Okay, so it's about time that I make a new calculator game. this time, I'm trying to create motherload. Yes, that game you played for hours on miniclip is now coming to a calculator near you.
So, I have calculated that a 140(w)x280(depth) map will take up almost 20000 bytes. Is that okay with you, or is that too much? Please vote so I can know.  Thanks

Maybe you could find some source code or tiles here that you could re-use, but I don't know how you would ask the permission.
Anyways, nice project idea. How many tiles are there in the game ? I guess you already use nibbles but if there are less than 4 tiles (which I doubt a bit), you can use two-bits per tile and divide the size of the map by two again.

Also, you could do like I do in TinyCraft: let the user choose the size of the map so people with a regular 83+ can choose a small one and people with a 84+SE can choose a large one (so I voted for "other").

It would be awesome.

suggestion for the map data: put it in an appvar.

And yeah I think I might reduce the map size to say 70x140 and let the user choose the depth (in multiples of 140)

Why does it have to be multiples of 140 ?? I could have understood a fixed value for the width, but the depth  can be anything, can't it ?

If you want to make it generate levels, can't you generate them at runtime and only save the things that change during gameplay (like positions of enemies)? I wouldn't mind having loading areas when you move to an other part of the map.

You can save the seed in the save file.

GLHF to avoif Garbage Collection. Is GC possible without the TI-OS menu? I'd see a loading screen with GC ibcluded

         I think the best solution would be to do something like the following.  First you will need some sort of deterministic random number generator (not axe's).  By using a random seed as a map key, combined with using the coordinated of a tile as a secondary seed, you would be able to generate the entire map from a single seed key.  More importantly, you could generate any tile in constant time, independent of any other tiles, and would not be restricted to having only 16 possible tile values.  Then it is only necessary to store a single bit of information for each tile, whether or not it has been dug or not.  With a map 128x256 you would only need 4096 bytes to store the entire state (plus the map key).  This is small enough that you could easily store it in an appvar.  When scrolling, you (assuming 8x8 tile size) can only see a maximum of 117 tiles at once, which is plenty small to fit into a small RAM area.  This 13x9 map area would be constantly updated as the screen scrolls by generating the new tiles using the map key and tile position as seed, and then setting the tile state to filled or dug based on the bit you read from the appvar.