Time Tunnel

01 · Persia and Salem

Bug: the basket's lid moves Salem's piece of the scripture

Putting the lid back on the snake's basket in Persia writes its position into another object's record. Which object depends on what else lies in the room.

Every object has a number, and the game keeps its position in two tables in memory, one byte per object: its x in the table that starts at address $076E, and its y in the one at $07D7 (a $ marks a number in hexadecimal, base 16). An object on the screen also has a sprite, one of the eight pictures the video chip moves over the screen by itself, and each sprite has a number of its own.

The lid (object $35) put down against the basket is set back on top of it, at x $1E, y $6B (persia_lid, $1CA1). The code writes those two numbers to the lid's sprite, and then into the tables at $0772 and $07DB, counting along by the lid's sprite number. Those addresses are four bytes into the tables of x and y, so the position goes to object 4 plus the sprite number, not to the lid.

The lid's sprite number depends on the room. room_enter hands out sprites from 7 down, in object order. At the start of a game the room holds the lid and the basket, so the lid gets sprite 7, and the position lands on object $0B, the scorpion in the gold rush. The game sets the scorpion's height again whenever the gnome enters the gold rush, but keeps the new x, so the scorpion starts 20 steps further left. The walkthroughs have the player bring the lamp into this room (object $33, lower than the lid), and then the lid gets sprite 6 and the position lands on object $0A: Salem's piece of the scripture. It has not appeared yet, and when the gnome lifts the rock on Salem's hillside the piece shows where its record says, 14 steps left and 3 lines up from where the game put it.

Both were tried in the emulator. With the lid set against the basket for one frame, the scorpion's record went from x $32, y $9C to $1E, $6B; with the lamp in the room as well, Salem's piece went from $2C, $6E to $1E, $6B. The lid still lies on the basket when a game starts, but not touching it by the game's own test, so the bug waits until the player takes the lid off and puts it back.

02 · The closet

The closet lets the gnome leave with four objects in it

The game's description says the closet stores up to eight objects. With five lying in it, the gnome cannot leave.

Before the gnome leaves, closet_pass counts the objects lying in the closet, not the one he carries. Each object adds one. Every object has a byte of flags, eight on-off settings, and an object whose bit 6 is on puts the count at five instead, and only the seven pieces of the scripture have that bit. With five or more, he stays. So the closet keeps four objects at most when he wants out, and never a piece.

The torch starts in the closet and counts as one of the four. A piece of the scripture left in the closet keeps the gnome in with it until he picks it up again.

03 · Leftovers

Secret: the developers' notes and another computer's code

Three stretches of the program hold things nobody was meant to see: a line of source code comments, code for a different processor, and a word from a disk tool.

The program ends with 86 bytes that nothing reads (source_fragment). The first 52 are text, with the line ends of CP/M and MS-DOS, the operating systems of the business computers of the time: "ments if he will move outside entire screen", a line holding only a semicolon, and "whol". They are the end of a comment in the game's source, still in memory when the file was saved. The rest are code for the Z80, a different processor from the C64's: they read and rewrite the addresses kept at 1 and 6, which on a CP/M computer are where its programs jump to restart and to call the operating system. So the program was probably put together on a CP/M machine, and its last bytes came from that machine's memory.

The throne room's character set unpacks to 129 characters (throne_charset). The last eight hold no pictures, and among their bytes is the text "Bytes/sector:", the kind of label a disk utility prints. The set was most likely saved from memory that such a program had used.

The program's first nine bytes, at $0900, are the start of a cartridge: two addresses of the game's start, $0CDA, and the letters "CBM80" that the C64 looks for when it is switched on. The C64 looks for them at $8004, so here they do nothing (cartridge_header).

04 · Unused pictures

Pictures the game never shows

A few frames and two whole objects are drawn and stored, and never appear.

Medusa's two halves (objects $56 and $57) have three frames each, and a fourth is stored after them. The burning dynamite ($34) has four, and a fifth follows. The objects' frame counts never reach the extra frames, and no code sets them. Objects $46 and $47 are thin dark shapes with a place in every table, but they start nowhere and no code names them. The basket's lid has a third row of picture that is never copied into its sprite.

05 · Sound

Bug: two warbles that are one

The sound effects have two warble commands, 9 and $A, and each loads a different amount. Both do the same thing.

Command $A loads $80 and command 9 loads $40, and both go on into the same code (sfx_cmd_warble, $BB82). The pitch is a number too big for one byte, so it is kept in two, a low byte and a high byte. The next instruction subtracts the pitch's low byte from itself, which leaves $FF (255) whatever the pitch was, and stores that over the amount. So the amount is never used, and each warble step lowers the pitch's high byte by one. The trip in time (effect 3) uses command 9 and the teleport (effect 4) uses $A; they warble alike. Both are on the How it works page's effects player.

06 · The controls

The controls' screen runs into the hidden row

The time machine's controls are the one room whose packed screen does not stop at 960 cells.

The screen is in 24-row mode, so the 25th row of characters is under the border. The controls' packed screen (controls_screen, $40AA) has no end marker where the other rooms have one, and runs on for 11 more cells into that row. In the emulator the hidden row held 0E 7F 00 0B 02 06 03 7B 19 19 7F after the controls were drawn. Nothing shows, because the border covers them.