The Pulse

NESFormer esegue giochi NES a partire dai pesi compilati di Qwen3.5

Il progetto nesformer di Drew Breunig compila una CPU NES 6502, la RAM di lavoro e il codice delle cartucce in un checkpoint Qwen3.5 senza addestrarne i pesi. Il progetto open source riproduce esattamente i frame dei giochi testati, ma è da

AI.info Team · Scritto con l’IA · verificato · 2026-10-31

I giochi NES possono essere eseguiti all’interno di un checkpoint di un modello linguistico, ma il modello impiega fino a 290 volte più tempo della console originale. Pubblicato il 30 ottobre, nesformer inserisce una CPU NES 6502, 2 KB di RAM di lavoro e il codice del programma della cartuccia nei pesi e nello stato ricorrente di un checkpoint standard del modello Qwen3.5.

La particolarità del progetto non è che un modello linguistico abbia imparato a imitare un gioco. I suoi pesi sono stati calcolati da un compilatore, non addestrati, e il modello genera la traccia di esecuzione della CPU un token alla volta. Un programma host separato gestisce il controller, il rendering grafico e parte della temporizzazione della console.

Logica compilata, non comportamento appreso

NES-former si basa su Qwenputer, un progetto precedente che compilava un CHIP-8 e una CPU RISC-V in Qwen3.5. In questa versione, lo stato Gated DeltaNet del modello funge da memoria: il repository descrive ogni testa come dotata di una matrice di stato 128 per 128, in cui le chiavi one-hot possono scrivere le righe e le query one-hot possono leggerle. I registri della CPU, i dati della cartuccia e la RAM sono memorizzati in quello stato.

Il checkpoint usa l’architettura di modello linguistico causale di Qwen3.5, ma la logica della macchina è incorporata nei suoi parametri numerici. Dei 466,6 milioni di parametri bfloat16, 9,3 milioni sono diversi da zero; i pesi risultanti occupano 933 MB in formato bfloat16 e, compressi, formano un file zip da 3,3 MB. Secondo il progetto, il checkpoint si carica tramite Transformers standard, senza codice personalizzato per il modello.

Mario funziona; la console no

Il modello contiene il core 6502, tutti i 151 opcode ufficiali, 2 KB di RAM di lavoro e fino a 32 KB di ROM per il programma della cartuccia. L’host fornisce l’immagine, gli input del controller, la temporizzazione del vblank e le risposte ad alcune letture di input/output. La descrizione del progetto chiarisce la divisione dei compiti: «Un piccolo programma host fa funzionare il resto della console attorno al modello: disegna l’immagine, legge il controller e genera l’interrupt vblank».

La distinzione è importante: nesformer non è un NES completo implementato nei pesi del modello. L’unità di elaborazione grafica è esterna al checkpoint ed esegue il rendering di una riga di scansione alla volta; l’unità di elaborazione audio non è implementata, quindi non c’è suono. Il repository precisa inoltre che gli effetti a metà riga di scansione non vengono riprodotti e che il rilevamento della collisione dello sprite zero e l’overflow degli sprite sono approssimativi.

Frame di test esatti, a caro prezzo in termini di velocità

Il progetto riferisce che la sua CPU di riferimento ha dato risultati corrispondenti al golden log di nestest per 3.348 istruzioni e all’emulatore py65 per 5,7 milioni di istruzioni di codice di gioco. Nei test a esecuzione libera, il gioco Thwaite ha prodotto 300 frame salvati corrispondenti, mentre Full Game ne ha prodotti 210. Sono risultati riferiti dal progetto, non un benchmark indipendente.

Sulla macchina usata dall’autore per la compilazione, il motore predefinito Numba ha funzionato a circa 1.650 token al secondo su un solo core della CPU; il motore standard di Transformers è arrivato a circa 10. Il repository stima che un vero NES richiederebbe circa 700.000 token al secondo, rendendo nesformer complessivamente da 150 a 290 volte più lento. Saltare i cicli di inattività aiuta a evitare le attese ripetute del successivo evento grafico, preservando i frame verificati e le scritture di I/O del progetto.

Due prompt e una gamma limitata di cartucce

In un commento su Hacker News, il creatore del progetto Drew Breunig ha detto che Opus 5.5 ha prodotto pesi e codice funzionanti a partire da due prompt, iniziando con una richiesta di esplorare se la tecnica di Qwenputer potesse emulare un chip e la RAM di un NES. Il suo secondo prompt era più semplice:

«Penso che dovremmo costruirlo, solo per divertimento. Va bene anche se non è veloce».

Drew Breunig, creatore di nesformer

Per ora, il software supporta le cartucce NROM, identificate come iNES mapper 0, e gli opcode ufficiali della CPU. I giochi che si basano su chip mapper con commutazione dei banchi di memoria, opcode non ufficiali o codice eseguito dalla RAM non rientrano tra i casi supportati. Il repository indica il supporto per i mapper come possibile estensione; resta aperta la questione ingegneristica se l’host possa assumere meno compiti mentre la compatibilità cresce.