A compiler turned an NES into Qwen weights that match a reference emulator exactly

A console in a language model's state

nesformer runs an NES's 6502 CPU, its 2 KB of work RAM and a cartridge's program ROM inside the weights of a stock Qwen3.5 checkpoint. A compiler computes the weights; the model predicts the CPU's execution log one token at a time. A host program draws frames, reads the controller and fires vblank interrupts. It builds on Qwenputer, which compiled a CHIP-8 and then a RISC-V CPU into Qwen3.5-4B, using the idea that "the model's Gated DeltaNet state is the machine's memory".

The numbers: 466.6M parameters in bf16 (933 MB) of which 9.3M are nonzero, compressing to a 3.3 MB zip. Free-running weights matched the reference CPU's traces on nestest, Thwaite and Full Game, and every saved frame matched. Speed is the cost: about 1,650 tokens per second, 150 to 290 times slower than a real console. Only mapper 0 cartridges, official opcodes and approximate graphics are supported.

Is it a trick or a result?

A reader asked whether there is a point: "Of course a set of digital logic circuits can be reduced to a set of weights. Am I missing something?" The project's author answered from the process side. dbreunig, whose account hosts the repo, said:

"Opus 5.5 built working weights and code with only two prompts"

Jacques Mattheij took the efficiency lesson: "it also gives some new appreciation for how much more efficient deterministic programs are compared to AI."

That is the useful reading of 933 MB holding 9.3M nonzero numbers: the model here is a slow, bloated container for a compiled circuit, not a learned one.