A 1988 cassette tape, taken apart one instruction at a time. All 42,645 bytes of the game are accounted for.
The game in numbers
Only 11% being code doesn't mean anything is missing: this game is 89% data. The graphics, six level strips of 256 columns each and their parallax backgrounds.
What turned up when we took it apart
The game loads on top of the ROM
A 64 KB MSX doesn't have 64 KB within reach: the bottom page, 0x0000 to 0x3FFF, is occupied by the BIOS ROM. The usual move for a tape game is not to bother and load from 0x4000 up.
Ale Hop! does the opposite. It puts all 42,645 bytes into page 0, on top of where the BIOS lives, then moves three chunks up into high RAM and covers what's left with the ROM again. The 35 KB of graphics and maps spend nearly all their time hidden under the BIOS; the game uncovers them for an instant each time it loads a level and covers them straight back up.
It's the decision that shapes everything else, including why this disassembly is five listings instead of one.
A message almost nobody got to read
Clear the sixth and last level and a text scrolls past. The screen framing it has two empty boxes: the text isn't drawn anywhere. It sits in ASCII at 0xC3F0, and a routine reads it letter by letter, pulls each glyph's bitmap back out of video memory, and shifts it one pixel per frame.
The sign-off advertises another game Topo Soft had published the year before, which in turn ended by pointing at this one.
Parallax in one instruction
The background moves four times slower than the track. Both blit routines read the same camera-column variable, but the background's does an and 0x3F on it and its map is 64 columns wide, while the track's uses the whole byte over a 256-column map. That's the entire trick.
135 bytes that never execute
Four stretches of perfectly coherent Z80 that no path reaches. Among them a full-screen colour effect that turns every black into transparent — 3,673 of the screen's 6,144 colour bytes — which only makes sense paired with a change of backdrop colour. Half a fade that got left out.
Also in there: the sound library's own interrupt handler, sitting unused because the game has its own. That's the best evidence the music player arrived as a reusable library rather than as code written for this game.
Room for two levels that don't exist
Background maps are located with 0x3000 + level * 0x200. There's space for eight, but only six have data: the 1,024 bytes levels 7 and 8 would occupy are 0xFF filler, and the loader stops at the sixth.
The six levels
These aren't screen captures. They're drawn from the game's own data: decompressing the graphics with the routine the game uses and assembling the maps. Each level is a 256-column strip of which only 32 are ever on screen.
Level 1·0x0000
Level 2·0x0800
Level 3·0x1000
Level 4·0x1800
Level 5·0x2000
Level 6·0x2800
How it was done
The game's own loader was used as the decoder: rather than reimplementing Topo Soft's turbo tape format, the original tape is loaded in openMSX and RAM is dumped at each stage. What comes out is exactly what the game sees in memory — and it matches the bytes extracted from the tape file, byte for byte.
From there the code is traced by following control flow from the entry points, never by disassembling linearly: 35 KB of graphics decoded as instructions would throw everything out of alignment. Regions known to be data are declared off-limits, because one bad seed sends the tracer into the artwork and inflates coverage with nonsense.
Two separate checks guard the result. Reproducibility: every listing reassembles to the original binary, byte for byte. And a budget: every byte must be either traced code or a data range named in the notes. The second one exists because the first can't see misinterpretation — if graphics get marked as code, the bytes still come out identical and only the listing lies.