Another method that you might be interested in works like this:
Say you have 10 different tiles and numbers are stored with 14 digits of precision. You can then store each map layer with the nth digit in the number. To access the map in TI-BASIC code:
10fPart(10^-N[A]
If you aren't familiar with TI-BASIC, fPart( simply grabs the decimal part of a number (leaving off the integer part). If the language you are using doesn't have that, there is probably some equivalent to a floor() function (round down to the nearest integer) and you would essentially do #-floor(#).

If you have M different tiles, you can theoretically store up to floor(14/log(M)) different maps in a single matrix element, this way. However, I would go with 1 less than that to avoid precision problems. Your code for extracting a given matrix would be to replace the 10 in the above code with M.

I hope to see more ideas Encoding data with primes and properties of numbers can have some pretty interesting effects.

That looks great o.o Is that 6MHz or 15MHz?

Hmm, might I ask why you need 16-bit coordinates? And will they be signed or unsigned? If they are unsigned, you will not be able to use the negative coordinates Runer112 mentioned.

You can definitely put a size word O.o And if you put in a size word, you just jump over all of the data, so you don't need to worry about a program having an FF since you jump over it. The bytes might look like:
FE0900EF004048656C6C6FC9 FE040001020304 FFFFFFFF...

When you read the first byte, it is FE, so the next two bytes are 0900 (the size bytes for 9 bytes), so you skip the next 9 bytes and now the pointer is at FE, the next size bytes tell it to skip 4 bytes, and now you are pointing to an FF byte that you can overwrite.

Reading flash is just like reading RAM.

Only if you want to overwrite it. If you have erased the sector (a chunk of 4 flash pages), you can write to all of the bytes. That is why the OS needs to garbage collect. When you unarchive to edit, then rearchive, it gets written back to a different place instead of overwriting the whole sector just to replace the data.

In case anybody missed it, Matrefeytontias is working on building an OS, so he won't have some tools (but it should be easier). I think this page might be useful.

Thanks, I will see what I can do! I will also try to see if there is a way to make it return to an app, too. If it doesn't return because of bcall(_JForceCmdNoChar), then that would be an issue for programs because it would eat a little RAM. For an app, I can just temporarily create a GetKey hook to automatically re-enter the app.

EDIT: One solution might be to make it so that your app starts with:
     jp Start     ;go to the normal start of the app
     jp Compile    ;jump to the compiling code
If your compiling code is a subroutine that ends with an RET, then people can simply use 'call 4083h' to compile a program.

For example, say this is a 4x4 section of your tilemap:
1  1  1  1
1  0  0  0
1  0  2  0
1  0  0  0
The numbers are your tile numbers, but they don't immediately point to tiles. Instead, they point to 4 bytes of data. The first byte tells you things like if you can walk on the tile or not, fro example, and the last two bytes tell where the tile data actually is. This way, if Tile 0 and Tile 2 use the same tile, but you can walk on tile 0 and not tile 2 (maybe something hidden in the path), you can use the same sprite twice instead of creating a new one. This is also a useful technique for animated tilemaps >.>