How I fit a bubble shooter into 3,810 bytes of C64 assembly

SPixs — Wed, 30 Sep 2026 21:01:38 +0000

Over the winter of 2020–21, Phoenix Ware and The RVG Squad ran The C64 'Cassette 50' Charity Competition, a tribute to Cassette 50, Cascade's infamous 1983 compilation of fifty games. The rule was simple and brutal: every game had to fit in 4 KB.

My entry was TinyBubbles, a Puzzle Bobble-style bubble shooter written in 6502 assembly. It won the competition. The whole game is a 3,810-byte PRG, with 286 bytes to spare.

You can play it in your browser, and the full source is on GitHub. Here is how it fits.

The budget: everything below $1000

The PRG loads from $0120 to $0FFF. That is the first 4 KB of the C64's address space, the part most programs leave alone because the stack, the system vectors and the screen live there. TinyBubbles moves in anyway and squeezes into the nooks:

The screen layout (map.bin) is loaded straight into screen RAM at $0400, and the custom charset goes right after it at $0800. What's left over is code, tables and a lot of creative recycling.

Starting without RUN

Loading at $0120 means the file overwrites the stack while it is being loaded. Instead of fighting that, the game exploits it. Two bytes placed at $01F8 overwrite the return address that the LOAD command will pull from the stack when the Kernal has finished loading:

// Modify the stack so that the load routine branches to our entry point after
// it has complete its loading.
*=$1f8 "Stack override"
    .byte <[Entry-1], >[Entry-1]

When LOAD finishes, its RTS "returns" into the game. You type LOAD"*",8,1 and the game starts. No RUN, and no BASIC stub wasting bytes.

There's a catch: the file also runs through pages 2 and 3, where the Kernal keeps its vectors (IRQ, NMI, the I/O routines, the keyboard decoder). So the PRG carries their default values at the right addresses. The Kernal keeps working until the very last byte is loaded.

A one-instruction main loop

Once everything is set up, the main loop is this:

mainLoop: {
    jmp *
}

The whole game (joystick, trajectory, collisions, popping, score, sound) runs in a raster interrupt at line 252, once per frame. The IRQ handler restores the registers itself and returns with RTI, so the Kernal's own interrupt routine (keyboard scan, cursor blink) never runs again. Nothing wastes cycles behind the game's back.

Let the hardware do the work

In 4 KB, every routine you don't write is a win. TinyBubbles leans on the chips as much as it can.

Collisions come from the VIC-II. There is no distance check between the flying bubble and the grid. The bubble is a sprite, the grid is made of characters, and the VIC-II sets a bit in $D01F the moment a sprite pixel touches a background pixel. The game just reads the register and snaps the bubble to the nearest grid cell.

Random numbers come from the SID. There is no pseudo-random generator. SID voice 3 runs white noise at maximum frequency with its gate closed (so it makes no sound), and reading $D41B returns the oscillator output. That picks the colour of the next bubble and the pitch of the "pop" sound.

Bubbles are characters, not sprites. A bubble on the board is four multicolour characters ($0A–$0D). Every bubble uses the same four characters, and colour RAM tints each one. Only the bubble you shoot, the crosshair and the two halves of the launcher are sprites.

The charset has 48 characters: bricks, frames, digits and just the letters needed on screen. Even that was trimmed: the "O" in SCORE and the "I" in HISCORE are actually the digits 0 and 1.

A hexagonal grid and a recursion on a leash

The board is an 8 × 10 grid, staggered like a honeycomb: every other row is shifted by half a bubble. It lives in zero page, one byte per cell: $80 means empty, otherwise the low bits hold the colour, and two more bits mark cells during traversals.

Two flood fills do the gameplay:

After a shot, find all connected bubbles of the same colour. Three or more pop.
Then find every bubble still connected to the ceiling. The rest falls.

Both share the same "visit the six neighbours" routine through an indirect jump, so the neighbour logic exists only once.

Recursion on a 6502 means the stack, and the stack is tiny. During initialisation it is limited to 32 bytes. Once the game is running, it gets the whole of page 1, including the space where the initialisation code used to be, since that code will never run again. And just in case, the recursion checks how much stack is left before going deeper:

recurseFunction: {
    tsx
    cpx #$06
    bcs !+
    rts // not enough space in stack... stop recurce !

!:
    jmp (functionVector)
functionVector:
    .word $00
}

Aiming and bouncing

The crosshair slides along a sine arc. The table isn't typed in by hand, the assembler computes it:

SINE_SIGHT_SCREEN_LOOKUP: {
.fill 32,round(26*sin(toRadians(i*192/32)))
}

When you fire, the vector from the bubble to the crosshair becomes a fixed-point velocity: 16 bits, shifted left by 5 for sub-pixel precision. Each frame adds it to the position. Hitting a side wall just flips the sign of the horizontal speed.

The small savings

A few more tricks, each worth a handful of bytes:

Levels are packed two bubbles per byte, one nibble each. A level is 24 bytes, unpacked into the grid when it loads. There are three levels, and they loop.
The score never gets converted for display. It is stored one decimal digit per byte, and since the charset's codes 0 to 9 are the digits, it is copied to screen RAM as-is. The level counter is even incremented directly in screen RAM.
Sprite images live in the tape buffer area ($0380 and $03C0), which nobody needs once the game has loaded from disk.
InitWindow modifies its own code: it rewrites the operand of its sta instruction to step down one screen row at a time.

Sound

Three effects, all driven directly on the SID registers:

a "pop": a triangle wave on voice 1 at a random pitch, taken from the noise oscillator;
an explosion: noise on voice 2;
a bell at the end of each level: voice 1 ring-modulated by voice 3.

Found again on a USB stick

I recently found the sources on an old USB stick. With KickAssembler 5.16, they rebuild byte for byte into the last build on the stick, from February 2021. The project is now open source under the GPL, with a detailed README and a browser version.

▶ Play it in your browser: https://spixs.github.io/TinyBubbles/
Source code: https://github.com/SPixs/TinyBubbles
itch.io: https://spixs.itch.io/tinybubbles

If you still have a real C64, LOAD"*",8,1 is all you need.

This article was written with the help of an AI assistant, then checked against the game's source code.

DEV Community: SPixs