Nesformer: um emulador do NES foi compilado nos pesos de um checkpoint Qwen3.5 (e roda Super Mario Bros)

Fala aí, beleza? O Drew Breunig colocou um emulador da CPU do Nintendinho DENTRO dos pesos de um modelo de linguagem, e dá pra rodar Super Mario Bros nele 😀

O projeto se chama Nesformer e está no GitHub como dbreunig/nesformer, sob licença MIT

Segundo o README, ele compila uma CPU do NES nos pesos de um "stock Qwen3.5 model" (um checkpoint Qwen3_5ForCausalLM), sem treino: o Simon Willison, ao noticiar o projeto, usou a formulação "dentro dos pesos do Qwen3.5-4B", mas como você vai ver mais abaixo, isso merece um detalhe técnico. De qualquer forma, o Mario roda dentro do modelo, só que muuuito devagar

Quem noticiou foi o Simon Willison, em 30/10/2026

A ideia parte do Qwenputer, de Divyansh Agrawal, e o sistema foi construído com o Opus 5.5 a partir de dois prompts

O que é o Qwenputer e de onde veio a ideia do Nesformer

O Qwenputer é um Qwen3.5-4B padrão com uma CPU RISC-V completa embutida nos pesos

Ele usa as camadas Gated DeltaNet do modelo como RAM e roda C e MicroPython nos próprios forward passes, sem runtime externo

Que forward pass? É a passada normal do modelo gerando a próxima saída, a mesma coisa que acontece quando ele te responde um texto

O Divyansh Agrawal explica tudo no post do Qwenputer, publicado em 22/10/2026

Segundo o README do Nesformer, o compilador do Qwenputer já tinha colocado uma CPU CHIP-8 e depois uma RISC-V dentro do Qwen3.5-4B

O Nesformer reaproveita esse compilador (o chipformer) e o truque central: usar o estado Gated DeltaNet como memória da máquina, então a sacada não nasceu do zero: é o próximo passo de uma técnica que já funcionava

Como o Nesformer coloca a CPU 6502 do NES nos pesos de um checkpoint Qwen3.5

Os pesos são compilados, não treinados: "Nobody trained these weights; a compiler computed every one", diz o README

Isso muda tudo: ninguém mostrou milhões de exemplos pro modelo aprender a ser um NES, os valores dos pesos foram escritos de propósito pra executar a lógica da CPU

Se você pensar num compilador comum, que transforma código em instruções de máquina, aqui é parecido, só que o destino são os tensores de um modelo 🙂

Agora o detalhe que precisa de atenção: o README descreve o checkpoint como um Qwen3_5ForCausalLM que reaproveita os formatos de cabeça (16 key heads, 32 value heads, dim 128) e a largura de MLP (9.216) do Qwen3.5-4B, mas o modelo final tem só 7 camadas Gated DeltaNet (mais uma camada de atenção zerada) e hidden size 768, com vocabulário de 263.808 tokens. Ou seja, não são os pesos completos do Qwen3.5-4B: é um checkpoint compacto que usa a mesma arquitetura de base. A ideia de que a CPU ficou "dentro do Qwen3.5-4B" é a formulação que o Simon Willison usou ao noticiar o projeto; o README em si fala em "stock Qwen3.5 model"

Segundo o README, funciona assim:

• o estado das camadas Gated DeltaNet faz o papel de memória da máquina
• os tensores de peso codificam o núcleo 6502 (os 151 opcodes oficiais), os 2 KB de RAM de trabalho e os 32 KB de PRG-ROM de um cartucho NROM (armazenados duas vezes)
• o modelo prevê o log de execução da CPU, um token por vez
• um pequeno programa hospedeiro (nesformer/host.py) cuida dos gráficos (PPU), da entrada do controle e da temporização de NMI no vblank

Ou seja, o modelo faz o trabalho da CPU, e o resto do console (vídeo, controle e timing) fica com o host

Quais jogos rodam no Nesformer e quais são os limites

Só rodam cartuchos NROM (iNES mapper 0)

O motivo: a CPU acessa apenas 32 KB de ROM de programa fixa, embutida no modelo. O usuário fornece a própria ROM

Os exemplos citados no README são Super Mario Bros., Donkey Kong e Excitebike

Agora a parte da velocidade, que é onde a brincadeira mostra o limite

O README declara cerca de 1.650 tokens por segundo num núcleo de CPU da máquina em que foi construído (motor numba padrão), contra os cerca de 700.000 tokens/s de que um NES real precisaria

Na prática, isso dá de 150 a 290 vezes mais lento que o console. O README só avisa "Expect it to be slow" e traz esses números: mas dá pra perceber, só de olhar pra eles, que é um experimento de pesquisa, não um emulador pra jogar no dia a dia

O repositório também tem uma CLI, e dois comandos chamam atenção:

• python -m nesformer check ROM roda os pesos e uma CPU de referência lado a lado, e para na primeira diferença
• python -m nesformer build compila o circuito e grava os pesos em weights/, em cerca de 10 segundos

O check é o mais interessante aqui, e já já tu vai ver o porquê

Os dois prompts que Drew Breunig usou com o Opus 5.5

Na thread do Hacker News sobre o projeto, publicada em 30/10/2026, o Breunig mostrou num comentário os dois prompts que usou com o Opus 5.5

No primeiro, ele pediu pro modelo ler o artigo do Qwenputer e o código relevante

Depois, explorar se a técnica conseguiria emular o chip e a RAM do NES, do jeito que o pessoal faz hoje com FPGAs no MiSTer, que tamanho de modelo seria preciso e se modelos menores chegariam ao clock padrão

O segundo prompt é curtinho:

I think we should build it! Just for fun. It's okay if it's not fast. We want to be able to have the weights, and a cli to run them that we can point at a ROM.

Traduzindo: bora construir, só por diversão, tudo bem se não ficar rápido, e queremos os pesos e uma CLI que receba uma ROM

Se liga que não tem especificação detalhada, nem arquitetura desenhada, nem lista de requisitos

É um pedido aberto, com um objetivo bem claro no fim

Como uma suíte de testes de conformidade serviu de verificação para o agente

Segundo o relato de Breunig no Hacker News, o Opus encontrou e usou como verificação uma suíte de testes de conformidade da comunidade de emulação de NES, com mais de 3 mil instruções de referência, hospedada no repositório christopherpow/nes-test-roms

Os próprios testes descritos no README do Nesformer confirmam esse encaixe: eles conferem a CPU de referência contra o log do nestest, o circuito compilado contra a referência, e os pesos em execução livre contra a referência

O Christopher Pow mantém esse repositório há 15 anos como uma coleção de ROMs de teste pra emuladores de NES, segundo descreve o próprio Simon Willison

Já o nestest em si é descrito no próprio arquivo como "The ultimate NES CPU test ROM", de Kevin Horton, versão 1.00 de 09/06/04

E a NESdev Wiki recomenda o nestest como "the best test to start with when getting a CPU emulator working for the first time"

Por que isso importa tanto?

Porque uma suíte de conformidade dá ao agente um critério objetivo de acerto: ou a CPU emulada se comporta como esperado, ou não se comporta

Sem isso, o agente fica dependendo de "parece que funciona", e aí é aquele código zoado no modo 100% vibe coder que só quebra depois xD

O que o Nesformer ensina a quem usa agentes de código

Um pedido curto e aberto rendeu um sistema complexo porque existia um alvo verificável

De um lado, o nestest e o log de referência dele dizendo o que é certo

Do outro, o modo check, que compara os pesos com uma CPU de referência lado a lado

A lição prática é simples: antes de pedir algo grande pra um agente, procura se já existe uma suíte de conformidade ou um oráculo de referência no domínio

Emulador tem ROM de teste, parser costuma ter suíte oficial, protocolo costuma ter testes de interoperabilidade e por aí vai

Com isso na mão, o agente tem como saber sozinho se errou, e tu tem como conferir sem confiar no olhômetro

E o limite continua valendo: o Nesformer não tem uso prático em desempenho, é um experimento lúdico (e muito massa como demonstração!)

Se você curte ver modelos sendo colocados à prova em projetos, no canal do Hora de Codar tem um vídeo com o Kimi K2.6 encarando vários projetos diferentes

Onde acompanhar o Nesformer

O melhor ponto de partida é o README do dbreunig/nesformer, que traz a técnica, os limites e a CLI

Depois vale ler o post do Qwenputer, pra entender de onde veio o compilador, e passar na thread do Hacker News, onde rola a discussão técnica

E se tu constrói com agentes, faz o exercício: qual suíte de testes já existente poderia servir de verificação no teu projeto?

Até o próximo post! 😀

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.