The disassembly is of the original tape, loaded the way a Spectrum loads it: SkoolKit's tap2sna runs the ROM's own LOAD and the tape's own loader on a simulated machine, and stops at ENTRY, where the loader enters the game, before the game has run a single instruction. That matters here: the game turns its sprites round in place as things face about, rewriting their bytes and the flags in their headers, so an image taken once it has run is no longer the tape. The tape holds a BASIC loader, the loading screen and four more blocks: the game, 34816 bytes loaded at 24576 ($6000); a 43-byte routine loaded into the printer buffer at LOADER; one byte loaded into the system variable NMIADD at NMIADD; and two into FRAMES at FRAMES. The BASIC ends with PRINT USR 23424, which runs the routine: it sets bit 7 of the R register, unscrambles the game block (each pair of bytes has a nibble swapped between them), moves it down to ENTRY and jumps there. All three of the small blocks are protection, and the game checks each: its start returns to BASIC unless FRAMES is where the tape put it (START), every object is updated through a jump to the byte at NMIADD, which the tape set to JP (HL) (DISPATCH), and every new game resets the machine unless bit 7 of R is set, as the loader left it (STOCK_BUILDINGS). The build does what the loader does to the tape's block itself and checks the result is what the snapshot holds.

Which bytes are code was found by running the game, not by reading it. The build plays it in SkoolKit's simulator -- with each control method and directional control, walking, turning, firing and turning the town round, pausing, in every cell of the town, and through staged scenes for game over, the bonuses, what is found in buildings, and the four objects thrown at the four villains and the ending that follows -- and records every address the processor fetches an instruction from. Recursive descent then follows the branches out of what ran, and the tables of routines the game jumps through (UPDATES and five smaller ones), inventing nothing. Everything else is data. The level data -- the town map (TOWN), the drawing order, the buildings, their boxes and tiles, the graphic table (GRAPHICS), the sprites, the fonts, the tunes and the game's text -- is laid out a record per entry from the game's own bytes each time the disassembly is built, so the game's design is never written into the repository's files. Each sprite's and tile's picture is drawn from its bytes the way the game's drawing code reads them. The listing reassembles byte for byte with sjasmplus, and the snapshot rebuilt from it is the one the tape made, byte for byte.

Everything from PRINTER_BUFFER to the top of memory. Below the game are the system variables, the loader's routine, what is left of the BASIC program and the game's stack, which grows down from ENTRY. Above the code are the screen buffer and its attributes (BUFFER) and the lookup tables the game builds (MIRROR_TABLES); the bytes the snapshot holds there are what the load left -- the tail of the game block, which the move down left behind, and zeros up to the ROM's user-defined graphics -- and the game writes all of it before it reads it.

No one else's disassembly of Nightshade was used. Nightshade shares the menu, the text printer, the tune player, the sprite format and parts of the drawing with Ultimate's earlier Filmation games, and where its code is theirs the names follow this project's own Knight Lore, Alien 8 and Pentagram annotations; the town, its drawing and the game's own routines are named from reading and running them. The pictures on these pages are drawn by the build from the game's own bytes.