Aaargh!

01 · The title

Secret: hold 1, ←, CTRL, and 2 on the title to read a hidden list of names

The title writes a list of names at its top left all the time, in black on black. Four keys held together turn it white, and rename the monsters Myrtle and Dill.

The title with the four keys held: THE VENUE at the top left, and MYRTLE and DILL over LIZARD and OGRE. Taken in the emulator.

Numbers written with a $ are addresses in the computer's memory, in hexadecimal; each one links to the game's code on the Source code tab. Every 32 passes of the title loop (each waits two frames), the routine at $B13E copies the next eleven characters of a list at $9D9F to the top left of the screen, with colour 0, black, on the black background. Then $B161 reads the keyboard. The keyboard is read a row of keys at a time. The game never chooses a row, so it reads the one the machine's built-in program, the KERNAL, left chosen: row 7. When the four keys of that row's first columns are down together, 1, the left arrow, CTRL, and 2, it colours those cells white, and writes the names at $B347 and $B34D over the monsters'.

The list, read from the listing's bytes at $9D9F, eleven characters at a time as the title shows it.

Many of the names are bands of the 1980s and before: New Order, Suicide, Spacemen 3 (written with the font's own digit 3, where the rest of the list is ASCII), Led Zep and The The. The Haçienda was New Order's club in Manchester, and MACHESTER may be Manchester misspelt. The list's last characters, THE THE, are never shown: the place in the list steps by eleven and wraps round before it reaches them.

02 · A message

Secret: a message in the program that nothing reads

Next to the title's text is a sentence that no instruction in the game reads.

I'M AT PAINS TO SEE...SEE THROUGH THOSE WINDOWPAINS...SEE RENTBOYS AND GOTO 16384.

The 82 bytes at $B37D are plain ASCII. Windowpains and Rentboys are in the hidden list too. A BASIC programmer would read GOTO 16384 as a jump to address 16384, $4000, but there is nothing there to find: that address is inside the characters of the city in the cave.

03 · The volcano

Secret: the volcano is every fourth city, eggs or not, and the game never ends

The manual says five eggs take a monster to the volcano and its golden egg, the end of the game. On the C64 nothing counts the eggs.

The volcano, the fourth city of a round, reached in the emulator by ending three cities without taking an egg.

The only count the main loop keeps is the city's place in the round, at $803E: it goes 1, 2, 3, 4 and back to 1, and the picker at $8444 always makes the fourth city the volcano (The cities). The volcano's golden egg is drawn on its screen from the start ($87A1), and taking it leads to the cave like any other egg. Then the next round starts with a jungle village or a temple. There is no ending screen in the program, and nothing ends a game but both monsters dying.

04 · Two players

Secret: a second player can join with the other joystick

The manual gives the C64 version one joystick. Fire on the other port brings the other monster into a game that is already on.

Fire on port 1 during a game of the lizard's, in the emulator: the ogre walks in from the right.

The lizard reads port 2 and the ogre port 1, with one instruction for both (lda $DC00,x at $8A43). A monster that is out of the game joins on its fire ($8A94), once a game. Wikipedia says the arcade original took one or two players at once and the home versions one; this version kept the second. With only one player, the cave fight's other monster is played by the computer (The cave).

05 · The lightning

The lightning powers punches, not flames

The manual says lightning increases fire power, the damage the flames do. On the C64 it refills the bar that punches spend.

Taking the lightning ($91F4) sets the monster's punching power ($80ED) and adds to its second bar. Every punch spends a step of that bar ($92D6), and with it empty the power is cleared and punches knock no holes. The flames never look at it: a flame burns a building, a hornet or the cannon the same whether the bar is full or empty.

06 · An animation

Bug: one frame in four of an animation comes from the wrong table

Three animated characters show bytes from another table on one pass in every four.

Each pass, $B463 animates three groups of characters. For characters $93 to $95 it keeps a phase from 0 to 3 and copies 24 bytes from the table at $B4BF, reading backwards from 24 times the phase. For phases 1 to 3 that reads the table's frames. For phase 0 the index starts at 0 and wraps round below the table, so the three characters get $B4BF and the bytes at $B5A8-$B5BE, which belong to another table. The table has room for a fourth frame where a phase of 4 would read it, so the counter was probably meant to run from 1 to 4.

Measured in the emulator: the characters' bytes took the table at $B4BF + 1, + 25 and + 49 in phases 1 to 3, and in phase 0 the wrapped bytes, exactly. Where those characters appear on the screen, and so whether a player can see the wrong frame, has not been checked.

07 · A stray write

Bug: every pass writes a number into a city's characters

A variable that nothing reads sits in the middle of the city in the cave's characters.

The work of each pass ($8065) stores 0, 1 and 2 in turn at $3E7F, and no instruction reads it. That byte is row 2 of character $3E of the city in the cave's own character set. The set is copied to the screen's characters only when the city is built, so the harm is small: when the city in the cave comes, that row of its character $3E holds whatever number the last pass left.

08 · Leftovers

The program carries pieces of its earlier versions

The program carries pieces of earlier versions of itself.

A building burning down calls $9594 (at $9541). That address holds only an rts, the instruction that returns, and the routine right after it, at $9595, draws a row of roof characters over the building, as the fall does elsewhere. Nothing else reaches it. Pointing the call one byte short is a quick way to switch a routine off.

Further up, $B7B4-$BD5E holds an older build of the character animation, its tables, the city tables, and the interrupt helpers, assembled about $350 bytes higher than the ones the game runs. Nothing calls it or reads it. $2581-$2E77 holds an older set of the monsters' leg frames, on a grid of its own that no table reaches. Two short fragments of code (at $AD6B, a punch in the cave, and at $89D2) are reached by nothing too.

09 · This copy

The tape is the game frozen at its title

The copy analysed here is a crack, saved with a freezer cartridge and put back on tape.

The tape loads a BASIC line, SYS2075 TRILOGIC V3.1, the restart routine of Trilogic's Expert cartridge, which saved the whole running machine as one packed file. It unpacks memory, puts the chips back and returns into the game where it was frozen, a moment after the title started. The return addresses on the stack lead back to the game's own start, at $8009, and this analysis restarts the game there. Started that way, it reaches the frozen moment again with all of memory the same but for 170 bytes of working state. A second crack, by X-Ray, comes from the same frozen game: its trainer's screen says "THIS GAME WAS ALREADY FROZEN".