Thanks for your interest in KnightOS!  Here's some stuff you might like to check out:
Latest Update
Demo Downloads:
TI-73
TI-83+
TI-83+ SE
TI-84+
TI-84+ SE

DISCLAIMER: These OS files are pre-release demos, and are not guaranteed to be stable.  In the event that you need to remove KnightOS or repair any problems, simply remove a battery, hold down DEL, and replace it.  You will be able to send a new OS.  Regardless, no responsibility for damage incurred by using these demos should be leveled against Drew DeVault.

Update
The filesystem now has a basic flat implementation, and I will be supporting the tree in a few days.  In addition, I was able to load a file from the filesystem into RAM and execute it.

Update
KnightOS made a major stride today - relative address loading.  At runtime, a program has no idea where it will end up in RAM, and therefore cannot correctly load relative pointers, or perform relative jumps or calls.  I just implemented kld, which has the same syntax as ld, but it calls a system routine that adds the program's RAM offset to the specified address, and uses SMC to modify the executing code so that it only needs to run the system routine once.  It's pretty awesome.

Update
Multitasking now works!  That's right - you can now run up to 20 programs at once under KnightOS.
4 days of non-stop work finally paid off, I guess!  Attached is a screen shot of the process in action.  It shows two programs displaying the hex value of A, which is unique to their threads - they aren't displaying the same A.

Update
lcall and LoadLibrary now work, allowing you to load libraries into RAM and call functions exposed within.  LoadLibrary accepts the same arguments as ExecProgram, and lcall's syntax is lcall ID, Function.  Each library has a two byte ID, and I will set up a library registration service, so that IDs aren't re-used.

Update
Flash writing now works great!  You can change the value of anything in flash memory.  Still to-do are page erasures, and for some odd reason, the flash write routine doesn't return correctly, but that should be easy to fix.

Update
I just created the official KnightOS website at http://knightos.sourceforge.net, where you will eventually be able to find downloads, source code, documentation, and developer information for KnightOS.  Please let me know if you find anything wrong with it.

Update
Hardware locking is now been implemented for the LCD port, and I am adding locks on the I/O, USB, and Keyboard hardware as well.  Of course I can't entirely stop programs from accessing the ports, but I can ask them to play nice, and all of the official routines are compliant with hardware locks.  The screenshot below is a demonstration of this technique, based on the same program from the previous update.  There are two threads, both waiting for keypresses.  Thread 01 is waiting on 1, and thread 02 is waiting for 2, and when those keys are pressed, they display their message.  Thread 01 is also watching for S, however, and when it sees it, it releases the LCD and gives control to thread 02.  In the screenshot, I alternate pressing 1 and 2, then press S every so often to switch LCD control.  Both threads try to write to the LCD, but only one is successful, and I can change which one that is.
The KnightKernel is progressing extremely well, and all I have left is to add hardware locking to other ports, add one flash control routine, and implement the filesystem.  Then it's just basic programs until the developer release.