I unfortunately am not familiar with assembly and that low level stuff, but it seems well explained from what I could gather.

That's a good point, I'll add a page identifier for FST pages as well.

I noticed that Garbage Dir has ID 0x01 and Directory has ID 0xFE. For deleting a directory or file, is the idea to mark it as deleted by clearing some of the bits in the ID? If so, you won't be able to get an ID of 0x01 by clearing some bits from 0xFE, since bit 0 is already clear in 0xFE. For deleted directory you could use the ID 0x02 instead.

Also, the way the swapping is done is pretty wasteful. It wears down FlashROM at least twice as fast as needed, and takes twice as long too. The way I would do it is to use a floating swap page rather than a fixed swap page. What this means is, instead of copying a page to the swap page and then back to the original page, copy a page to the swap page and then make the old page the new swap page.

To implement this you might have to use virtual page numbers. The first byte of each real page can contain the virtual page number for that page. So, for example, if real page 5 is virtual page 9, then all references to page 9 (say, a file entry with the file contents on page 9) will read from or write to the real page number 5. When you need to swap that page, then you can move the whole virtual page to the swap page easily and make real page 5 the new swap page. This adds a little bit of overhead but gives you much better performance overall.

Additionally, for a little bit of protection against incomplete page erases, you could add a few bytes (a magic value like "KFS") to the beginning/end of a page after it is erased. If your routines read a page that doesn't contain that magic value, then you know that the page wasn't erased properly. Erase the page and write the magic value (and virtual page number) to it.

The rest of the spec looks decent, but it is kind of a shame that only one writable stream can be open at a time. It's cool to see that it supports nested directories and long file names, though.

Good luck with this project!

Thanks for pointing out the directory problem.  I hate using hex for that kind of thing, I always make a mistake like that.
As for virtual pages, it sounds like a great idea to start.  However, it would get pretty inefficient, pretty fast.  Imagine you're several GCs into the usage of the filesystem.  The virtual pages end up completely different then the normal ones.  When looking for file entries, or reading from a stream, crossing page boundaries becomes very slow - you'd have to swap through every physical page until you find the virtual one you need.  That worries me, since you already need to search all entries to find the last file added.  It would be even worse for garbage collection.  Plus, the flash chip is a tough puppy.  I've only ever heard of one calculator's flash dying.

Are files allowed to cross sector boundaries? If not, you could go with virtual sectors, and crossing pages can still be done in a sequential manner.

Edit:
Also, I see a problem with directories being 0xFE and garbage directories being 0x01. You can't set bit 0, right?
Edit2:
Oops, that was already mentioned
Edit3:
Now that I look closer, files can be >65536 bytes large, so never mind. Ignore this entire post

Thanks for pointing out the directory problem.  I hate using hex for that kind of thing, I always make a mistake like that.
As for virtual pages, it sounds like a great idea to start.  However, it would get pretty inefficient, pretty fast.  Imagine you're several GCs into the usage of the filesystem.  The virtual pages end up completely different then the normal ones.  When looking for file entries, or reading from a stream, crossing page boundaries becomes very slow - you'd have to swap through every physical page until you find the virtual one you need.

Could you keep a copy of the virtual->physical mapping as a table in RAM? With a 1-byte entry per 64kB sector, it should only take 32 bytes.

Thanks for clarifying your point.  I think that I'll use the current system in this version, look into virtual pages for 3.0.  I'm definitely interested in the idea, but it's just not on the time table right now.

Fine, and it's pretty much done.  I just want to get it implemented in KnightOS before releasing it.