1986 · Micro Power

Doctor Who and the Mines of Terror

This minisite was contributed by air, unorig. It’s currently claimed by unorig who is editing it to reach a Gold tier standard.

Every sprite in the game, the TARDIS landing, one frame rebuilt from two screens, and a status bar whose font hides in its own screen.

The cast

Every sprite in the mine

The Doctor, Splinx, the controllers, the madrag, and every item, drawn from the bytes at $5000-$73FF in the colours the game gives them. Click one to see where it is stored and who shows it. The Gameplay tab says what each one is for.

Multicolour sprites in the colours the game gives them: the shared red and orange ($D025, $D026) and each object's own colour from $1850, for the object whose animation table or starting frame uses the image. Grey marks the few images no table names. The Doctor's own colour is black, which is why he shows only red and orange, as in the game.

The game's sprite images sit in the second 16 KB of memory, which the video chip shows during play, so a frame number from $40 to $CF points straight at 64 bytes from $5000 to $73FF.

At most eight objects appear at once, because the C64 has eight hardware sprites. Each pass, the game collects the visible ones and leaves out any ninth (sprite_list_add_object, $81DA).

Some items can be drawn into the scenery as well as flying as sprites. The game blends their shapes into 32 spare characters, pixel pair by pixel pair, so they sit on the rock without covering it (charobj_composite_char, $8652).

The Doctor

Two sprites, and a frame for every two pixels

The Doctor is drawn from two sprites, one above the other. Press a move to see the frames the game shows for it.

The lower sprite draws his coat and legs, and the upper one, eight pixels higher, his head and arms ($CB48). The frame comes from where he stands, not from a timer. Walking, the game takes his x position, keeps the lowest four bits, and halves them, so each two pixels of ground pick the next of eight frames. Facing left he uses a second table of frames, and as x falls he steps through it in reverse order (doctor_pick_frames, $CC4C). On a ladder his height picks one of four frames, a new one every four pixels ($CCBE). Carrying something, he keeps one upper frame with his arms full ($CC96, $CCB2).

The TARDIS

Landing in a shimmer of pixels

The game opens with the TARDIS arriving. Six sprites in a block of two by three shimmer over the landing place and thin out pixel by pixel until almost nothing is left. Leaving runs the same effect backwards.

The six sprites at the positions in $FC70, all showing one image ($7400) in the colours set at $FF2F. The image starts as one of two at $09E4; the second is used when the Doctor is high in the mine ($FE60).

Every fourth frame the game copies the whole image afresh and then clears some of its pixel pairs (arrival_frame, $FD1F). The pairs go in a fixed shuffle: 68 byte offsets at $09A0, each tried with one of five masks in turn, so every copy loses a different scatter of pixels (dissolve_sprite, $FEA9). Each image has 128 coloured pixel pairs. The number cleared starts at two, holds while a counter runs down, and then grows by three each time up to 125 ($FCAF), so the last copy keeps three. For the departure it starts at 127 and falls by three (departure_sequence, $FE23), so the shimmer thickens instead.

The same routine fades the Doctor when he loses a regeneration, on his own two frames ($CB6B), as the Regenerate button in the Doctor above shows.

The screen

One frame, rebuilt from memory

The first screen of the game, drawn by this page from the game's memory and the video chip's settings. Show the raster bands to see where the picture changes mode.

A reconstruction, not a screenshot: one frame recorded in the emulator, with every write to the video chip and the line it happened on, drawn line by line. It matches the emulator's own picture in all 104,448 pixels.

The picture is two screens in one. An interrupt at $8010 runs three times a frame and resets the video chip each time. From line 256 to line 78 of the next frame the chip shows the status bar, from memory bank 0 and screen $0400. From line 78 it switches to bank 1 and whichever of the two play screens is ready. The handler keeps its place in the frame in the offset of a branch at $8017, so each interrupt jumps straight to the next band's code.

The status bar

A font kept in the screen it draws

The status bar uses four rows of a 25-row screen. The other 21 rows are never shown: they hold the font the status bar is written in.

The game writes its own text in a private alphabet in which each letter is its ASCII code plus 155: A is $DC, Z is $F5, the digits are $F6-$FF, and $94 is a space. The video chip finds a character's shape at eight times its code from the start of the font. In the status band the font starts at $0000, so the shapes for $94-$FF sit at $04A0-$07FF, in the unused rows of the status bar's own screen.

As the game starts, it copies the screen and its own shapes from $4B00, then copies A to Z and 0 to 9 from the Commodore's character ROM into place ($48F5). One shape does not fit. The shape for $FF would be the last eight bytes of the screen's memory, where the video chip reads the sprite pointers. So the digit 9 is drawn with $F5, the code for Z, and the digit table at $1730 sends 9 there. The status bar never needs a Z.