Nope, I've already had to deal with those issues x.x

Hint for all people downloading content with the web browser Chromium: Chromium caches downloads. That means that if someone changes a file (lets say an OS for a calculator) and wants you to download it and try it out, you will probably not download the latest version. Instead you download the same version over and over again and therefor giving completely false information to the person who is changing the file. This might not be a good thing to do.

Instead, use something that doesn't cache downloads unless told to, like wget.

Woohoo! Thanks in part to Dr Phil's help, I've gotten KnightOS back to a workable state. It still behaves differently on hardware than on an emulator, but I'm making progress.
I also found a clever way of debugging things on hardware when you don't have text routines and such available. I did have various LCD routines available, such as FastCopy, PutSprite, and [get/set/invert]Pixel. What I ended up doing was displaying a pixel at every major point in the code I was debugging, and moving it down a pixel each time. That way, depending on how far down on the screen the pixel got, I could determine just where the problem occurred. I've also used PutSprite to dump portions of RAM on the screen (I could use FastCopy, which accepts a buffer in IY, but it would be far too messy to translate to binary by hand).

interesting use of lcd buffer drawing... glad that it is getting back it working

Yeah, I'm very pleased with the idea of using the screen to display diagnostics in unorthodox ways. For example, my PutSprite routine takes the height in B (which is essentially the number of bytes to show), so I put in a height of 8 and dumped the first entry of the thread table to make sure it initialized correctly. I did the same with RAM formatting.

I recorded one of these tests to give you a general idea of what I'm talking about. I thought it looked pretty cool

The first pixel is displayed after hardware initializes correctly. After that, you have an 8x12 sprite that shows the end of page 0x77 (this is part of the filesystem I had a feeling was corrupted - I was wrong). After that is the file copy loop, which is supposed to copy the contents of a file to RAM. What you see there is a display of the number of bytes left in the file: three registers, DBC, on top of each other. In the emulator, this works right - the size of the file in question isn't very large, and so only C has anything worth showing.
On my calculator, all three registers are shown as 0xFF, which is the current source of my woes (this is why I show that portion of the filesystem as a sprite, I thought perhaps it was corrupted).
On the emulator, after it shows the loop counter's progress, you can see one pixel in the middle appear (signalling the end of the loop), and another one to the right (signalling the completion of the routine). The next source of my woe is the lack of another single pixel on the far left showing that it successfully launched the userspace program, but I'll tackle that after the 0xFFFFFF problem.

That's basically the point of the little spinning sets of pixels at the bottom of the screen when CALCnet is in debug mode. Debugging interrupts is a huge pain, and that makes it a lot more straightforward.

I've always wondered what those were all about, thanks for clarifying.
After some more testing, I've found that the behavior is different on a TI-84+ versus a TI-84+ SE. If anyone wants to add a model to that list, I'd greatly appreciate more tests.

I have to agree with SirCmpwn's and KermMartian's use of simple graphics on the screen for diagnostics. I use the bottom left of the screen (which isn't used for anything else currently) quite a bit for this purpose in Punix. There are a few "spinners" showing where the kernel is spending its time, a counter showing process context switches (it increments once for each switch), an audio buffer usage bar, link usage bars, etc. All of those little pieces of graphics are pretty messy and mostly ad-hoc, but they are invaluable for debugging interrupt handlers and other timing issues.

Besides being useful, they're also really fun to watch while the system is doing stuff.

When I found out that the calculator was using 0xFFFFFF instead of an accurate number, I changed it so that it had key repeat and could force shut down with clear, just so I could hold down Enter and watch the pretty dots

I fixed it! Thanks to BrandonW for his help in the matter. Apparently, you need to include the first page of each sector you use in the 8XU. Part of the file system is stored at page $77 (84+ SE), and the beginning of that sector is $74. The boot code only clears a sector if it receives the first page in that sector, otherwise it just tries to overwrite it (which doesn't work). So I changed my build tool to automatically include the first page of each sector used in the 8xu.
That, in addition to fixing various other problems, put it back into a working state.

After months of waiting that you've surely been on the edge of your seat for, I finally have a demo prepared! It isn't very exciting, but it's still better than nothing. I've finished around 60% of the kernel, enough that I'm comfortable working on userspace (OS) code. So, I've started making programs, including a basic version of the Castle. Right now, the boot code will check to see if /bin/install exists, and run it if it does (it deletes itself), and otherwise, it will start up the Castle. The Castle can run /bin/hello (Hello World!), and has set up a custom return point to re-launch the Castle when it exits (for some reason, this only works once, any subsequent run of /bin/hello will not correctly return to the Castle (it just reboots). Outside of this, the Castle shows off some pretty graphics and allows you to sleep, shut down, or restart your calcultor.
Right now, the TI-73 and TI-83+ versions are not working, but I've tested the TI-84+ SE on hardware. I'm having validation issues with the TI-84+, so I'm not sure if it works properly (it installed with no problem a couple versions ago). I don't own a TI-83+ SE, but I'd be interested to see if it works, if anyone has one to try it on (I'm pretty sure it will work).
TI-83+ SE
TI-84+
TI-84+ SE



All of the things that are going on in this screenshot:

• Boots up, launches /bin/boot
  
• /bin/boot checks for /bin/install, and launches it
  
• /bin/install does nothing (debug build), and deletes itself, then loads /lib/libtext and displays a message, then reboots
  
• Boots up, launches /bin/boot
  
• /bin/boot checks for /bin/install, which doesn't exist, and runs /bin/castle
  
• /bin/castle loads /lib/libtext and draws its interface
  
• /bin/castle enters a loop
  
• User launches /bin/hello from /bin/castle
  
• /bin/castle sets up a custom return point for /bin/hello and exits
  
• /bin/hello loads /lib/libtext, which is already running, and nothing happens
  
• /bin/hello displays a message and returns
  
• The custom return point re-launches /bin/castle
  
• Repeat
  

EDIT: Added contrast adjustment (+/- from Castle), and fixed validation for TI-84+

Looks nice! I like the theme stuff you did there. Nice to see that your OS is running and can do stuff.

I spent some time wrestling with SVN, but I successfully got the source for this version up here.

I've added crash detection, which I'll improve over time. It will clean things up and let the user know what happened, and in some cases will be able to recover.

I rewrote memory management, and it is now significantly more optimized (and easier to read). It also addresses a problem I call "dead memory", where the space between the end of one allocated section and another is too small to overcome the overhead caused by metadata about allocated segments (and with reallocating the same section twice with the same amount of memory - happens a lot with screen buffers). What I ended up doing is padding dead memory by a few bytes to be the exact size of the allocated section.

New, more stable demo is up:

• TI-73
  
• TI-83+
  
• TI-83+ SE
  
• TI-84+
  
• TI-84+ SE
  

The TI-73 and TI-83+ versions may have some issues, but the rest should be rock-solid demos. If you manage to see that fancy crash recovery screen, you should let me know (I don't think you possibly can right now).

Exactly HOW stable is this?
You remember last time I DL'ed a KOS demo.

Heh, what I remember is that you flipped out over nothing special, and did some serious damage to my OS building reputation
There is no way whatsoever that this will do any permanent damage to your calculator. What it might do is damage your archive when you re-install TIOS, because they use incompatible file systems.
However, you can always, always remove a battery, hold down DEL, and replace it to force-receive an OS. As far as stability of this particular OS is concerned, I've tested a TI-84+ and TI-84+ SE myself, and it works perfectly.
Worst possible case scenario, TIOS doesn't like your archive. If this happens, then you can still stop the transfer halfway through (remove the cable or something), and then the boot code will let you format Flash with Battery Pull+Mode.

Wow, this looks awesome! When it is finished, it will be the OS my calc runs One question, will it work on TI-Nspire 84+ keypad?

Not really. I plan on looking into it, but you probably won't be able to permanently change the OS.