The tape loads the game scrambled and then three small blocks: 43 bytes of loader into the printer buffer (LOADER), one byte, JP (HL), into NMIADD, and two into FRAMES. The loader sets bit 7 of the refresh register, unscrambles the game and starts it with interrupts off, for good -- there is no EI in the game, so FRAMES never counts again. The game then checks all three, each in its own way: START goes back to BASIC unless FRAMES' middle byte is $63; every object update, every table of routines, goes through a jump to NMIADD (DISPATCH); and at every new game STOCK_BUILDINGS checks R's bit 7, which only a program can set, and resets the Spectrum if it is clear. A copy made without the small blocks, or started any other way, fails one of them.

A fourth check is aimed at players. Before each new life NEW_LIFE reads the instruction that takes a life, and if it is not DEC (HL) it jumps to address 0: the usual infinite-lives poke resets the machine at the first death (run in the simulator; the pokes have a picture, and a poke that gets past it). Knight Lore, Alien 8 and Pentagram have nothing of the kind.

FRAMES has a second use: NEW_GAME starts the turn counter from it, $6334, at every game, and the menu counts it on once a pass (see waiting at the menu). The checks read from the code; the reset without R's bit 7 run in the simulator (the build's first simulator runs did exactly that until they took R from the snapshot).

There is no instruction that loads the number of lives. NEW_GAME reads the byte at LIVES_BYTE -- the opcode of the JR that closes the main loop, $18 -- and shifts it right twice: 6. The first life takes one as it starts (NEW_LIFE), so the panel shows five, and a game is six lives in all. A search for the number finds nothing, and a poke to the byte breaks the main loop. Whether it was meant as a guard is not known; it works as one. Read, and run in the simulator: LIVES was 5 in the first life and the sixth death was the game over.

The score is printed as seven digits (PRINT_SCORE_AT, in ADD_SCORE): the lower digit of SCORE's first byte, its next two bytes, and the byte after them, SCORE_ZEROS, which nothing adds to -- ADD_SCORE adds to the two bytes before it, and a new game clears it. So every score ends 00, and the points are really hundreds: a monster of graphics 64-79 adds 5 and shows as 500, a strike on one of 112-127 adds 10 to 25 (1000 to 2500), and destroying a villain adds 25 to the middle byte: 250000. Read, and searched: no instruction addresses SCORE_ZEROS.

The menu (MENU) goes round its loop about forty times a second, and every pass counts the turn counter on and stirs the random number with the refresh register (NEXT_TURN). The random number decides the knight's start cell (RANDOM_START_CELL), where the four objects and the four villains go (PLACE_OBJECTS, PLACE_VILLAINS, from bytes of the ROM that it picks), how many finds each type of building holds (STOCK_BUILDINGS), and much else; the turn counter decides when the creature first comes (every 256th turn) and which monsters head for the knight (those born in the first half of each 256). So how long the player waits before pressing 0 deals a different town. Run in the simulator: starting the first game after one to six passes of the menu gave six different start cells and six different sets of places for the villains.

Nightshade reads bytes of the Spectrum's ROM as random numbers, with the random number as the address: the objects and the villains are placed by pairs of ROM bytes as a column and a row (PLACE_OBJECTS, PLACE_VILLAINS), each building type's stock of finds comes from the ROM's first 4K (STOCK_BUILDINGS), and the puff of a thing vanishing is pitched by ROM bytes (PUFF_SOUND). The villains' hum reads the ROM too, though that was not meant (see the bugs). Read. On a 128K whose editor ROM has been paged in, all of these read other bytes (see the bugs).

Knight Lore, Alien 8 and Pentagram are rooms: a room is built into object records -- walls, blocks and doorways as well as what moves -- and every one of them is sorted by depth in three dimensions and drawn as a masked sprite; the screen flips to the next room at a doorway. Nightshade (Filmation II, as Ultimate called it) is a town of 32 by 32 cells (TOWN), a byte a cell for its type, and the view moves with the knight, who stays in the middle. The buildings are not objects at all: DRAW_CELLS picks, from what stands round him, which cells to draw and in what order, and draws their walls from tiles, the nearest first, each 16-pixel column of the screen taken by the first wall to reach it, so nothing behind can show there and nothing needs sorting. Only 23 records of 16 bytes are left for what moves (Knight Lore's are 32 bytes), nothing has a height -- nothing jumps, falls or stands on anything -- and the depth sort (SORT_AND_DRAW_THINGS) orders only the things within one cell, in two dimensions. Collision is with boxes kept for each cell type (BOX_TABLE). Read; see how the game is put together and the drawing, and, for Filmation I, Knight Lore's depth sort.

Little of the engine, and much of the frame round it. Compared routine by routine with the three other games' loaded code: READ_KEYS is byte for byte all three's; the tune player (PLAY_TUNE_ONCE, PLAY_TUNE, PLAY_NOTE) is instruction for instruction Alien 8's and Pentagram's, and its note table (NOTES, 61 notes of three bytes) is the same bytes as theirs and Knight Lore's; the menu (MENU) is Alien 8's with its own tune and random number; the pause (PAUSE) is Alien 8's without its beeps; the sprite turning (TURN_SPRITE) is nearly Alien 8's. The sound effects -- EFFECT_NOTE, FIRE_SOUND, CLICK, the ending's note (ENDING_BEEP) -- are Pentagram's, and BLIP_BY_TURN's blip and its 80 bytes of pitches are in Pentagram too, where the blip is never called: Pentagram, the later game, kept them from this one. The town, its drawing, the movement and collision, the monsters and the quest are Nightshade's own. See Alien 8's and Pentagram's reference pages (Alien 8, Pentagram).

The game's text -- the menu, the panel's heading and the lines after a game (END_TEXT) -- names none of the game's characters or things: not the four villains, not the four objects that destroy them, not the monsters or the creature. The listing calls them by their pictures and their graphic numbers -- the villain of graphics 108-111, say, and the object whose record lies 64 bytes before the villain's, the only thing that can destroy it (OBJECT_STRIKE) (see the quest). The names players know come from outside the game and were not checked against it here; which picture goes with which name is left open.