Ahh yes, thanks for the reminder Runner.  I forgot it was the erases, not the writes.  Regardless, each archive writes to a new place, correct?  So chunking the map and archiving/unarchiving multiple times per session would fill up the memory faster than just archiving once at the end, which would result in more flash clears.  Of course, whether anybody should actually worry about this is questionable.

How much exactly can fit into ram?  I've seen 4,000 bytes of free ram, but is this the only place in which map data can be stored?  I would assume more is available...

Ok, that makes sense. Two questions in that case: 1. Is there any way to detect if the user has unarchived programs?  2. Is there a rule of thumb for how long unarchiving/archiving an appvar (based on its size) will take?

you can use the bcall _ErrNotEnoughMem to check if enough free ram is available (usable in axe via inline asm). apparently 9815h also contains the total amount of ram free, so you could check there too.

also, like several other people have said already, there is no reason for you to be unarchiving anything ever during your program's execution. all that "unarchiving" does, anyways, is copy the variables to RAM and then delete them from the archive, and there's no reason for them to be deleted.

Alright, thanks for the help with handling available space.  But Shmibs I must be misunderstanding something...at somepoint the map data would need to be unarchived in order to alter it would it not?

You do need to place map data in RAM to alter it, but you don't have to both copy it to RAM and delete it from flash (which is what unarchiving does) – simply copying it to RAM is enough.

Alright, I get what you mean with copying.  As far as more information, I'll give you what I can.  I would expect most users to heavily modify tiles in a fairly concentrated area, and only do light changes in the rest of the map.  However, there is no way to predict where these heavy changes will take place, and it is entirely possible, although unlikely, they will heavily modify everything after a long time.  As for number of tiles, I would guesstimate under 64ish, with only about 16-20 being extremely common throughout the world.

Edit:  I've been thinking some more, and I feel like chunking the data into smallish appvars is the best route.  My map would consist of multiple appvars, of which, three would be loaded into ram at a single time: the chunk the player is at, and a chunk to either side.  If the player modified any of the tiles in a chunk, the new data would be saved to the appvar, and that appvar would be flagged as modified.  When the player changed chunks, the one chunk that will no longer be loaded is checked to see if it was modified, if it was, it is archived, if not, it is simply discarded.  If anybody has any feedback on this (completely theoretical) method, please share.

Note: I considered using a list of changes that took place, but quickly ran into too many obstacles.  For example: handling multiple changes to the same tile and preventing the list of changes from getting excessively large.