KnightOS Updates

[SirCmpwn]

Kernel 0.6.10

This is another mostly maintenance related kernel release.

Features
New syscalls:

• createSymLink
• getNextThreadId

Bugs fixed

• Incorrect copying of data in realloc under certain conditions

Quoted from Github

Downloads

Headers
kernel-headers-0.6.10 (PKO version)

Kernels
TI-73 TI-83+ TI-83+ SE TI-84+ TI-84+ SE TI-84+ CSE

KnightOS running on kernel 0.6.10: Download upgrade files

[Ivoah]

Glad to see some progress on KOS! I wish I had some more free time so I could help with stuff, but school has been busy lately. I hope this update signals the coming of future bigger updates in the near future, keep up the good work SirCmpwn.

[Dream of Omnimaga]

Once I fix my old 83+ I'll give this a try. I'm glad that KOS is still progressing.

[Max Leiter]

Really glad KOS is still moving forward, really hope I can help with kernel dev at some point in the future. Should be a little easier now that I have a physical calculator to run it on d:

[SirCmpwn]

I've been working on bed (the KnightOS text editor) over the last few days. Here's a video of it editing its own source code:

[garvalf]

KnightOS looks cool, and while I know it's not the purpose of it, I find it strange there is not even a simple 4 operations calculator included with it...
I've seen https://packages.knightos.org/community/progcalc but I have now clue for how to install it within an emulator.

[utz]

I'm starting to drool more and more over this... hmm, perhaps I should attempt a KOS port of HoustonTracker 2? I assume it would be a relatively simple matter of changing the header, reassigning the saferam areas, and replacing the one bcall (clearlcd) with the according KOS function. Can someone give me a quick run-through of the most important things to know? I'd prefer to include a minimum set of tools in my own toolchain rather than use the KOS SDK, though.

[novenary]

KnightOS looks cool, and while I know it's not the purpose of it, I find it strange there is not even a simple 4 operations calculator included with it...
I've seen https://packages.knightos.org/community/progcalc but I have now clue for how to install it within an emulator.

There is no floating point support in the kernel yet, which is why there's no proper calculator for it.

I'm starting to drool more and more over this... hmm, perhaps I should attempt a KOS port of HoustonTracker 2? I assume it would be a relatively simple matter of changing the header, reassigning the saferam areas, and replacing the one bcall (clearlcd) with the according KOS function. Can someone give me a quick run-through of the most important things to know? I'd prefer to include a minimum set of tools in my own toolchain rather than use the KOS SDK, though.

You have to use the SDK to build KOS programs, because it has to be built into the ROM for now since there are still no file transfers. You'd have more to change than just the header. KnightOS executables are position-independent and you should use the syscalls to access the LCD. Not sure if it does anything with the link port.

[utz]

Oic. It won't be possible then. HT2 is not position-independant due to huge amounts of self-modifying code and page-aligned lookup tables, and all the gfx are done through direct LCD access via port 10/11.

[SirCmpwn]

Oic. It won't be possible then. HT2 is not position-independant due to huge amounts of self-modifying code and page-aligned lookup tables, and all the gfx are done through direct LCD access via port 10/11.

Phoenix is the same way - lots of LUTs, SMC, and direct LCD access, but I was still able to port it.

[utz]

I think I'm a bit too busy to really dig into KOS enough to pull it off at this point. Well, you can always give it a try of course, the code is on my github. Though I'd say it's probably best to wait till the next release, when a few more bugs have been ironed out.

[SirCmpwn]

Got a special something in the mail yesterday. Was a nice distraction from the KnightOS stuff I'm supposed to be doing. Check it out:

That's right! TI Keyboard support, baby. I started by implementing the TI link protocol, and then decoding packets from the keyboard to pull out scancodes. I made a generic interface from the kernel to expose raw scancodes to userspace from any sort of keyboard as well. The old keypad driver is still in place and hasn't been moved to this model, but I expect to change that fairly soon and move most of the keyboard handling to userspace (this will allow us to do things like support USB keyboards with whatever non-English keymap you prefer, for example). I hardcoded the TI Keyboard's keymap into corelib so that the getCharacterInput function would return ASCII characters from the keyboard. This means that any userspace app that already took text input now supports the keyboard with no changes (no need to recompile, either). It's not done yet, but it's pretty good. Also, this forced me to establish partial link protocol support in the kernel, which is a good head start for eventually implementing file transfers from PCs to calcs.

If you want to play with this yourself, a TI keyboard is about 10 bucks on Amazon. The relevant changes to the kernel and corelib have not been released in a stable version yet, but you can compile them yourselves if you want to try it out.

[novenary]

Nice, that was pretty fast. I like that you are supporting official peripherals, gives KOS even more value to switch over to.

[Max Leiter]

Really cool to see some kernel work being done on KOS, also surprised at how fast you added it. +1

[SirCmpwn]

Spent all weekend working on this:



It's still pretty buggy, but the code is up here: https://github.com/KnightOS/iofsd. The relevant kernel code is here: https://github.com/KnightOS/kernel/blob/master/src/00/link.asm

This is a daemon, "iofsd", that I'm going to make run at boot (it'll be added to /etc/inittab). It makes it so that a computer can talk to KnightOS about its filesystem over the I/O port. Running as a daemon means that it's kept in the background and silently does its job while the rest of the OS gets on with life. It also spends most of its life suspended, which means that it's not taking up CPU time except for the handful of milliseconds it spends responding to queries over the I/O port. The end result is that I can plug my calculator into my PC while I'm playing Phoenix and list the contents of a directory without any discernable slowdown of gameplay. This depends heavily on the I/O support I've added to the kernel, which gives userspace programs asyncronous access to the I/O port. 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. Userspace programs can also allocate buffers for bulk transfers and asyncronously send a response. This is also designed for concurrent use of the I/O port - you could plug your calcluator into a friend's calculator and start sending over files, then switch to a chat program and chat with them as the files are being sent in the background. Currently, only the TI-83+ SE and higher are supported. I'll add the TI-73 and TI-83+ after everything settles down, it shouldn't be too hard.

Anyway, it's still buggy, but it works.. Next on my plate is going to be cleaning up the bugs and making it stable, then I'm going to add support for sending and receiving files, and eventually I want to make it so that you can mount your calculator's filesystem on a Linux system with FUSE (which will then make it possible to install packages on your calculator without reflashing the whole OS, finally).