Endless - A dive into a C64 game

Posted on 07 Mar 2025
Tagged with: [ c64, game, 6502, assembly

Almost 40 years ago, in 1985, a game was released for the Commodore 64 called “Eindeloos” (“Endless”, in dutch). In this game you needed to find your way around a labyrinth while avoiding all kind of enemies and obstacles. The map was so huge, that it was almost impossible to finish the game. It truly was endless for most players.

I can’t remember that I ever finished the game, but since we are working on a C64 with max 64KB of memory, having an endless map was pretty much impossible (provided the map wasn’t generated on the fly, which for those days is a pretty safe bet that it wasn’t). So it had to be stored somewhere in memory. A few days ago, I stumbled upon the game again and decided to take a look if I was able to extract the map. With the help of a C64 debugger (retrodebugger), I dived back into the past with 6502 assembly and started to reverse engineer the game.

Finally, after some trail and error, I was able to extract the map:

Endless map

The map is 1024 by 512 petscii characters in size, so it must have some way of “compression” to store it in the 64KB memory. To do this, the map consists of 8-char wide 1-dimensional blocks (1 row of 8 characters). Since the screen is 40 characters wide, there are 5 of these blocks visible on the screen at the time, with 25 rows of blocks.

For instance, when the game starts, it will load the first row of the screen with the following bytes: 04 71 00 71 00

The first 04 points to a memory location where the first 8 characters can be found. These are placed onto the screen. Next, the 71 points to the next 8 characters etc. You see that the second and fourth block are pointing to the same set of blocks, while the third and fifth block point to 00. They will result in the same 8 characters. In total, we only need to store 3 (unique) blocks (04, 71 and 00) somewhere in memory.

Turns out that there are 128 unique 8-char blocks in the game, and they are stored in memory starting at 0x8000. Besides these blocks, we also need to store the colors for each block. These colors are stored in memory starting at 0xA000. Each character in a block has a corresponding color. So the character found at 0x8491 will have the color found at 0xA491. The first 4 bytes of the color byte are the actual color (0-15), while the upper 4 bits do other things (i’m not sure what exactly, but it seems like they define if an enemy can be spawned at that point, and other things).

To get from the index bytes to the actual offset of the blocks, we need to do some bit shifting and masking. It would be a lot easier if the 6502 could do 16-bit operations, but being an 8 bit machine, trying to figure out 16-bit addresses is a bit clunky. The actual “decyphering” code is a bit tricky to grasp at first, especially when the same loops are used for multiple purposes (copying the chars, and copying the colors), while doing some opcode and operand manipulation at the same time. I’d reckon this is a pretty normal way to work on such machines to make things fast and small enough to work.

In order to extract the map, i’ve written a small go program that reads a memory dump of the C64 while the game was playing in the debugger. This allows me to fetch the petscii characters (simply a single byte per scanline), and all the memory blocks. Step debugging the code in retrodebugger was a bit awkward but doable. At the end, i’m generating a PNG file with the map and the correct (c64) colors and it looks like the real deal! Notice that there is some junk at the bottom of the map which you cannot see (or reach)…

Consider that you can only see 40x25 characters at one time on your screen, and the map is 1024x512, it’s pretty impressive how they created such a big map without the tooling we have today. I know the programmer (John Vanderaart) is still around, so it might be fun to ask around how he actually created it back then.

If you want to play the game online: https://c64online.com/c64-games/eindeloos-nl/

I know there is another game from the same software house that is called “De grotten van Oberon” (“The caves of Oberon”) which seems like it’s using the same technique and has the same map characters. I might take a look at that one as well in the future.