On Wed, Jan 14, 2026 at 4:59 PM David Plass [email protected] <https://mailto:[email protected]> wrote:
I may port my own Baseball game (Commodore PET BASIC, as is tradition) > next. Oh! I somehow never realized that the screen size on the Tandy 200 (40x16) is comparable to the Commodore PET (40x25). I wonder if it would be possible to port Dan Longfellow’s Miner! <https://archive.org/details/Cursor_19_Miner_1980_Longfellow_Ron> to the Tandy 200. If you’re not familiar with Miner, it looks like this: [image: image.png] And here are the instructions from 1980: *MINER!* In this game you are a gold miner, facing the normal hazards of a deep mine: there are cave-ins, (which sometimes cause you to lose all your gold!), as well as underground springs that will flood your carefully dug tunnels. You move by using the numeric pad [2] is down, [4] is left, [6] right, [8] is up and [5] means “stop”. Naturally, the first thing to do is get in the elevator and move down. When you get to the level where you want to work, press [4] and start digging with your pick. Gold (or hazards, such as springs or hard rock) will occur at the dots. When you find gold, get in the elevator and deposit it in the bank! You have a drill [D], explosives [E], and a pump [P] at your disposal. However, using these tools costs money! You’ll win the game when you amass $10,000. If I recall correctly, it was all BASIC and the only tricky thing would be that screen memory on the PET was mapped to an area of RAM. Every time you moved your character one step, it would use PEEK to check if you were going to run into another character on the screen. Then it would use POKE to put your character in the new location. Again IIRC, the Tandy 200 can’t do that because the screen memory is stored in the LCD driver chips, right? Anybody have a good idea for how to fake a screen map in Model-T BASIC in a reasonably efficient way? Bitwise operators are space efficient but deadly slow in BASIC. I’d use a 40×16 array of bytes, but I don’t know how to do that in BASIC. Even single-precision integers take up two bytes (plus overhead), so DIM SC%(40,16) consumes 1404 bytes even though there are only 640 unique locations. I remember John Hogerhuis once mentioning having allocated memory at the end of a program by using an invalid last line number in the .BA file. Is the maximum length one can allocate that way limited to 256 bytes? Would there be any harm in treating DIM like malloc() and doing something like this? 10 DIM SC%(40*16/2) REM Allocate at least 40*16 = 640 bytes20 LM = VARPTR(SC%(0))30 ...130 POKE LM + R*40 + C, 42 On our systems RAM isn’t the screen but it *is* the filesystem, so I want to be extra cautious when POKEing around. Does the Model-T ever shift the location of where BASIC variables are stored while a program is running? Is the DIM statement guaranteed to allocate a single contiguous block on a Model-T? —b9 9
