I tried not to write an emulator
How the curriculum came first, why the emulator became inevitable, and what an LLM has to do with any of it.
For an earlier version of Code Like It’s 198x, I was producing every screenshot, every clip of video, and every snippet of audio by hand. Four target systems. Each tutorial needed dozens of artefacts. I’d boot the emulator, run the program, alt-tab to a capture tool, screenshot, paste, label, file, repeat. After a couple of weeks of this, the obvious question started looping: is there a way to automate it?
It turns out that scripting a retro emulator is harder than it should be. Each of the four emulators I chose supported it differently. One had no scripting interface at all - you drove it with your hands, or not at all. One let you trigger screenshots from the command line, but not video, and not audio. One accepted keypress injection at startup, but with no way to delay it, so every key arrived in the same frame - which is no use to anyone teaching how to type a BASIC program.
I sat with this for a while. Cobbling together four different scripting harnesses, one per emulator, sounded like the kind of work where you finish in six months and still don’t have a curriculum. Writing my own emulator from scratch sounded, on paper, like more work. In practice, with a single consistent target and one set of decisions, it was less. Honestly, I really did try to avoid it.
That decision opened Pandora’s Box. But instead of evil being let out into the world, what came out was the sheer complexity of what I had taken on. Cycle-accurate emulation of even one 8-bit machine is a substantial undertaking; doing it across multiple systems with a consistent architecture is several. I have started over from scratch at least three times. The current Emu198x stack - which will be released as open source - is largely cycle-accurate, scriptable via JSON, and lately scriptable via MCP, which means an LLM can drive it directly. The original requirement (automate the screenshots) is now incidental to what the thing can do. To be clear, these emulators are not yet at the same level as the established players in the field, from which I’ve drawn inspiration along the way; those other emulators have taken years, if not decades, of continual effort to get them to where they are today, and we all owe their authors a great deal of gratitude.
But this isn’t really a story about emulators, exactly. The emulators are infrastructure. The thing they exist to serve is: a curriculum I have been wanting to write for years, and have only recently worked up the nerve to start.
I have always really, really wanted to make my own games. Not in the modern sense, where you wire together a physics engine, a renderer, an input system and an asset pipeline that someone else built, and the game is the thin script you write on top. In the older sense - where the game is the code, where you can (mostly) read every line of it, where you understand exactly what happens when you press a key because you wrote the bit that translates the keypress into a register read.
The trouble is that modern engines are stacked so deep that learning from them is genuinely hard. You can’t see what’s happening because layers of abstraction are hiding it from you. Going back to 198x hardware is the cleanest way I know to put yourself somewhere you can see all the way down. There is a CPU, there is memory, there is a video chip, there is the screen. Nothing in between is hiding the parts you need to understand.
I am not qualified in any formal way to teach this, and I want to say that out loud rather than pretend otherwise. I have learned an enormous amount since I started, and the plan is to keep learning out loud, documenting the journey, so that anyone else who wants to follow the same trail can. We can get there, together.
There is a thing I should say plainly, because if I don’t say it here, the wrong version of it will eventually be said for me:
Code Like It’s 198x and Emu198x have been built substantially with LLM assistance. Realistically, neither would exist at this scope without it. A multi-system cycle-accurate emulator stack, a curriculum that spans dozens of target machines, and a reference archive that ties them together - that’s team-scale work. One person doing it in a few years is only possible because the available tooling for one person has shifted under our feet.
I expect some readers to bounce at that paragraph, and I would rather they bounce now than later. For the readers who would like to know how I square it with the project’s other commitments, here is the honest answer: the commitment is not to hide the hardware. The LLM does not hide anything. The emulator is cycle-accurate against the same kinds of conformance tests every other emulator uses. The curriculum is human-authored - every decision about what to teach, in what order, with what framing, is mine. What the LLM compresses is time: the months that would otherwise go into extracting facts from datasheets, organising reference material and untangling the dependencies between lessons. The work product is the same depth either way. The LLM is what made it possible to exist at all.
The MCP integration on the emulator side falls out of the same instinct. If LLMs help me build the project, they should be first-class users of it too. A reader who picks up Emu198x and drives it from their own Claude or Cursor session is doing the same thing I do. There is no move I can make that they cannot. That feels right.
There is a third leg to this, beyond the emulator and the curriculum, and it’s the part I’m most quietly excited about. The Vault is the reference layer of the project - an encyclopaedia and knowledge base that documents the twists and turns and interconnections between the machines, the people, the games, the publishers, the scenes. The same instinct that drives the emulator (see all the way down) and the curriculum (see all the way down) applied to history: trace the lineages, do not accept the surface story. The Spectrum-clone diaspora across Brazil, Bulgaria, Spain, Czechoslovakia and the Soviet Union belongs in The Vault. So does the lineage that connects the machine I’m writing this on to the machines I am teaching you to write code for.
Briefly, since I find this almost too neat: Chris Curry worked closely with Clive Sinclair for thirteen years - first at Sinclair Radionics, then at Science of Cambridge - before a disagreement about which microcomputer to build next sent him off to co-found, with Hermann Hauser, what became Acorn Computers. Acorn went on to design ARM, originally as a chip for their own (woefully underappreciated) machines and now the dominant CPU architecture on the planet. The MacBook Pro I’m writing this on runs on Apple Silicon, which is ARM. The line from the rubber-keyed Spectrum on a shelf to the laptop on a desk is shorter than it looks: it runs through a small group of Cambridge engineers who fell out, struck out and built parallel computing dynasties in the same town.
Code Like It’s 198x is a curriculum teaching modern developers to write games for retro hardware, currently in early-stage development. This newsletter is its monthly editorial companion — for more, see code198x.com.