Un émulateur complet du processeur NES 6502 a été intégré directement dans les poids d’un modèle de langage Qwen3.5. Cette prouesse technique, portée par le projet nesformer, permet de faire tourner des jeux rétro comme Super Mario Bros. en exploitant la capacité du modèle à prédire l’état d’exécution du CPU token par token.

L’idée, inspirée par Qwenputer de Divyansh Agrawal, est de transformer les composants matériels — le CPU, la mémoire de travail et la ROM — en une structure interne du modèle. Au lieu d’utiliser un émulateur externe classique, le modèle génère le journal d’exécution du CPU au fur et à mesure qu’il joue. Un petit programme hôte se charge alors du reste de l’interaction console : affichage graphique, lecture des commandes de manette et gestion des interruptions.

Le système utilise la structure Gated DeltaNet du modèle pour représenter la mémoire de la machine. Selon les développeurs du projet, cette méthode permet de charger des ROMs NROM (mapper 0), comme Super Mario Bros. ou Donkey Kong, sans avoir besoin de reconstruire les poids pour chaque jeu. L’outil de ligne de commande permet de lancer le jeu, de vérifier la conformité du modèle par rapport à un émulateur de référence, ou encore de tracer le flux de tokens.

La complexité de la simulation matérielle

Ce n’est pas une démonstration de rapidité, mais plutôt une démonstration de faisabilité algorithmique. Lorsque l’on exécute un jeu, il faut attendre. L’auteur du projet mentionne que la première compilation du moteur prend environ vingt secondes. Par la suite, chaque image peut prendre entre une et six secondes, ce qui signifie que 600 images — soit dix secondes de temps de jeu NES — peuvent prendre près de vingt-cinq minutes.

En parallèle de cette intégration logicielle, les ingénieurs ont eu recours à des tests de conformité très rigoureux. Le projet nesformer a notamment intégré la collection de tests NES CPU créée il y a quinze ans par Christopher Pow. Ces tests visent à vérifier des comportements précis, par exemple, si les instructions de lecture de la mémoire zéropage respectent les limites de pages, ce que les émulateurs moins fiables peuvent manquer.

Ce qui change pour les développeurs de modèles

Ce travail soulève des questions sur la frontière entre l’IA et l’architecture informatique. En transformant un CPU complet — avec ses 151 opcodes, ses modes d’adressage, son registre, sa RAM de 2 Ko, et sa ROM de 32 Ko — en données pondérées, on force le modèle à internaliser une logique machine très stricte. Il y a, en effet, des mécanismes de contrôle précis, comme la différence entre ce que les instructions CPY et CMP doivent affecter sur le registre d’overflow, et ce que les instructions SBC et ADC doivent faire.

Le programme hôte reste nécessaire pour gérer les périphériques non intégrés au modèle, comme le PPU (qui gère le rendu des lignes de balayage et la palette) ou les contrôleurs de manette. Il est intéressant de noter que les poids du modèle contiennent non seulement le cœur 6502, mais aussi une copie des ROMs pour instruction et données, assurant ainsi une autonomie relative au sein du checkpoint.

Il faudra surveiller comment cette technique, qui nécessite une compilation lourde des circuits, évoluera. La capacité à intégrer des architectures matérielles complexes directement dans des modèles de langage offre un nouveau paradigme pour l’interaction entre l’IA et le calcul embarqué.

Sources

• GitHub – dbreunig/nesformer: An NES CPU compiled into the weights of a stock Qwen3.5 model, github.com
• nes-test-roms/other/nestest.txt at master · christopherpow/nes-test-roms, github.com
• dbreunig/nesformer, Simon Willison, 30 octobre 2026