ИИ Claude играет в DOOM вслепую на итальянском модуле SCINTIX P4

Claude gioca a DOOM alla cieca su un modulo italiano: prima sbatteva sui muri Andrea Ricci ha portato DOOM su SCINTIX P4, modulo ESP32-P4 nel formato Raspberry Pi CM4/CM5, e ha esposto il gioco a un modello via MCP: Claude Sonnet riceve un ventaglio di 51 raggi, una mappa ASCII delle pareti gi viste, e muove il marine di Andrea Bai pubblicata il 27 Agosto 2026, alle 08:41 nel canale Scienza e tecnologia DooM Andrea Ricci, cofondatore dell'azienda italiana Reloc, ha portato DOOM su SCINTIX P4, un modulo che mette un ESP32-P4 e un ESP32-C6 nel formato meccanico delle Raspberry Pi CM4 e CM5, e poi ha lasciato che a giocarci fosse Claude Sonnet. Il modello non riceve mai un fotogramma: al suo posto arriva una descrizione testuale di quello che il marine ha davanti, e da l decide se avanzare, girare, sparare o aprire una porta. Il progetto interamente open source, firmware e server di controllo compresi. La scheda un system-on-module: l'ESP32-P4 un dual-core RISC-V a 400 MHz con controller MIPI-DSI, acceleratore 2D per i pixel e USB host, mentre la parte radio delegata all'ESP32-C6 affiancato. DOOM continua a disegnare i propri fotogrammi a 320x200, e l'ingrandimento fino ai 1024x600 del pannello MIPI-DSI lavoro dell'acceleratore, che tiene il gioco su 30 fotogrammi al secondo stabili. Il collegamento con il modello passa dalla stessa rete Wi-Fi che il C6 porta al P4, dato che il P4 non ha una radio propria. Un'osservazione testuale al posto dei pixel L'osservazione che il modello riceve a ogni turno fatta di poche voci, tutte ricavate da quello che sarebbe visibile sullo schermo. C' un ventaglio di 51 raggi che misurano la distanza delle pareti lungo il campo visivo, l'elenco dei nemici e degli oggetti effettivamente inquadrati e in linea di vista, ordinati da sinistra a destra, e una mappa ASCII che riporta soltanto le pareti gi scoperte, esattamente come l'automap del gioco. Si aggiungono due indizi: door_ahead segnala una porta chiusa in vista, blocked dice che l'ultima mossa non ha prodotto avanzamento. Nessuna posizione letta dalla mappa completa, nessun nemico visto attraverso i muri. Il ventaglio era partito da sette raggi, e con sette raggi l'agente continuava a camminare addosso agli ostacoli: i vani delle porte e gli spigoli dei muri cadevano negli spazi fra un raggio e l'altro, quindi per il modello non esistevano proprio. Con 51 raggi distribuiti su tutto il campo visivo il mondo diventato leggibile, perch un raggio molto pi lungo dei suoi vicini indica un'apertura. Anche door_ahead ha richiesto la stessa rifinitura: punta al centro della porta e ricompare quando una porta si richiusa, cos che il modello capisca di dover premere di nuovo il comando di apertura invece di leggere un muro pieno. Il problema che ha insegnato di pi era un errore di segno. Le direzioni riportate al modello risultavano invertite rispetto a quanto diceva la documentazione, e l'angolo di orientamento seguiva una convenzione diversa da quella della mappa, con il risultato che l'agente scambiava sistematicamente destra e sinistra. La correzione consistita nel rendere positivo il verso destro ovunque, per oggetti, pareti e porte, e nel trasformare l'orientamento in una bussola allineata alla mappa orientata a nord: da l l'agente ha smesso di prendere i muri a testate e ha cominciato a navigare. Anche blocked stato riscritto, proiettando lo spostamento sull'asse di marcia, cos che strisciare di lato lungo una parete continui a contare come mancato avanzamento nella direzione in cui si punta. Il canale in lockstep e il server MCP Il canale di controllo un endpoint WebSocket che fa girare il gioco in lockstep: il client invia un'azione, il gioco avanza di qualche tic e restituisce l'osservazione in JSON, poi si ferma di nuovo e aspetta la mossa successiva. Il determinismo il punto dell'esercizio, perch il modello ragiona sempre su una scena congelata e coerente, non su un mondo che continua a muoversi mentre lui pensa. anche il motivo per cui, nel video, il marine si sposta a scatti brevi: fra una mossa e l'altra il gioco letteralmente in pausa. Sopra il canale WebSocket c' un piccolo server MCP che espone la partita come un insieme di strumenti: observe, move_forward, move_back, turn_left, turn_right, strafe_left, strafe_right, fire, use, select_weapon e get_map. Il gioco si registra cos presso qualunque client compatibile con MCP, Claude Code compreso, e basta puntare il client all'indirizzo IP della scheda perch il modello possa giocare. Non serve codice di collegamento e non serve leggere lo schermo. Lo scaler hardware, la radio e le periferiche L'ingrandimento da 320x200 a 1024x600 era il vero collo di bottiglia del port. Fatto in software costava circa 24 ms per fotogramma fra scalatura e copia, e teneva il gioco intorno ai 20 fotogrammi al secondo. Passando il compito al PPA, l'acceleratore 2D dell'ESP32-P4, l'immagine viene scalata direttamente nel buffer posteriore del pannello MIPI-DSI, che gi di propriet del driver di visualizzazione: presentarlo diventa uno scambio di buffer senza copie aggiuntive, il costo scende a circa 9 ms e il gioco si assesta su 30 fotogrammi al secondo. Oltre quella soglia il limite non pi la scalatura, ma il renderer di DOOM e il suo tick di gioco a 35 Hz. Il passaggio all'acceleratore ha portato con s un difetto visivo curioso. Il PPA quantizza il fattore di scala a passi di 1/16, quindi il 3,2x richiesto diventa 3,1875x, cio 1020 pixel di larghezza: le ultime quattro colonne del pannello non vengono mai scritte. Con il doppio buffering le due aree contenevano residui diversi del pattern di avvio, e il bordo destro sfarfallava a ogni scambio di buffer. La soluzione stata azzerare al nero entrambi i framebuffer una volta sola all'accensione, lasciando una striscia nera di quattro pixel che nessuno nota. La connettivit arriva dall'ESP32-C6, raggiunto via ESP-Hosted su un collegamento SDIO a 4 bit. Dal punto di vista del P4 il Wi-Fi si comporta come se fosse locale: al primo avvio la scheda apre una rete propria con SSID SCINTIX-P4-xxxx e un portale di configurazione per ricevere le credenziali, dopodich si collega come stazione. lo stesso collegamento che il modello usa per raggiungere il gioco. L'ingresso umano passa dall'USB host del P4, con tastiere in boot protocol mappate sui tasti classici di DOOM e gamepad HID generici, e le due cose convivono senza conflitti. C' per un dettaglio da tenere a mente per chiunque lavori con l'USB host su questo chip: un dispositivo full-speed dietro un hub high-speed richiede un Transaction Translator, che non implementato nello stack USB host dell'IDF usato qui, quindi un controller full-speed collegato attraverso un hub high-speed non viene enumerato affatto. Collegato direttamente funziona. Per l'audio stato agganciato via I2S un codec ES8311 esterno. Il modulo non ha un MCLK dedicato, quindi il codec ricava il clock dal bit clock, e a 22050 Hz con campioni a 16 bit il moltiplicatore interno cade sul rapporto corretto. L'amplificatore a bordo si sblocca attraverso un espansore di I/O PI4IOE invece che da un normale pin GPIO, e DOOM ha di nuovo i suoi effetti sonori, senza la musica. Il controller senza fili il pezzo ancora incompleto. Sempre perch il P4 non ha radio propria, l'host NimBLE gira sul P4 e il C6 fa da controller BLE, con l'HCI trasportato sul canale VHCI dell'ESP-Hosted, e l'obiettivo accoppiare un 8BitDo Micro senza dongle USB: la scansione BLE gi funziona attraverso il C6, la parte HID host il passo successivo. Il resto, port di DOOM, firmware e server MCP, pubblicato su GitHub nel repository relocsrl/scintix-p4-playing-doom.