The Pulse

NESFormer Runs NES Games From Compiled Qwen3.5 Weights

Drew Breunig’s nesformer compiles an NES 6502 CPU, work RAM and cartridge code into a Qwen3.5 checkpoint without training the weights. The open-source project reproduces tested game frames exactly, but runs 150 to 290 times slower than an N

AI.info Team · Written with AI · fact-checked · 2026-10-31

NES games can run inside a language-model checkpoint, but the model takes up to 290 times longer than the original console to play them. Released on October 30, nesformer puts an NES 6502 CPU, 2 KB of work RAM and cartridge program code into the weights and recurrent state of a standard Qwen3.5 model checkpoint.

The project’s unusual claim is not that a language model learned to imitate a game. Its weights were computed by a compiler, not trained, and the model generates the CPU’s execution trace one token at a time. A separate host program handles the controller, graphics rendering and parts of the console’s timing.

Compiled logic, not learned behavior

NES-former builds on Qwenputer, an earlier project that compiled a CHIP-8 and a RISC-V CPU into Qwen3.5. In this version, the model’s Gated DeltaNet state acts as memory: the repository describes each head as holding a 128-by-128 state matrix, where one-hot keys can write rows and one-hot queries can read them. The CPU’s registers, cartridge data and RAM are stored in that state.

The checkpoint uses the Qwen3.5 causal-language-model architecture, but the machine logic is built into its numerical parameters. Of 466.6 million bfloat16 parameters, 9.3 million are nonzero; the resulting weights occupy 933 MB in bfloat16 form and compress to a 3.3 MB zip. The project says the checkpoint loads through stock Transformers without custom model code.

Mario runs; the console does not

The model contains the 6502 core, all 151 official opcodes, 2 KB of work RAM and up to 32 KB of cartridge program ROM. The host supplies the picture, controller input, vblank timing and answers to some input/output reads. The project’s own description makes the division clear: “A small host program plays the rest of the console around it: it draws the picture, reads the controller, and fires the vblank interrupt.”

That distinction matters: nesformer is not a complete NES implemented in model weights. The picture processing unit is outside the checkpoint and renders one scanline at a time; the audio processing unit is not implemented, so there is no sound. The repository also notes that mid-scanline effects are not reproduced and that sprite-zero hit and sprite overflow are approximate.

Exact test frames at a steep speed cost

The project reports matching its reference CPU against the nestest golden log for 3,348 instructions and against the py65 emulator on 5.7 million instructions of game code. In free-running tests, the Thwaite game produced 300 saved frames that matched, while Full Game produced 210 matching frames. Those are results reported by the project, not an independent benchmark.

On the author’s build machine, the default Numba engine ran at about 1,650 tokens per second on one CPU core; the standard Transformers engine managed about 10. The repository estimates that a real NES would require roughly 700,000 tokens per second, putting nesformer at 150 to 290 times slower overall. Idle-loop skipping helps by bypassing repeated waits for the next graphics event, while preserving the project’s checked frames and I/O writes.

Two prompts and a narrow cartridge target

In a Hacker News comment, project creator Drew Breunig said Opus 5.5 produced working weights and code from two prompts, starting with a request to explore whether the Qwenputer technique could emulate an NES chip and RAM. His second prompt was simpler:

“I think we should build it! Just for fun. It's okay if it's not fast.”

Drew Breunig, nesformer creator

For now, the software supports NROM cartridges, identified as iNES mapper 0, and official CPU opcodes. Games that rely on bank-switching mapper chips, unofficial opcodes or code running from RAM fall outside its supported cases. The repository outlines mapper support as a possible extension; whether the host can take on fewer jobs while compatibility grows is still an open engineering question.