Cassette 50 Charity Competition

10 BASIC program memory-saving tips

The main rule of the Cassette 50 competition states that the program must not access
memory addresses above $0fff, except for setting things like border colour, changes to
colour RAM, calls to BASIC or Kernal functions etc.

For BASIC programmers this makes things even harder because they don’t generally have
access to the 1,024 bytes below $0400 that an experienced C64 assembly programmer may
be able to utilise.

However, there are several tricks I used in order to save memory when creating the game
‘Circles’ that might be of use to anyone who might want to have a go at entering the
competition but does not know 6502 assembly. I am not an expert BASIC programmer by
any means, but here are a few that I have picked up from watching YouTube videos such as
8-bit-show-and-tell, and from the experience of making this game.

1) Don’t use spaces.

Readable code is out of the window, but spaces are not needed for the C64 to
understand instructions, and take up one byte each which soon adds up. Spaces
also slow the code down.

Therefore POKE 56, 16 : GOTO 50 becomes POKE56,16:GOTO50.

2) Cram as much onto one line as possible.

Each new line you use takes up more memory. If possible fill up each line to its
maximum of 80 characters rather than doing the next logical instruction on a new
line. This will also have the effect of making your game run faster.

3) Avoid strings if you can.

Strings take up a lot of memory. A fancy title screen (and the code needed to display
it) with detailed instructions would probably take up a quarter or more of your free
memory. For example I had to cut down ‘Time’, ‘Score’ and ‘Best’ to ‘T’,’S’ and ‘B’ to
make room for the code that would keep track of and display the high score. Keep
strings to a minimum and you can always add them at the end if you have room.
4) Use the ON keyword.

This can save typing a lot if/then/goto code where you want to branch your code in
more than two possible directions. I used it for my joystick handler, which would
return a value of 1, 2, 4, 8 or 0 for fire, which I could then use to branch to handle
code for each direction using:

‘ON X GOTO 75, 125, 50, 175, 50, 50, 50, 225’.
In this example line 50 starts the joystick check loop over again and others branch to
specific code for each direction.

5) Create reusable code.

If you have bits of code that do similar things, see if there’s a way that code can be
used as a subroutine that can be called from multiple points.

For example, in Circles, when a valid move is made the game needs to draw the
connecting lines, which may be to the left, right, above or below the reticle and may
be a horizontal or vertical line. Initially I had separate code for the four cases, but
improved this to store the required row and column in X & Y, and the required
graphics character to T$, and then use GOSUB to draw that character. Where CC is
the current column and CR is the current row of the reticle:

185 T$ = “-”:X=CC-1:Y=CR:GOSUB550 // draw a horizontal line to the left

225 T$ = “I”:X=CC:Y=CR-1:GOSUB550 // draw a vertical line above

500 POKE214,Y:PRINT””:POKE211,X:PRINTC$(G(CP))+T$:RETURN

G is an array of 36 grid positions containing their colour ID, and C$ is a string

containing the control characters for each of the colours.

6) Keep your idea small. No, smaller than that.

Circles is a very simple game, and is right up against the memory limit. Before that I
tried to create a more complicated puzzle game and just ran out of space to perform
the grid logic. Think of a simple mechanic, implement it, and then see how much
space is left to add new features or polish.
7) Use abbreviations to increase instructions per line.

Most instructions have an abbreviation that can be used in place of the full keyword.
For example, PRINT can be replaced with ?. Although the instruction takes up one
byte either way, it means more instructions can be squeezed into 80 characters,
which may prevent the need for another line.

However, it’s not a good idea to do this early on because when you LIST the
program, the ? will be replaced by PRINT and you will see the line is now more than
80 characters long. When you edit and submit the line, anything on the third row will
not be included so you will have to replace all the PRINTs with ? again. So this is
really to be used as a last resort when the code is working and you are trying to free
a few bytes for something else.

8) Re-use variables.

Before you use a new variable, consider whether there is another one already
defined that you can use instead. For example, I had X and Y variables for iterating
over columns and rows and A variable for iterating over a flat array. I found I could
use X in all the places I had used A because there was no overlap, saving the
memory cost from the allocation of the A variable.

9) Remove the variable names on NEXT statements.

The C64 does not actually need to know which FOR iteration variable the NEXT is
closing, it will work this out by itself. This will save one byte and be faster, again at
the expense of making your code less readable, especially if you have nested loops.

10) Use single-character variable names.

I did not actually follow this piece of advice very well but will do if there are any bugs I
need to fix in Circles and I need more bytes. This will give you 26 numerical variables
and 26 strings to work with, with each one used in place of the two-character variant
saving a byte each time it is used, and also making the code faster.

Once again this will make your code less readable, as SC is more recognisable as
something that might hold the score than ‘S’, but the bytes saved could lead to a
better game.

Finally the biggest tip of all, if you’re working on a real machine or TheC64 - SAVE YOUR
WORK OFTEN, just in case! On TheC64 you can use the save state function, but ensure
you have a .d64 image mounted before starting work and be careful not to press the wrong
button in the menu to load instead of save….