Great! I'm glad to see TI-89 support added. Does this includes TI-89 Titanium support as well?

Not yet. There shouldn't be too much to change to get it working on the Titanium, as far as the memory layout goes, but I haven't even tried porting to it yet.

I remember Prosit! That was a pretty impressive multi-tasking kernel with a GUI.

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.

You can scan the pages at boot time and keep a table in RAM to map virtual pages to real pages. This can be as simple as an array of bytes, the size being determined by the number of Flash pages (how many pages are there anyway? 32?). To find the real page number for a given virtual page number, just use the virtual page number as an index into the array, and read the byte at that position. That byte is the real page number. When you swap pages (as in, use the floating swap page), you just have to update a couple of bytes in the array.

If you align your array on a 256-byte boundary, the code to translate virtual to real page numbers can be this simple (note: I haven't tested this code):
ld h,virtual_page_table/256
ld l,a  ; a is the virtual page number
ld a,(hl) ; now a is the real page number

You would want to add some bounds checking on the virtual page number and such in a real system, of course.

EDIT: curses! Goplat beat me by 8 seconds!

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!

Good
So my wild guess about a read at offset 0x2E from address 1 actually proved to be correct...

Yup. I think I'll improve my exception handlers one of these days so they'll provide more information about the exception in human-readable formats (only when it happens in kernel mode. I'll want to send a signal and/or kill a process if it happens in user mode)

The bug you've reported on the TIEmu SF tracker looks odd. TIEmu has no business reading data one byte off their valid locations...

I noticed in both working and non-working (crashing) TIB files the long value 0xCCCCCCCC immediately before the SSP and PC, but in the crashing TIB, there is an additional 0xCC byte before that long value. That is probably just the last byte of a length or pointer value. Does TiEmu look for 0xCCCCCCCC as a marker or signature of sorts? If so then it would start at the previous byte for that reason.

Okay, so I found the problem. It is in this line in set_state() in sched.c:
               if (time_before(p->p_deadline, current->p_deadline)) {
Somehow the value 1 is passed in for p, and the p_deadline member is at offset 0x2e in the proc structure, so this is attempting to access a long value at p->p_deadline at address 0x2f.

So the address exception doesn't contain the return address but rather the address that some code attempted to access non-word aligned.

Now I finally bother reading M68000PRM.pdf. Here's the stack frame for address error exceptions (in pretty ASCII art ):
15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
+-----------------------------------------------+
|                                |RW|IN|  func  | <-- lower address (%sp)
+-----------------------------------------------+
|             access address (high)             |
+                                               +
|             access address (low)              |
+-----------------------------------------------+
|             instruction register              |
+-----------------------------------------------+
|               status register                 |
+-----------------------------------------------+
|             program counter (high)            |
+                                               +
|             program counter (low)             |
+-----------------------------------------------+
RW (Read/Write): Write = 0, Read = 1
IN (Instruction/Not): Instruction = 0, Not = 1

Therefore this address exception and the stack frame make more sense.

I still have to figure out what is calling set_state() with the value 1.

EDIT:   I just found it. I called set_run (which calls set_state) without any arguments, so whatever value happened to be on the stack was used as the value for p. FAIL  

EDIT 2: Lo and behold, that fixed the problem!! I guess I should use function prototypes more thoroughly, since TIGCC would give an error if I had a prototype for sched_run().

EDIT 3: Actually, calling sched_run() from that place (in tsleep() in process.c) was a bug itself. The process was already scheduled to run at that time so it was trying to schedule a process that was already running. I just had to remove the line completely. Now my scheduler and (due to my recent clock/timer fixes) timers are extremely stable!