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. 

The Axe Documentation states that 0 is not a valid size for the Fill argument. 

The problem with making Basic fast, is that you would have to actually change the way the language works in order to get any good amount of speed.  Basic is slow for 2 main reasons, the first being that every single graphics command updates the screen.  Even asm games are slow if they are forced to update the screen after every drawing command.  The second reason is that all the math is in floating point, which is inherently slow.  That is why all attempts to make a fast version of basic have gone on to design their own languages like Axe or Grammar

The command 'rand' generates a random number from 0 to 65535.  To restrict that range to a smaller range, you can use the modular arithmetic operator ^ like so: rand^37.  This divides the random number by 37 and returns the remainder.  By the nature of the remainder, its range is from 0 to N-1 when you divide by N, so this function returns your desired number from 0 to 36. 

pimathbrainiac you should definitely post a program as well so we can try everything out.  Looking at the screenshots it looks like there might be something funny going on, but it's hard to tell when everything's moving so fast.

This sounds like a very intriguing new way to save memory!  You better watch out though, since even though the maximum value for a number in a matrix is 10^99, the numbers are stored in floating point format.  What this means is that even though you can store very large numbers, the precision of them will only be about the last 14 digits or so (depending on your calculator model).  This will result in extremely large numbers being seemingly divisible by numbers they cannot be divisible by.  For example, a large enough power of 2 will return 0 when you ask for remainder 3.

Yeah don't worry, I'll make sure everything is right.  I can't send the screenshots themselves because each chamber is cut into lots of little pieces and need to be edited together.

I'm slowly working on that as well, it is mostly done I just have a few more chambers to finish up.  I might try to work on that tonight since I seem to have some free time today