KnightOS Updates

[Lionel Debroux]

Looks good

so that you can mount your calculator's filesystem on a Linux system with FUSE

In libticalcs, it's a good thing that since the TILP II 1.17 release train, I moved static variables scattered into multiple source files to CalcHandle...

[SirCmpwn]

In libticalcs, it's a good thing that since the TILP II 1.17 release train, I moved static variables scattered into multiple source files to CalcHandle...

Nice this just uses libticables, not libticalcs.

[Dream of Omnimaga]

So basically, does it mean that in the future, it could be possible to launch KnightOS-compatible calculator programs from a computer, with the program being temporarily copied in the calculator RAM then if writeback is enabled, its copy sent back to the computer upon exiting? No matter what, this is very cool, though. I always kneew that KOS aimed at supporting multitasking but I didn't realize that multitasking could continue working in an ASM game.

[SirCmpwn]

So basically, does it mean that in the future, it could be possible to launch KnightOS-compatible calculator programs from a computer, with the program being temporarily copied in the calculator RAM then if writeback is enabled, its copy sent back to the computer upon exiting? No matter what, this is very cool, though. I always kneew that KOS aimed at supporting multitasking but I didn't realize that multitasking could continue working in an ASM game.

I guess that sort of thing could be possible, but that's not really the intent of this feature nor would it be possible without significant further development. Also, KnightOS doesn't really use writeback - instead, you're encouraged to create files on the filesystem to save your data. Phoenix uses writeback on TIOS, but the KnightOS port of Phoenix stores its saved game data in /var/phoenix/.

The secret to having the game remain playable while remote file operations are happening is the asyncronous kernel API for the I/O port. Whenever the daemon takes control to respond to packets, it runs a relatively small and fast amount of code that ends with asyncronously sending a packet, which then returns control to the game while the packet is sending, and the daemon only gets control back again once the packet is done.

[Dream of Omnimaga]

I see. Also good move about the save files. I wasn't sure if you used those since you were playing Phoenix, so I thought that some old ASM games would still rely on SMC.


Also I assume that the asyncronous kernel API for the I/O port uses something like interrupts, right? Would it make it had to port games such as Desolate and the ASM remake of Reuben Quest 2, which uses interrupt-based grayscale?

[SirCmpwn]

I see. Also good move about the save files. I wasn't sure if you used those since you were playing Phoenix, so I thought that some old ASM games would still rely on SMC.


Also I assume that the asyncronous kernel API for the I/O port uses something like interrupts, right? Would it make it had to port games such as Desolate and the ASM remake of Reuben Quest 2, which uses interrupt-based grayscale?

Yes, it uses the link assist interrupts. The hardware is responsible for sending/receiving bytes, and the kernel's interrupt handler queues up the next byte in a handful of T-states. Desolate and Reuben Quest's way of doing grayscale are not compatible with KnightOS, but I'm planning on making a grayscale library that is interruptable, which the ports of games like Desolate can be modified to use instead of their current grayscale mechanism.

[Dream of Omnimaga]

That's good. Does it mean that grayscale would sometime stop refreshing during gameplay every second or so for a very short period of time?

[SirCmpwn]

That's good. Does it mean that grayscale would sometime stop refreshing during gameplay every second or so for a very short period of time?

Too early to say, but of course that would not be the desired behavior and we'll work to avoid that.

[Lionel Debroux]

this just uses libticables, not libticalcs.

I thought you may have been able to leverage some code from libticalcs, especially the lower layers (dbus_send, dbus_recv), or even some commands (now in cmdz80.c), given that you wrote:

Given some minor extensions on the TI link protocol, the kernel can listen for packets and notify userspace programs that have requested to be notified about certain packet types as they arrive.

The version in the tilibs Git repository exposes more APIs than the version corresponding to the TILP II 1.17 release train.

[SirCmpwn]

The libticables code for iofs is pretty simple, take a look for yourself:

https://github.com/KnightOS/iofsd/blob/master/iofs/src/protocol.c

[Lionel Debroux]

send_packet() could just leverage dbus_send(), which has been exported for a while. You'd gain progress information.
recv_packet() cannot just leverage dbus_recv(), as that performs protocol checking... but if I refactor dbus_recv() to split the header receive and the data receive code (with progress information) from the main function, then export the two new helper functions, you could use them. This refactoring is a worthwhile change regardless of whether you switch to libticalcs.

[SirCmpwn]

send_packet() could just leverage dbus_send(), which has been exported for a while. You'd gain progress information.
recv_packet() cannot just leverage dbus_recv(), as that performs protocol checking... but if I refactor dbus_recv() to split the header receive and the data receive code (with progress information) from the main function, then export the two new helper functions, you could use them. This refactoring is a worthwhile change regardless of whether you switch to libticalcs.

I see. The progress information would probably be useful if I were to make some sort of GUI for managing your filesystem. Also, I'm pretty sure that the protocol in use here is close enough to the dbus protocol that it'll work fine. I probably wouldn't take advantage of them in any case for this project, but you're right that the refactoring may be worthwhile. I would like to see more people using libticables for interesting projects like this.

[SirCmpwn]

New contributor jacobly has been making some waves recently in z80e and other places:



He has dramatically improved the accuracy of z80e. Now it can boot TIOS, though it's buggy and slow - probably interrupt problems. It can also run this old KnightOS demo, finally:

Thanks to his efforts, z80e passes zexdoc and zexall now, which means that the z80 emulation is spot on. Thanks jacobly!

I'm probably going to jump on the z80e train and flesh it out some more when I'm not working on iofsd or bed.

[Max Leiter]

Also worth noting, there is now a Dockerfile for a Debian machine with the SDK installed thanks to @SirCmpwn

[Lionel Debroux]

FWIW, I've now spliced the header receiving code and the data receiving code out of libticalcs' dbus_recv(), and exported both new helper functions, as I mentioned above. The commit lives in the "experimental" branch for now, https://github.com/debrouxl/tilibs/tree/experimental .