#c64digger

Music and sound effects. I was lucky to work with Uctumi who created charming music and all SFX. As I have explained in my “Playing the memory tetris” post, Digger has 2 SID files that Uctumi created with GoatTracker. They contain the following subtunes:

SID1 located at $C000: MUSIC_POPCORN (main theme), MUSIC_DEATH (funeral march) and MUSIC_SUCCESS (level completed)

SID2 located at $A200: MUSIC_BONUS (bonus mode theme), MUSIC_INTRO, MUSIC_ENDING.

Now, music playback is the only Assembler routine in the game. It’s implemented with the global sid_index variable and the play_popcorn() function. To start playing e.g. MUSIC_SUCCESS, I am calling sid_index = 2; play_popcorn(). The function sets the subtune index and points the raster interrupt (happening at line 40) vector at int_music or int2_music function, depending on sid_index. These interrupt handlers simply jump to SID playing routing from SID1 or SID2.

For SFX playback, each subtune has also GoatTracker’s SFX player built in. There are functions play_sfx_eat(), play_sfx_gold_broken() etc. that point AX to SFX binary data and jump to SFX playing routine of SID1 or SID2, depending on which music is currently playing, for example:

.proc _play_sfx_eat_gold lda _sid_index ; Check which SID is active. cmp #03 bmi sfxeatgoldbank_1 lda #<(_sfx_eat_gold_data) ; Load SFX address. ldy #>(_sfx_eat_gold_data) ldx #14 ; Always use voice 3. bmi sfxeatgoldbank_1 jsr sid2_play+3 rts sfxeatgoldbank_1: lda #<(_sfx_eat_gold_data) ldy #>(_sfx_eat_gold_data) ldx #14 jsr sid_play+3 rts .endproc _sfx_gold_fall_data: .byte $00, $F8, $00, $D2, ...

Let me actually explain how Digger is built and the rationale for some decisions.

Digger is written in C with cc65 for an obvious reason: I don't know the 6502 assembly well enough, and will hardly manage to learn it better anytime soon. Plain assembler is used only for music & sound effects playback because they are controlled by a raster IRQ which can hardly be implemented in C.

Levels data. There are 14 2D 15x10 arrays filled with map elements (MAP_EMPTY, MAP_EMERALD, MAP_GOLD etc.) They are stored in a binary file sized 2100 bytes that is loaded into $B300 by the linker. These layouts 0-13 are repeated throughout levels 0-253 as follows: 0-1-2-...-12, then 7-8-9-...-12, then 3-4-...-12, 3-...-12, etc. until 253. The level 254 (displayed as 255) is special because its layout #13 arranges emeralds in the “HOKUTO” word (game is released by the HOKUTO FORCE group):

From my previous post you know already that I have thought of characters forming the maze “grid”, and sprites that can move freely in it. C64 can display 8 sprites at a time (if you need more you need to implement something called “sprite multiplexing” yourself). There are 16 registers (0xD000 - 0xD00F) to store X and Y coords of each sprite, and 1 extra register 0xD010 whose bit i is 1 if sprite i’s X coord > 255. So to move sprites around and at the same time to know in which maze tile they are I invented the following coordinate system:

Each object has X and Y coordinates that correspond to X and Y indices of a tile where it’s located, and also X_OFFSET and Y_OFFSET that store offset from a tile top left corner, in pixels, measured between -15 and 15.

When Digger moves right, its X_OFFSET increases. When it becomes 16, its X increments and X_OFFSET becomes 0. Correspondingly when Digger moves left, its X_OFFSET decreases. When it becomes -16, its X decrements and X_OFFSET becomes 0.

This turned out to become a fundamental design mistake. Problem is, such coordinate system allows storing the same “physical” position of sprite (in screen pixels) in multiple possible ways. Assume on the picture above that X_OFFSET = 9, Y_OFFSET = 2. Then all following positions are valid and represent the same position of Digger on screen:

X=1, Y=1, X_OFFSET=9, Y_OFFSET=2

X=2, Y=1, X_OFFSET=-7, Y_OFFSET=2

X=1, Y=2, X_OFFSET=9, Y_OFFSET=-14

So when I need to check for collisions (e.g. whether a falling gold bag has hit the Digger) I have to check all possible combinations of logical coordinates instead of simply checking the physical pixel coordinates!

Let’s have a deeper look at Digger’s charset. A short explanation: Digger is a Multicolor Character mode game like Boulder Dash, so the entire setting is composed from 8x8 characters that form 2x2 tiles. We need 4 characters to draw a gold bag (2 in a row arranged in 2 rows), 4 characters to draw an emerald and so on. This is the complete set of characters that I have drawn:

(Of course a character can only reside within the 40x25 grid, so in order to have smooth movements of Digger, monsters, bullet etc. - unlike Boulder Dash :) - we also need sprites which I’ll talk about some other time).

I kept Digger source code on GitHub from the beginning. It was convenient to work on it when I had time from my both home computers or remotely.

On Feb-26 I recorded this video run of my early Digger work-in-progress code and put it on my YouTube channel that had almost zero traffic:

My problem was to arrange all data I needed for the game into the available memory. C64 has 64K of RAM but what’s available to an app is in fact less. 

As I was creating more GFX for Digger, I also needed more memory to store it. I had absolutely no idea how to do it, or how others do it. My attempts to define a linker memory configuration failed so I have chosen the most simple approach I could think of:

I created the charset.c module with a looong array containing bytes for chars forming game tiles

also I created the sprites.c module with another array containing sprite bytes

in the beginning of game’s main() function I was memcpy’ing both arrays where they actually had to reside: charset array to 0x8800 and sprites array - to 0xA000.

Fancy exploring some GFX I created for Digger? Here are all Digger sprites: