Memory usage and squeezing Lander into the unexpanded Archimedes 305
Compared to the memory-intensive Elite, David Braben's previous game, the memory available to Lander feels positively spacious - the BBC Micro had just 32K compared to 512K in the smallest model in the original Archimedes range. But even with all this extra RAM, Lander has to be careful with how it consumes its memory. Here we take a look at the memory map for Lander.
In the Archimedes, any physical RAM installed in the machine is mapped by the memory controller (MEMC) into various parts of the first 32MB of the memory map, which runs from 0 to &2000000. As the maximum amount of physical RAM on an Archimedes is only 4MB, there is plenty of space in the 32MB memory map that isn't mapped to physical memory, and trying to access this will give the "Abort on data transfer" error that is familiar to anyone who has done any coding on the early ARM chips.
The currently running application is always mapped to &00008000 - so in terms of Lander, that's the main game code and all of its workspace and buffer RAM, including the game's own stack. Screen memory is mapped to the top of the memory map, ending at &01FFFFFF. As Lander needs two banks of screen memory with 80K for each bank, this means the two screen memory banks live at &01FD8000 and &01FEC000. The operating system allocates various other memory blocks on top of these, such as the system heap, the sprite area and so on, and the first 32K of the memory map from 0 to &00007FFF is always reserved for the system workspace.
The application is allocated whatever memory is left once everything else has taken a bite. As a result, when running Lander on the Archimedes A305 with its relatively modest 512K of memory, you have to quit the desktop and run a utility called USEGAME before the game will run. USEGAME unplugs the modules containing the font and window managers, disables the desktop and sets the screen size to exactly 160K, thereby leaving just enough free memory for the game itself. Lander itself requires a minimum of 172K of application RAM, as the game takes up memory from &00008000 to &00032FF0, which is just eight bytes shy of 172K.
Here's the memory map for Lander:
+--------------------------------------+ &01FFFFFF | | | Screen bank 1 | | | +--------------------------------------+ &01FEC000 | | | Screen bank 2 | | | +--------------------------------------+ &01FD8000 | | . . . . . . . . . . | | +--------------------------------------+ &00032FF0 | | | Graphics buffers (12 * 4308 bytes) | | | +--------------------------------------+ &00026600 | | | Object map (256 * 256 bytes) | | | +--------------------------------------+ &00016600 = objectMap | | | &00016580 - &000165FC unused | | | +--------------------------------------+ &00016580 | | | Particle data buffer (484 * 8 words) | | | +--------------------------------------+ &00012900 = particleData | | | Variable workspace | | | +--------------------------------------+ &00012200 = workspace | | | Descending stack (128 words) | | | +--------------------------------------+ &00012000 | | | &00011A10 - &00011FFC unused | | | +--------------------------------------+ &00011A10 = end of divisionTable | | | Main game code | | | +--------------------------------------+ &00008000 = landscapeOffset | | | System workspace | | | +--------------------------------------+ &00000000
There isn't a lot of unused space in there, though there are some unused routines in the code, and a block of unused memory after the main game code and before the stack.