Baking a NES Emulator Into an LLM: Qwen3.5-4B Runs Super Mario Bros.

When the Emulator Is No Longer Code, but Model Weights

When you think of playing Super Mario Bros., what usually comes to mind is emulator software plus a ROM. But developer Drew Breunig did something counterintuitive: he "baked" an entire NES 6502 CPU emulator into the weights of Qwen3.5-4B. The project is called nesformer, published on his GitHub, and it quickly sparked discussion on Hacker News.

This means running NES games no longer relies on an interpreter loop in the traditional sense, but instead lets the large model "play the role" of that 8-bit processor during inference. It's very slow, but it does run—you can load a ROM like Super Mario Bros. and watch it inch forward inside Qwen.

The NES (Nintendo Entertainment System) main processor is a customized version of the MOS Technology 6502 (the Ricoh 2A03), an 8-bit CPU clocked at roughly 1.79 MHz. Its instruction set contains about 56 instructions and multiple addressing modes, and its behavior is highly deterministic: given the registers and memory state, the result of the next instruction is fully predictable.

Traditional emulators exploit this determinism with an interpreter loop that reads, decodes, and executes instructions one at a time. Baking this CPU's behavior into model weights essentially requires a parameterized network to reproduce this deterministic state transition at every inference step—which is the most counterintuitive part of the experiment conceptually: using a probabilistic model to approximate a finite state machine.

Inspired by qwenputer

The idea for this project didn't come out of nowhere. Breunig explicitly states that he was inspired by Divyansh Agrawal's qwenputer. qwenputer demonstrated the feasibility of stuffing computational logic into model weights, and nesformer pushes that idea toward a more concrete hardware-emulation scenario.

What the two share is that the model is no longer just "generating text" but is treated as an executable substrate. This usage departs from the mainstream narrative of large models, yet opens up an interesting experimental direction—using neural network weights to express highly deterministic state machine logic.

The Build Process: Two Prompts for Opus 5.5

According to what Breunig disclosed in a Hacker News comment, this system was built with Opus 5.5, with the core being just two prompts. The first was to have the model read the qwenputer article and related source code, then assess: could the same technique be used to emulate the NES's chip and memory? If so, how large a model would be needed? Could a smaller, faster model reach standard clock speed?

The second prompt made the call directly: "I think we should build it! Just for fun. Slow is fine. We want the weights, and a CLI that can point at a ROM."

The wording of these two prompts is worth noting: it doesn't demand engineering perfection, but puts "fun" and "runnable" first. This goal-setting actually lowered the barrier to implementation, turning a seemingly absurd idea into a deliverable prototype.

Leveraging a 15-Year-Old CPU Conformance Test

There's another key detail in the build process. Opus found and used a NES CPU conformance test suite that Christopher Pow published 15 years ago (nestest.txt). This test was originally used to verify the correctness of emulator implementations, and is now used to calibrate how faithfully the model reproduces 6502 instruction behavior.

This is a clever reuse. The old test suite provides clear pass/fail criteria, turning "is the model really emulating the CPU" from a vague subjective judgment into verifiable behavioral validation.

A conformance test is a standard acceptance method in emulator development: it provides a set of preset initial register and memory states, executes instructions one by one, and compares against expected results and flag changes. nestest.txt is the classic test for the 6502, covering the vast majority of instructions and edge cases, and its output can be diffed line by line.

Its value lies in turning "is this emulator correct" into an automatically determinable pass/fail signal. By borrowing this test suite to calibrate the model, nesformer essentially ports an engineering standard originally used to validate interpreters into a metric for evaluating "whether the weights have learned CPU behavior"—the most ingenious part of the project's methodology.

What This Means, and What It Doesn't

Not a Practical Emulator

First, a bucket of cold water: at its current speed, it's still far from "playable." Breunig himself used "very slowly" in his description. Treating it as an everyday way to play NES isn't realistic; traditional emulators remain the overwhelming choice in terms of performance and compatibility.

A Probe Into the Boundaries of Model Capability

What's truly valuable is the question it raises: how much deterministic computation can model weights carry? Once logic is parameterized, how is correctness guaranteed? The conformance test offers a viable path, but its coverage is ultimately limited.

Experiments like this echo the broader body of research on "compiling algorithms into neural networks." Together they point toward a still-unclear direction—neural networks may not only be function approximators, but also a kind of programmable medium. The trade-offs among speed, accuracy, and generalization remain the unanswered core questions.

Compiling algorithms into neural network weights is a research direction that has gradually taken shape in recent years. Common approaches include having networks simulate registers and memory in a latent space, using recurrent structures to carry program state, or distilling the input-output behavior of symbolic programs into parameters.

The common difficulty of such work is that deterministic logic demands error-free step-by-step progression, whereas neural networks are inherently continuous, approximate, and susceptible to the accumulation of numerical error—small errors get amplified over long sequences of execution. So when evaluating such systems, beyond whether they can run at all, one must also look at how long a correct execution chain they can sustain and whether they still hold on unseen inputs—exactly the kind of problem that probe experiments like nesformer try to expose.

Implications for Developer Workflows

Another notable point is the build method itself. Two prompts, a "just for fun" decision, plus the model autonomously finding and using an old test suite—this demonstrates a new form of collaboration: humans set intent and acceptance criteria, while the model handles resource retrieval and implementation. As for how far this form can go, nesformer is just one of many samples.

Want to Try It Yourself?

The project code and weights are open-sourced at dbreunig/nesformer. As Breunig describes, what you need is the weights and a CLI; just point it at a ROM. Be mentally prepared: after loading Super Mario Bros., give it plenty of time.

If you're interested in experiments of the "model as computational medium" kind, qwenputer and nesformer are worth reading together. They aren't products but probes—used to poke at that layer of membrane on the boundary of current large model capabilities that hasn't yet been clearly defined.