How 198x uses AI

I use AI throughout 198x. It writes almost all the first drafts of the code and lesson prose. I set the direction, develop the teaching approach, guide the architecture and review work through GitHub pull requests before publication.

That is a substantial contribution from AI, and I want to be clear about it. It makes projects feasible that I would otherwise be unable to commit to because of the amount of work involved.

I want people to be able to learn about and write code for dozens of historical machines. That means making the machines understandable and giving readers a practical way to experiment with them. A lesson needs working examples. Those examples need tools. The tools need to run on the computers readers actually own.

I tried hard to avoid writing emulators, assemblers and build tools. Existing projects represented years of work, and using them was the obvious place to start. But I repeatedly encountered software that only ran on Windows, required obsolete libraries or no longer worked on modern operating systems. Websites had disappeared. Forks had developed different pieces of functionality, leaving me to work out which combination might do what I needed.

Those problems become a teaching problem when every reader has to solve them before reaching the lesson.

Building the tooling gave me a way to provide a coherent workflow across operating systems. It also made browser-based tools possible through WebAssembly. A reader can move towards writing and running code without first having to assemble a development environment. That serves the educational purpose of the project directly.

The scope grew because I kept finding obstacles to what I wanted people to be able to do. AI made addressing those obstacles practical.

What I bring to the work

I’ve been part of this scene for the better part of four decades. I grew up with these machines. That experience gives me a useful sense of when an explanation, a program or a machine’s behaviour doesn’t look right. It also gives me questions I want the project to answer.

Experience has limits. Familiarity can help me spot a mistake, but it can also make a familiar misconception seem reasonable. I still need evidence.

For the lessons, I’ve spent a great deal of time working through what to introduce, how deeply to explain it, what to leave until later and when to revisit a subject. I consider both what I would want to understand and what someone new to programming needs in order to take the next step.

An explanation that helps a beginner get started may need more detail later. The teaching approach deliberately returns to earlier topics as readers acquire the understanding needed to examine them more closely. Deciding how that progression should work is a substantial part of my contribution.

My review is less detailed in some areas than others. I’m not a particularly experienced Rust developer, so the Rust code underlying the emulators receives less detailed personal review than material closer to my expertise. I have guided the architecture throughout, but I would not claim to have personally audited every line. The validation process matters partly because my own knowledge cannot cover everything the project attempts.

What the work is based on

Before developing the emulators, I assembled a substantial corpus of source material: documentation for the systems and their individual chips, service manuals, books and contemporary magazines. Other material published on the web generally serves as secondary evidence, unless stronger sources are unavailable.

The goal has always been a high level of accuracy against the hardware, whilst accepting that we cannot reproduce the full physical behaviour of electrical circuits and voltages. The Z80 implementation models signals and timing within individual T-states, allowing interactions inside an instruction to be examined. That granularity makes detailed behaviour testable; it does not automatically make the implementation correct.

For each feature, we attempt to validate the implementation against established test suites used by other emulators or against manufacturer service material. The lessons also draw heavily on the source corpus. Every lesson code sample to date has been tested using both my own emulators and assemblers and independently developed tools.

For factual claims and citations, I use a mixture of checking material myself and AI-assisted cross-checking. I’m aware that AI can produce convincing errors, including explanations that sound much more certain than their evidence warrants. Citations give us something to examine. They still need to support the claim being made.

Where documentation or tests are insufficient, we examine how existing emulators handle the problem. That is useful implementation evidence, with an obvious limitation: we may reproduce somebody else’s mistaken interpretation. Those uncertainties are flagged in code comments. Agreement between implementations is valuable, but it is not the same as agreement with the original hardware.

What verification looks like

Asking AI to be certain is not, by itself, a verification method. It needs ways to investigate.

The emulators include an MCP interface that allows AI tools to inspect the running machine: tracing execution, examining memory and watching for particular values or instruction addresses. I can direct an investigation and keep pressing for evidence while the tools provide access to what the program is actually doing.

Operation Wolf’s Speedlock-7 loader provides a concrete example. Its protection check was failing and triggering a routine that wiped the emulated machine’s memory.

Tracing execution one T-state at a time exposed the exact check that failed. The loader received the bit sequence 101000 where it expected 111010. Examining the tape image then revealed why: our parser read the wrong six bits of a partially used byte.

The correction was one line. Finding that line required tracing the running program, reconstructing the data it received and connecting that result to the tape parser. The fix included a regression test for the exact pulse sequence. The investigation and correction are recorded in Git.

We reran the affected software. The follow-up recorded Operation Wolf progressing beyond the wipe and Bubble Bobble reaching game code. It also recorded that Head over Heels remained broken and needed a separate investigation. One successful correction did not justify declaring every related loader fixed. The follow-up records those different outcomes.

Other investigations have changed earlier conclusions. Work on Z80 interrupt timing initially relied partly on how FUSE handled interrupts. Later, more detailed measurements led to a different interpretation and a correction to the integrated Spectrum model. The validation report explicitly supersedes the earlier decision and records both the evidence and the limits of the experiment. That report is available here.

These examples show what the process can establish. A particular failure was observed, investigated and corrected. Tests exercise the corrected behaviour. They do not prove that the entire emulator is accurate, or that every other assumption is sound.

Why existing information still needs work

Much of the information used by 198x already exists. The project depends on the work of the people who designed these systems, documented them, investigated them and preserved their software.

Existence does not guarantee continued access. I’ve encountered that directly through disappearing websites and software that has become difficult to run. Nor does having the documents automatically give someone the understanding needed to use them.

A chip manual, a machine’s service guide and a working program can illuminate different parts of the same question. Connecting them takes work. Turning that understanding into an implementation makes some assumptions testable. Turning it into a lesson helps another person acquire the understanding without having to repeat the entire investigation.

That is part of what preservation means within 198x: keeping knowledge accessible, examining its connections and making it useful for learning and creation. It does not depend on every fact being newly discovered.

People and responsibility

I would love to involve more of the people who built these machines and their software. Documentation and execution traces cannot tell us everything about why someone chose a particular approach, what alternatives they tried or which constraints mattered most at the time.

Building something concrete gives those conversations a starting point. A reconstructed behaviour, an unanswered question or an explanation that needs correcting gives someone a specific opportunity to contribute. Contributions can be small and still matter.

People discovering these machines now have something to contribute too. A learner can expose an assumption in a lesson that an experienced programmer no longer notices.

Nobody needs to share my opinion of AI to contribute. Some people have ethical, economic or other objections to its use. Explaining my process will not resolve all of those disagreements, and this page is not an attempt to defend every use of the technology.

I choose what gets published and take responsibility for it. If something is wrong, AI’s involvement does not excuse the error. The work needs to be open to examination and correction.

AI has made it possible for me to pursue this project at a scale I could not otherwise sustain. What I want readers to gain is the ability to understand these machines, ask better questions about them and build something of their own.