You would be able to store programs, but not run them directly from "ExRAM".

Also, I was thinking of keeping track of the last address allocated in memory, so that allocation and deallocation would run faster by moving only what is needed. That is with the first TI-OS style memory allocation method. I still haven't developed anything for the second scheme, so that's still iffy.

I'm still planning this thing out on paper, since it wouldn't be the easiest thing to debug. Know that I can't use PTI to emulate this since PTI doesn't have support for the memory I'm trying to use, so development will naturally be slower than if I had an emulator that would work with this.

Any suggestions for commands that might be useful for interfacing with this move-only filesystem program? Maybe filesystem ideas?

So far, these are the specifics of the idea:

In addition to ROM pages 0 thru 7F (logically), there are RAM pages 0 thru 7, addressable as-is on port 5, or addressable through port 6 as $80 thru $87. Because of logic simplicity and the fact that the TI-OS on the TI-84 series uses RAM page 2 (for USB protocol), my program will use RAM pages 4 thru 7 and address it as if it was a single 64KB chunk. For that, I have a routine that transparently translates an address in a register (usually HL) to reflect a page and position in the $400-7FFF memory bank.

Programs are allocated from $0000 up to the end of the table, the table starts at $FFEF and grows downward. The spare 16 bytes beyond the table is reserved for filesystem variables, so they need not be stored in user RAM, and is then safe from other utilities that will use the standard saferam areas.

At the start of the table, each entry will be allocated 12 bytes per entry, irrespective of the variable's type. This is to ensure that traversing the table will happen as quickly and painlessly as possible, although a dynamic table size is certainly probable. Each entry is written backwards in memory, but each entry, shown forwards is as follows in offsets:
+0 : Data type
+1 : LSB of memory location
+2 : MSB of memory location
+3 : Reserved (possible use is a name size byte or something.
+4 to +11 : 8 bytes allocated to data's name. Null-padded.

Upon formatting this memory, one entry will be already on the table, and the variable created contains four bytes, two for its size and two for the data itself. It's name will be "!", and it serves the purpose of being a placeholder so there won't be a table with zero entries. Using the memory routines, an error will be generated if one attempts to delete "!" out of the memory.

At memory location $FFFE will reside a two-byte entry showing how much "Free RAM" there is. Although it could be calculated each time, I would like to keep it to verify the integrity of the filesystem.

At memory location $FFFC will contain a two-byte entry showing how many symbol table entries there are. This is used as a loop counter as the symbol table is traversed.

At memory location $FFFA will be the address of the last piece of data allocated in ExRAM. This value is used to calculate where the end of ExRAM is so that memory allocation and deallocation can run much more efficiently, so that they don't try to move unused memory (which would cause a massive slowdown if there was a large enough chunk between the end of the symbol table and the end of ExRAM).

More variables will be inserted into this "reserved" space as I see fit.