A 1980s BASIC game hid machine code inside a comment. It took 40 years to explain why

Gibberish that was never meant to be read as text

The opening line of The Wizard's Castle, a 1980s dungeon-crawler for the Exidy Sorcerer microcomputer, reads 10 REM"_(C2SLFF4 — a BASIC remark statement, the line type explicitly meant for human-readable comments the interpreter ignores at runtime. Except this one isn't readable, and it isn't ignored in any meaningful sense either: the bytes inside that REM statement are executable Z80 machine code, not text, and the game depends on them running correctly to function at all.

Exploiting how the interpreter stores its own source

The mechanism hinges on a detail of how the Sorcerer's BASIC interpreter worked internally: when BASIC tokenizes a program, it stores the source — including the literal contents of REM comments — directly in RAM, in a fixed, predictable layout. The game's author worked out that the REM statement's content would land precisely at memory address 474 — exactly the address a subsequent USR(0) call in the program was set up to jump to and execute as a function. A POKE sequence early in the program builds a small trampoline pointing at address 474, then the USR(0) call jumps there and starts executing whatever bytes happen to be sitting in RAM — which are, by design, the "comment" from line 10. The non-ASCII, non-printable bytes inside the REM statement (values like 0xED and 0xF7 turning up in the analysis) aren't characters at all; they're legitimate Z80 assembly instructions, compiled by hand and smuggled into a spot BASIC's own tokenizer was guaranteed to preserve untouched.

What the hidden code actually does, once it's running: it reads the Z80 processor's R register — an internal register that increments automatically with every single instruction the CPU executes, as a side effect of normal operation — filters out any zero values it returns, and writes the result to a specific screen memory address, using it as a cheap, fairly unpredictable seed for the game's pseudo-random number generator. On 1980s home hardware with no dedicated entropy source, tapping a register that changes constantly just from the CPU doing anything at all was a genuinely clever way to get randomness that didn't cost a single byte of explicit RNG code — the seed generation is folded entirely into a comment nobody was supposed to read as anything but a comment.

Why it had to be a comment, not visible code

The deeper reason this trick exists at all, rather than the author simply writing the machine-code bytes as a normal DATA statement, comes down to how 1980s BASIC games actually reached readers: printed as text listings in computer magazines, typed in by hand by thousands of readers on their own machines. Typing raw non-ASCII machine-code bytes from a printed magazine page using a standard keyboard was close to impossible — there was no clean way to represent unprintable byte values as characters a reader could type back in. The REM-statement trick sidesteps that entirely: whatever garbled sequence of symbols the magazine printed, as long as a reader typed it back in exactly — likely using special Graphic+Shift key combinations the Sorcerer supported, or by hand-POKEing the bytes in after typing placeholder characters — the tokenizer's RAM layout guaranteed those bytes ended up at address 474 regardless. It's a solution built entirely around the printing and typing constraints of its era: elegant precisely because it had to survive being copied by hand, by strangers, off a magazine page.