Rocket Raid Under The Hood 3: Loading process

This is the third part in a series of posts on digging into the code of the Acornsoft side-scrolling arcade game, Rocket Raid.

Now that we have gathered together all the materials needed, we're almost ready to start looking at the code itself. But first let's take a brief look at the memory map for the BBC B.

The BBC B Memory Map

The Beeb's memory is laid out as per the following diagram (from the book "Assembly Programming Made Easy for the BBC Micro", by lan Murray). A standard machine has 32K of RAM, being the lower half of the diagram.

BBC Micro Memory Map

Location &E00 is the standard start of the area for BASIC programs to be stored, assuming the system uses only tape for external storage; this jumps up to &1900 with a disc system installed. 

&8000 represents the upper boundary for graphics RAM. The amount of RAM used for screen memory depends on the graphics mode that is used. For example, in the BBC's MODE 2 which supports display of all 8 colours at once, screen graphics take up a relatively huge 20K of memory (from &3000 to &7FFF), whereas in the efficient Teletext-based MODE 7, only locations from &7C00 to &7FFF are needed.

There is also a special area of 256 bytes at the start of RAM (from &0000 to &00FF) known as "zero page". Although small in size, it is special due to the design of the 6502 processor which can store and retrieve values more quickly than when using other locations in memory, giving programs a speed advantage. Zero page is available for use by machine-language programs when BASIC is not in use.

One technique used to counter the lack memory caused by the use of the disc filing system (DFS), for example, is to load into memory using a memory-friendly MODE such as MODE 7, and then once loaded relocate the code lower down to make use of the memory used by the DFS, knowing that disc access will no longer be necessary. This is something we will see that the Rocket Raid code does in order to squeeze itself into memory.

Examining the Loader

Let's have a look at the loading process after setting the Rocket Raid disc image in BeebEm, The loader for Rocket Raid consists of two small BASIC programs: RAID and RAID2.

RAID simply displays a loading screen, which consists of MODE 7 Teletext graphics, and then calls the second part of the loader:

100 PAGE=&5000:CHAIN"RAID2"

Rocket Raid loading screen

The significance of setting PAGE is that it allows the second loader program to be brought into memory somewhere that leaves enough room for the main game code that it will be loading in. It sits below the start of the screen graphics area for MODE 7, which has a very small screen graphics footprint starting at &7C00. 

RAID2 has a more substantial job. First it loads the compiled game code, stored as the file RAIDOBJ, into memory at location &2000:

400 *L.RAIDOBJ 2000

Address &2000 is high enough to avoid memory areas used by the disc operating system and the BASIC loading program itself. So how large is the game code? This can be found by running the DFS command *INFO at the BASIC prompt, which gives the following result:

> *INFO RAIDOBJ
$.RAIDOBJ    002000 003400 00269D 00C

The first number is the default load address, &2000. The second is the execution address of the code, &3400, and the third is the size of the file which is &269D bytes - i.e. the main game code is just 9K! (The last number represents the start sector on disk, which is not of interest).

However since the game will be running in MODE 2 the code will have to be moved to somewhere else in memory to avoid being overwritten by the screen graphics when the mode is switched. At its current position, the end address of the code (&2000+&269D=&469D) sits well inside the start of screen graphics memory for MODE 2 at &3000.

To achieve this, the next line of the loader copies the game code down to location to a lower place in memory, in 4-byte chunks.

410 FOR A%=&2000 TO &46A0 STEP 4:!(A%-&1200)=!A%:NEXT

The effective new start location is &2000-&1200=&E00, which is recognizable as the standard start of user memory for programs on a tape-based system.

But even once the code has been moved down, a quick calculation shows that the end of the code still runs over the screen memory boundary at &3000. This can be confirmed by adding the length of the code to its starting location, giving &E00+&269D=&349D. Any code that remains in this area runs the risk of being wiped out on a change to MODE 2.

This puzzle will be solved once we look at the start of the main game code to see how this is handled before making the switch into MODE 2.

Instructions page,
courtesy of the RAID2 loader

Finally, the RAID2 loader displays a simple Teletext page of instructions to the player on how to play the game, and then calls the entry point of the newly-relocated machine code:

1900 CALL&3400

(Since the instruction page is displayed by the loader program, once the screen is cleared it won't be available again for display later in the game. Instead, the game reverts to a high score table page when prompting the user to play again).

Next time we'll make a start on trying to disassemble the main game code itself.