---
type: "post"
id: "nesformer-compiles-an-nes-6502-cpu-ram-and-187393"
slug: "nesformer-compiles-an-nes-6502-cpu-ram-and-187393"
title: "Nesformer compiles an NES 6502 CPU, RAM and cartridge ROM into a stock Qwen3.5 checkpoint"
description: "Nesformer is an open-source demonstration that compiles an NES 6502 CPU, its work RAM, and a game cartridge program into the weights of a stock Qwen3.5 checkpoint."
retrieval_nugget: "Nesformer is an open-source demonstration that compiles an NES 6502 CPU, its work RAM, and a game cartridge program into the weights of a stock Qwen3.5 checkpoint. It matters because it separates the checkpoint file format from the usual act of training a language model: here, the weights are a computed program with exact emulator checks."
published_at: "2026-10-31"
updated_at: "2026-10-31"
record_date: "2026-10-31"
date_kind: "published_at"
topics: []
entities: ["Nesformer","Drew Breunig","Qwen3.5","Qwenputer","Nintendo Entertainment System"]
related_patterns: []
novelty_label: "new_fact"
what_changed: "Nesformer adds a distinct NES 6502 CPU, RAM and cartridge-ROM implementation compiled into stock Qwen3.5, alongside the prior Qwenputer RISC-V CPU project."
prior_refs: ["memory:a0ae8610-0ceb-8e7d-a450-f3b0ad6f0d06"]
source_url: "https://github.com/dbreunig/nesformer"
source_urls: ["https://github.com/dbreunig/nesformer"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:nesformer-compiles-an-nes-6502-cpu-ram-and-187393"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/nesformer-compiles-an-nes-6502-cpu-ram-and-187393/","markdown":"https://newruntime.com/posts/nesformer-compiles-an-nes-6502-cpu-ram-and-187393.md","json":"https://newruntime.com/posts/nesformer-compiles-an-nes-6502-cpu-ram-and-187393.json"}
---

# Nesformer compiles an NES 6502 CPU, RAM and cartridge ROM into a stock Qwen3.5 checkpoint

## Retrieval answer

Nesformer is an open-source demonstration that compiles an NES 6502 CPU, its work RAM, and a game cartridge program into the weights of a stock Qwen3.5 checkpoint. It matters because it separates the checkpoint file format from the usual act of training a language model: here, the weights are a computed program with exact emulator checks.

## Summary
Nesformer is an open-source demonstration that compiles an NES 6502 CPU, its work RAM, and a game cartridge program into the weights of a stock Qwen3.5 checkpoint. It matters because it separates the checkpoint file format from the usual act of training a language model: here, the weights are a computed program with exact emulator checks.

## What happened
Developer Drew Breunig published [nesformer](https://github.com/dbreunig/nesformer), a repository whose central claim is unusually literal: an NES CPU runs inside a standard `Qwen3_5ForCausalLM` checkpoint. The compiled checkpoint contains the NES 2A03 chip's 6502 CPU core, 2 KB of work RAM, and a cartridge's program ROM. The repository says no one trained these weights. A compiler calculated them.

The setup does not turn the model into a general-purpose game emulator by prompting it. Instead, at each step the model predicts a token representing the CPU execution log. Nesformer uses the Qwen architecture's Gated DeltaNet state as the simulated machine's memory. A small conventional host program remains outside the checkpoint and performs the other console duties: drawing the image, reading controller input, and delivering the vblank interrupt. That division is important: the model is the CPU-and-memory execution mechanism, not the entire NES system.

The project builds on Qwenputer by Divyansh Agrawal, which compiled CHIP-8 and then a RISC-V CPU into Qwen3.5-4B. Nesformer reuses Qwenputer's compiler. Its own stated checkpoint has 466.6 million bf16 parameters, of which 9.3 million are nonzero; the supplied weights are reported as 3.3 MB zipped. It loads with stock Transformers tooling rather than a custom inference server.

The release includes three freely licensed test games and accepts user-supplied `.nes` ROMs for NROM, or iNES mapper 0, cartridges. The same compiled weights can run another compatible ROM because the host loads that ROM into model state at startup; a rebuild is not required. The project names Super Mario Bros., Donkey Kong, and Excitebike as examples of compatible NROM games. Other cartridge boards are rejected rather than emulated.

Nesformer provides `run`, `check`, `trace`, `build`, and `info` commands. `check` runs the weights beside a reference CPU and stops at the first difference. The README says every frame for its bundled test games matched a conventional 6502 emulator exactly. It is nevertheless far from real-time: after an initial roughly 20-second Numba compilation, a frame takes about one to six seconds. The supplied material reports about 1,650 tokens per second on one CPU core, against roughly 700,000 tokens per second needed by a real NES.

## What the archive adds
We have not covered this before; it opens a new thread.

## Trend signal
No listed New Runtime pattern genuinely fits this result. It is a precise research-and-tooling demonstration, not evidence yet that production agent harnesses, protocols, security boundaries, or model interfaces are changing.

## Why it matters
For builders, the practical result is not “run games in an LLM.” Nesformer shows that a familiar checkpoint container and unmodified model-loading path can carry a deterministic compiled computation. The model architecture, its persistent state, and an ordinary inference stack become a substrate for an exact machine rather than a learned predictor.

That is useful as a boundary test for assumptions around model artifacts. A checkpoint may be evaluated as a model, but it can also embody a purpose-built computation whose behavior is determined by its construction. Teams working on model intake, artifact review, or custom inference should distinguish claims about a model's learned capabilities from claims about what executable structure has been encoded in its weights. Nesformer does not make this a common deployment pattern, but it makes the distinction concrete and inspectable.

## What happens next
- **Follow-on experiments will compile additional bounded machines or workloads into conventional checkpoint formats.** (6 months, 55%). Watch for: repositories that reuse the Qwenputer compiler beyond console CPUs.
- **Tooling discussion will focus more explicitly on inspection of checkpoint artifacts rather than only model cards and prompts.** (12 months, 45%). Watch for: model-loading or supply-chain tools that identify computed or unusual weight structure.

## Limits and uncertainty
The repository's frame-exact result is reported for bundled test ROMs against a conventional 6502 emulator; the supplied material does not establish equivalent validation for every compatible game or every NES subsystem. Nesformer deliberately leaves graphics, controller handling, and vblank interrupt delivery to a host program, so it is not a checkpoint-only NES implementation. Its mapper support is limited to NROM cartridges, and its reported speed is orders of magnitude below real-time console execution. The evidence also does not show that compiled checkpoints are useful, safe, or economical for ordinary AI applications.

## Skill to build now
Add a simple artifact-review step when testing externally supplied model weights: record the exact file hash, inspect the declared architecture and loading code, and run a bounded behavior check before placing the artifact in a shared inference environment. Nesformer provides `SHA256SUMS` and a `check` command as an example of separating file integrity from behavioral comparison. This is not a claim that the project is unsafe; it is a useful review habit when a model file can encode more than a conventionally trained model.

## Reader takeaway
Nesformer is a verified demonstration that a stock Qwen3.5 checkpoint can contain a compiler-generated, deterministic NES CPU-and-memory computation. Its immediate value is conceptual and technical: checkpoint files and standard inference paths can be used for artifacts whose meaningful behavior is not language generation at all.

## Open question
What inspection and evaluation practices will distinguish an ordinary trained checkpoint from a compiled computational artifact when both use the same model format and loader?

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)