The Fourth Protocol

01 · The game

Three games on one disk

The Fourth Protocol turns Frederick Forsyth's novel of 1984 into three games, one for each stage of the plot. You are Preston, newly made head of the section C1(A).

In episode one, The NATO Documents, you sit at Cencom, a screen of icons, for forty days. Memos and reports arrive, the telephone rings, and you decide whom to watch and what to act on until you can name who is leaking NATO's papers. Episode two, The Bomb, sends you across London and beyond, again with icons, to find where a nuclear bomb is hidden. In episode three, The SAS Assault, you type commands in a single room to defuse it.

Each episode loads on its own from a menu after the title, so any of them can be played first. The manual asks for them in order, and episode three will not start without a code word found in episode two.

02 · The title tune

Music: David Dunn's title tune

The tune plays while the title picture waits for SPACE. It lasts two and a half minutes, then starts again.

The tune is a stream of bytes from $C389. A raster interrupt, a call the video chip makes each time it reaches a chosen line of the screen, runs tune_play once a frame from line 252 (title_irq, $413F). Every routine the tune can call sits in the 256 bytes from $CD00, and each command byte is the last two digits of its routine's address. The player writes the byte into a JMP instruction at tune_dispatch and jumps, so the commands need no table: command $53 is the routine at $CD53.

Every step lasts 17 frames, and each note's gate goes off three frames before the step ends, so the notes never quite join (tune_step_length). Within a step, tune_effects makes two voices warble: voice 2 flips between its note and the note plus $30 every fifth frame, and voice 3 between its note and the note plus $40 every sixth. The filter, its resonance at full, works on voice 2 or voice 3 by turns, and its mode and cutoff change as the tune goes on. The stream is 438 steps long, 7,446 frames. That is 2 minutes 29 seconds on a European machine, and then command $82 sends the player back to the start.

03 · One frame, rebuilt from memory

Cencom, drawn by an operating system of the game's own

Episodes one and two never print a character the Commodore's way. Everything on the screen is drawn into a high-resolution bitmap by a small operating system that the game keeps in the memory under the Commodore's own.

The operating system, the file XXXMYOS1, copies itself to $EB00-$FFFF, the memory under the KERNAL (the Commodore's own operating system in ROM), and the game then switches the KERNAL out of sight. It keeps one picture of 320 by 200 pixels, a bitmap at $2000, with a byte of colours for each 8 by 8 cell at $0C00. Its background is a pattern of white and black stripes (clear_screen).

On that picture it keeps two lists. The 16 windows are rectangles of cells, each with a double frame, black outside and white inside; windows 8 to 14 save what they cover and put it back when they close. The 32 icons are pictures, one bit to a pixel, placed in a rectangle of cells inside a window or on the whole screen (window $10). The pointer is two sprites, small pictures the video chip draws over the screen by itself: a shape and its black outline. In episode one it is a yellow hand, and SPACE moves it from icon to icon.

04 · The operating system

25 of the operating system's 87 calls would crash the machine

A program asks the operating system for something by calling $EC00 with the number of what it wants in the accumulator, the processor's main register.

Some functions take what they need from the bytes that follow the call: a window's position and size, or an icon's picture and colour. The function then returns past them (os_inline_args). Thirteen of the numbers have no function, and their entries in the table are zero, so a call would jump to address 0. Twelve more lead to JMP $FC00, eleven of them at once and function $03 by way of draw_to_second_bitmap. $FC00 falls in the middle of another instruction, so the processor would run on through bytes that were never meant as code (os_dead_stub). Functions $03 and $21 were meant to send the drawing to a second bitmap at $C000, which was never finished. The game is safe from all 25: each of its 335 calls names its function with a number written into the code, and every one of those numbers has a working function.

05 · Text

Every memo, packed four bits at a time

Episode one is mostly reading: 46 memos, 16 reports, the watchers' situation reports (sitreps), and the Blenheim files, which a telephone call with the code of the week releases. They fit on the disk because each word is stored as a number, often in just four bits, half a byte.

A text is a run of four-bit codes, read from the low half of each byte first. The thirteen commonest things in English text, the space, eleven letters and the new line, take a single code each. Two codes give the rest of the letters and the commonest short pieces, and three codes give one of 256 whole words. The words themselves sit in a dictionary of 301 at $96D0, and the game finds word number n by counting n zero bytes from its start (find_dictionary_word).

Episode two packs its texts the same way with a dictionary of its own (dictionary at $C91C in its listing). Episode three, written by another programmer, keeps its 188 messages as plain capitals.