When will you be releasing some sort of spec on KFS, SirCmpwn? I'd be very interested in taking a look at it and suggesting anything that might pop into my head.

I did ^.

No, you released a general spec about KnightOS. I'm requesting more details about the Knight File System as you envision it, including what metadata will be stored other than an (Address,Page) triplet pointing to each item. Folder? Name length? Restrictions on name characters and length? Will size be stored in the FAT or in the file itself? Those are the kinds of details I was looking for.

Oh, I see.
Well, I have a spec for the KFS. Its on my *other* computer. But I can answer a couple of those details now, and post the spec next time I get on my primary computer. The limit on folder/file name length is available memory. Characters have the restriction of not using \ or /. Address/Page/Length are all stored in the FAT. No metadata will be stored.

Here is documentation on the KFS. It is not just subject to change, it is almost guaranteed to change, but it is what I have right now.
Also, below is the memory bank layout I have planned currently:

You're not planning on storing each executable on its own page, though, are you? That would be fairly interesting, and very nice in terms of relocation and all that, but quite inefficient. I presume therefore that the program will specify what RAM reservation it wants, how much stack space it needs, etc?

No, there are two routines that are important to this:
AllocateMem
AllocateExecutableMem
The OS calls AllocateExecutableMem to allocate some RAM at 8000h, and loads a program into it. Programs call AllocateMem to get access to free RAM at C000h.
As for the stack, I was thinking of having programs request a stack size, and KnightOS using AllocateMem for its stack.

Still chugging along
I'm in the process of reworking the filesystem driver and the RAM driver, and will shortly have a stable kernel to build the OS off of.

Whoa, and at that point will you therefore have the filesystem complete and working? Or am I misunderstanding, does the Filesystem Driver simply interact with a separate module that manages the filesystem, which you'll have to write separately.

The filesystem driver will work and will easily be updated. The KFS, however, may not be the same. Right now, IDs count from 01 and up in the KFS specs, but I think I want to use FF down so I don't have to clear Flash pages to update files. I also need to add an ID to represent a deleted file.
Also, the filesystem can probably be complete and working the next time I sit down to work on it. I have a lot of projects, so next time I start working on KnightOS, I will probably finish the KFS driver.

Sounds good. To avoid lots of Flash trashing, I was thinking that perhaps you could do something similar to what the TI-OS does, keep writing new information across additional, later pages that may contradict and supercede information on previous pages, and then consolidate it when you're running low on space? This would require a bit more computation, of course, but you could certainly do some intelligent stuff like RAM-caching to keep it to a minimum.

Well, RAM is the only way for programs to modify files without directly unlocking the flash themselves.
Also, a Garbage Collect kind of thing will be implemented. It will run in the background, and all reads/writes to files will return an error until it's done.

Update
KnightOS had a major breakthrough - the first successful hardware test!
Eeems, who recently started working on the kernel with me, tested KnightOS on a TI-83+ today successfully. All the implemented features worked flawlessly, and it sent to the calculator just fine in signed form.
In addition, the following features and landmarks have been reached:
*Memory allocation is done, for both executable and data memory
*Eeems wrote a sound driver that allows for sound to be played from the OS

Which features are those, by the way? LCD drivers, text rendering, powering on and off?

Hehehe, I have a copy of your KinghtOS, although you did make changes... Sorry I cant use it, TILP is an idiot when it comes to OS upgrades

Exciting!

Hope to hear about new updates soon. Can't wait to see how well this progresses

Lol, yes. It's a surprisingly complete kernel, though. A couple days and I start work on the OS.

Winsauce. Does this mean you have the filesystem and memory allocation and deallocation completely working and tested, then? Is there a size limit to files? Can they span flash pages?

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.

To answer KermM's question, memory allocation/deallocation has been tested and is working, and files can indeed span flash pages, although they will have to be edited in smaller chunks if the program doesn't take over the processor. The size limit is the available memory, although I'm trying to keep the data pages off of the FAT pages.

Sorry to ask if it has already been said, but will you have in-built asm support, as in no need for shells?