OddThinking

To understand this geeky war-story, you need to know a little about the architecture of the Commodore 64 computer.

Architecture of the Commodore 64

The RAM of the Commodore 64 was divided up into sections.

• Bytes 0 – 1023 was used for a whole lot of registers that were used to configure the behaviour of the computer.

• Bytes 1024-2040 were memory-mapped to the 40×25 character screen.

  For example, that means that if you set (“poked”) the value 1 into byte 1024, the letter A value would appear in the top-left corner. If you poked 2 into byte 1064 (i.e. 1024+40 characters per line), the letter B would appear on the left hand-side of the second line.

• Bytes 2041-2047 were used to control sprites.

• Bytes 2049-32767 were used as space for storing your BASIC program code, in a very lightly pre-processed (tokenised) format.

All of this is from memory (no pun intended), so I apologise if it is slightly inaccurate, and I fear greatly that it might be right – why can’t my brain remember facts more useful to me?

The Task

Geoff and I were playing around with the development of a little tank-game – the genre where you get a top down view of two tanks that fire at each other, past obstacles. We were using character-based graphics, with a custom font that included a picture of a tank pointing up down left and right. We had programmed the tank to turn to each of the four compass points, and to move forward and backward. It was time to add the code that controlled the bullets.

The Bullet Code

We programmed the BASIC code for firing downwards: Set the memory associated with the appropriate location on the screen to the character representing a cannon shell. Add 40, and do it again. Blank out the original location, and repeat.

Time to test: We moved the tank, pointed it downwards, and fired. A shell fired out of the cannon, and neatly proceeded down the screen. We were overjoyed, until it reached the end of the screen, and we looked at each other, as realisation dawned: We hadn’t yet written any code to stop the bullet from continuing when it reached the end of the screen.

Aborting the code, we found to our horror that our fears were true. The bullet had proceeded past the end of the memory-mapped screen, skipped by the sprite data, and had continued to shoot a hole right down the middle of our BASIC code.