Even though the Commodore 64 is a powerful machine with a blisteringly fast one Megahertz CPU and a gargantuan 64 Kilobytes of RAM, these resources are not infinite. So a little care and planning is still required.
Single file load
I want everything to be in a single file that can be loaded in by the C64 in one go. This is a little arbitrary, but it provides a nice creative constraint and saves a lot of faffing about with bank-switching (for cartridges) or on-the-fly loading from disk or tape.
The end product will be a .prg file that can be loaded in an emulator, or from tape or disk on a real machine.
Maybe I’ll figure out how to produce a .crt cartridge image too.
Memory map
The C64 has got 64K of RAM, and that’s as much as the 6502 can directly address.
But there’s also BASIC and Kernal ROM and the registers for the VIC-II, SID and CIA chips, which all need to be mapped into that 64K address space.
So some areas of address space have multiple uses, and bank switching is used to say which things are visible at any one time.
To take an example, the area starting at location D000 (in hex) is used for RAM, character set ROM and for registers used to control graphics, sound and I/O!
Here’s a rough memory map of the C64 (addresses in hex):
0000 zeropage
0100 stack
0200 assorted kernal and BASIC data
0400 1K RAM (default screen memory)
0800 38K RAM
A000 8K RAM | BASIC ROM
C000 4K RAM
D000 4K RAM | VIC-II, SID, I/O, Colour RAM | Character ROM
E000 8K RAM | Kernal ROM
Memory availability
Because BASIC is effectively the operating system, I’ll be relying on BASIC to load and run the game (i.e. LOAD "*",8,1).
The free application space for BASIC starts at from 0800. BASIC is smart enough that it should be OK loading data all the way up to E000, where the Kernal ROM starts. But I’m planning to use from C000 onward for graphics, so we’ll use that as our upper limit.
That means we can load our code + data in to RAM from 0800 up to C000, which gives us a limit of 46K.
For comparison, I’ve scaled down this cat picture to be 46KB:
(source)
That’s the maximum size of this game.
In theory I could be a bit more cunning with decompression and overlapping areas of memory and squeeze some more space out… but I think you quickly get into the realm of diminishing returns. Maybe at the end there’ll be some killer feature I just have to include, and then I’ll have be a smart arse to jam it in. But for now, I’ll keep things simple. Well, simpleish.
Memory budget
Within that 46K, I’m planning to break it down like this:
8K map data (compressed)
6K misc graphics (uncompressed)
4K sprite data (compressed)
4K music/sound
18K code
I’m looking at about 25 rooms in the map, so 8K gives us a budget of 328 bytes of compressed data per room, which should be plenty. Some rooms will use more, some less.
There’s a bit of wiggle room there, but I think that’s a fair first memory budget.