Report · github.com
A Working Nintendo in ~1GB of Qwen Weights
github.com
Source published October 30, 2026
Summary: 2 min read
62/100
Summary
Nesformer compiles an NES 6502 CPU, 2 KB of work RAM and up to 32 KB of cartridge program ROM into the weights and Gated DeltaNet state of a Qwen3_5ForCausalLM checkpoint. Rather than training the model, a compiler calculates its weights so that greedy token generation produces the CPU execution trace one token at a time. A host program supplies controller input, renders graphics, handles vblank timing and injects NMI interrupts, while the model holds CPU registers, RAM and cartridge data. The 466.6 million-parameter bf16 checkpoint occupies 933 MB uncompressed but compresses to 3.3 MB because only 9.3 million parameters are nonzero. It uses seven Gated DeltaNet layers, with each head’s 128-by-128 state matrix serving as addressable memory. The same weights can run NROM, or iNES mapper 0, games including Super Mario Bros., Donkey Kong and Excitebike when users provide ROM files. Nesformer reports that its bundled test runs produced CPU traces and rendered frames matching a conventional 6502 emulator, including a 600-frame Thwaite run and a 420-frame Full Game run. Its numba-based engine runs at roughly 1,650 tokens per second on one CPU core, while an NES would require about 700,000 tokens per second; idle-loop skipping leaves reported frames and I/O writes unchanged. Limitations include no mapper support, unofficial opcodes, IRQs, PRG-RAM, sound or full PPU accuracy.
Key Takeaways
- Nesformer uses compiler-generated Qwen3.5 checkpoint weights rather than trained weights to emulate an NES 6502 CPU token by token.
- The model state stores CPU registers, 2 KB of RAM and up to 32 KB of program ROM, while a host program handles graphics, controllers and vblank interrupts.
- Nesformer supports NROM cartridges only, so games requiring bank-switching mappers such as MMC1 or MMC3 cannot run.
- The project reports emulator-identical traces and frames for its supplied test runs, but its fastest engine remains roughly 150 to 290 times slower than a real NES.
What the discussion said
The thread treated this less as a practical emulator than as an unusually vivid stress test for transformer computation. Readers were struck that a Qwen-derived model can embed the NES processor, program ROM, and mutable RAM in its weights and recurrent state, then turn controller events into playable output. The fact that the weights were constructed rather than conventionally trained made the project feel like a concrete demonstration of what this architecture can represent, especially with strong reference implementations and machine-checkable targets guiding the work. At the same time, the reported 150–290x slowdown became the real lesson. Several commenters saw it as a useful antidote to fantasies about replacing ordinary software or operating systems with generative models: deterministic code remains spectacularly cheaper for deterministic tasks. Others argued that this comparison is premature, since a circuit-level compilation is an especially perverse use of a transformer; a narrower model built for selected operating-system functions could cut much of the waste. Some also questioned how broadly working had been established, noting that Mario running is meaningful but far short of exhaustive compatibility. Enthusiasm therefore centered on the hack’s conceptual value, while skepticism centered on practical performance, verification, and whether the result has a purpose beyond a clever proof of possibility.
Where opinion split
The central fight is whether transformer-based emulation is evidence for a viable new computing substrate or a flamboyant proof of inefficiency. Skeptics argue that running fixed digital logic through roughly a gigabyte of model weights at hundreds of times slower than hardware exposes how badly AI fits this job; optimists counter that this circuit-level design is the wrong baseline, and specialized narrow models may make some embedded execution worthwhile.
Coverage & discussions
Hacker News · github.com
Community discussions
Community Sentiment
Positives
- Embedding CPU logic, game data, and live RAM into a model’s weights and state makes transformer computation feel less like autocomplete and more like a programmable machine.
- The project’s construction from reference materials rather than model training impressed readers as a sharp demonstration of how architecture and state can carry exact computation.
- High-quality source implementations and test oracles let an AI coding system assemble a surprising proof of concept with minimal prompting, hinting at faster exploration of strange model designs.
- Several readers see a path toward compact internal virtual machines that execute tools inside forward passes, avoiding repeated autoregressive tool-call loops.
Concerns
- A model that emulates an NES hundreds of times slower than the console is a brutal reminder that deterministic programs still dominate AI on cost, speed, and energy for fixed tasks.
- Playable Mario is only a limited validation target; incomplete cartridge support means the working claim does not establish faithful NES-wide behavior.
- Compiling circuitry into transformer weights looks more like an elaborate stunt than a useful emulator, and some readers doubt it demonstrates anything beyond representational possibility.
- The claim that AI can quickly generate such hacks led some to discount the project’s novelty, framing it as disposable coding output rather than a durable advance.
Related Articles
Qwenputer: A functioning, deterministic RISC-V CPU inside Qwen3.5
Oct 29, 2026
Run Kimi K3 using 29 GB of RAM at 0.50 tok/s
Jul 31, 2026
A CPU that runs entirely on GPU
Mar 4, 2026
Soul Player C64 – A real transformer running on a 1 MHz Commodore 64
Apr 20, 2026
We got 207 tok/s with Qwen3.5-27B on an RTX 3090
Apr 20, 2026