nesformer: running NES games inside a language model

The problem

A language model can run a program without error only if its weights encode the program’s computation exactly.

Language model weights are usually learned from data. A trained model can give a wrong result, and reading its weights does not tell you what it computes.

How it solves it

nesformer was posted on Hacker News as a Show HN on October 31, 2026. It computes its weights with a compiler instead of training them. A model with the Qwen3.5 architecture holds the NESNESNintendo’s home video game console, sold in North America from 1985. It first came out in Japan in 1983 as the Famicom. Its CPU is based on the 6502. CPU, its 2 KB of work RAM and a cartridge’s program ROM.

When you play a game, the model predicts the CPU’s execution log one token at a time. One CPU instruction usually becomes one token, and game code averages 1.1 to 1.3 tokens per instruction. A small host program draws the screen and reads the controller. It also sends the CPU an interruptinterruptA signal that makes the CPU pause its current work and run a set piece of code first. The NES sends one to the CPU for every frame it draws. for each new frame. The host never looks at the CPU’s registers or memory directly. It reads only the log the model outputs. The check command runs a game side by side on the model and on a reference CPU. It stops at the first token that differs. The reference CPU is a 6502 emulator written in Python.

What is different

The weights are made differently. In nesformer, a compiler turns the CPU’s circuit into weights. The result is a standard Qwen3.5 model folder for Hugging Face. According to the README, the transformers library loads it without custom code. Only 9,340,331 of its 466,647,616 parameters are nonzero, so the 933 MB of weights zip to 3.3 MB. The Gated DeltaNetGated DeltaNetA language model layer that remembers earlier input by updating a fixed-size state matrix at every token, instead of looking back at every earlier token. Qwen3.5 models include it. layers in Qwen3.5 update a state matrix at every token, and each row of that matrix becomes one memory cell. The cartridge ROM, RAM and registers all live in these rows. Another project, Qwenputer, built the compiler and used it to put CHIP-8 and RISC-V CPUs into Qwen3.5-4B. nesformer uses the same compiler to put the NES’s 6502 CPU into an 8-layer Qwen3.5 model. One limit is that bigger games do not run. The model reads program ROM from a fixed 32 KB table, but their cartridges carry a mappermapperA chip in an NES cartridge that swaps which part of the ROM the CPU sees. Games bigger than 32 KB use it to reach the rest of their ROM. chip that swaps ROM regions.

It is also slower than an actual NES. According to the README, matching an actual NES would take about 700,000 tokens per second. On the maker’s computer, it generated about 1,650 tokens per second on one CPU core. The host skips repeated iterations of the loop where the game code waits for the next frame. This cuts the token count by a factor of 2.6 to 4.2. According to the README, nesformer runs 150 to 290 times slower than the console overall.

How it was built

• The repository has one commit, the first public release on October 30, 2026. The commit has no Co-authored-by trailer for an AI tool.
• It includes Qwenputer’s compiler, chipformer, under the MIT license. Parts of the circuit and weight code were adapted from Qwenputer.
• The maker records checks at four levels in the README. The reference CPU was compared with another 6502 emulator and with the official log of nestest, a ROM for testing the CPU. The circuit and the weights were compared with the reference CPU.

Running it

I followed the README’s commands on a 4-core computer without a GPU.

1. Install. Unzipping nesformer-weights.zip (3.3 MB) from the repository gave a 933 MB weights file. Its SHA-256 matched the value in the repository. pip install numpy scipy numba pillow finished in 14 seconds.
2. Comparison. I ran check roms/thwaite.nes --tokens 20000 with Thwaite, an NES game. It finished in 16 seconds including loading the weights, and the tool reported 1,469 tokens per second. The 20,000 tokens and 5 frames from the model were identical to the reference CPU’s. With nestest, the check took 34 seconds including loading the weights, and 50,001 tokens and 81 frames were identical.
3. Game. run roms/thwaite.nes --frames 120 generated 175,511 tokens in 102 seconds. That is 1,719 tokens per second. On an NES, 120 frames take 2.0 seconds, so this was 51 times slower than the console. I pressed no buttons, so the run covered only the screens before play starts. It took about 1,460 tokens per frame, less than half of the README’s 600-frame Thwaite run (about 3,200). Each frame took 0.4 to 2.4 seconds.
4. Rebuild. The build command rebuilt the weights file from the circuit in 18 seconds. The README says about 10 seconds. The new file had the same SHA-256 as the shipped weights.

frame 120/120  175,511 tokens  1,719 tok/s  1.6s/frame
175,511 tokens in 102s (1,719 tok/s), 120 frames, 3,573,681 CPU cycles (2.0s of NES time)

Not checked

• Playing the game. Run Thwaite for 600 frames with the button script from the README’s example command and check the game screens. The README says this takes about 25 minutes.
• The unmodified transformers library. Install torch and run the same weights with --engine hf.

Verdict

It works. About 70,000 tokens from the model matched the reference CPU’s log. But it took 102 seconds to run what an NES runs in 2 seconds. It is worth trying if you want to see a program run without error inside a language model.