nesformer: an NES CPU compiled into Qwen weights runs games 150–290× slower

On 30 October 2026, Drew Breunig posted nesformer to Show HN: an open-source project that runs the Nintendo Entertainment System's 6502 CPU, its 2 KB of work RAM and a game cartridge's program ROM inside a stock Qwen3.5 model checkpoint. According to the README, nobody trained the weights; a compiler computed every one. The model predicts the CPU's execution log one token at a time, and a small host program draws the picture and reads the controller.

How it works, per the README

• It builds on Qwenputer by Divyansh Agrawal, which compiled a CHIP-8 and then a RISC-V CPU into Qwen3.5-4B. The central trick is that the model's Gated DeltaNet state is the machine's memory: each row of a 128 × 128 state matrix acts as one memory cell.
• The checkpoint has 7 Gated DeltaNet layers, a hidden size of 768 and 466.6 million parameters in bf16 (933 MB), of which 9.3 million are nonzero, so the weights zip to 3.3 MB.
• The CPU core, RAM and the 32 KB of program ROM live in the model. The picture-drawing chip (PPU), controllers and timing live in the host program, and there is no sound.

What was checked, and what it costs

The README lists its checks. The reference CPU matches the nestest golden log for 3,348 instructions and the py65 emulator over 5.7 million instructions of game code. The compiled weights, free-running, produced traces identical to the reference: 1,916,527 tokens for the Thwaite test game (all 300 saved frames match) and 2,645,885 tokens for Full Game (all 210 saved frames match). These are the author's own results; the README includes a test suite to repeat them.

Speed is the catch. The README reports about 1,650 tokens per second on one CPU core, 210 with plain numpy and about 10 with stock transformers, against roughly 700,000 per second for a real NES. A frame takes 1–6 seconds, and 600 frames (10 seconds of game time) take about 25 minutes. It reports 150–290× slower than the real console.

Limits

The README says it supports only NROM cartridges (iNES mapper 0), official opcodes only, code running from cartridge ROM only, and no interrupt requests other than BRK and NMI. Games that need bank switching, such as those using MMC1 or MMC3 chips, stop with a message.

How it was built, and the thread

Simon Willison relayed a Hacker News comment in which the author says Claude Opus 5.5 produced the working weights and code from two prompts: one asking whether the technique could emulate the NES chip and RAM and at what model size, and one saying to build it, slow or not, with a command-line tool to run it on a ROM. That account is the author's, not independently verified.

The strongest objection in the thread was about purpose: one commenter said a set of digital logic circuits can obviously be reduced to weights, and asked what the point is. Another read the 150–290× figure as a measure of how much more compute a language model needs than an ordinary program. Another asked how anyone knows it is 'working' without testing every input, which the README's reference-trace checks only partly answer: they cover the listed games and test ROM, not every possible input.

What a team can take from it

This is not something to deploy. The reusable idea is the verification: the author compared the model's output token by token against a conventional reference implementation, and published the figures. If a vendor or colleague says logic has been moved into a model, ask for that comparison, the number of steps it covered and the speed penalty.