Claude Code resuscita un gioco Amiga del 1993 leggendo 72.758 righe di assembly

Un videogioco Amiga del 1993, scritto quasi interamente in assembly Motorola 68000, è tornato a vivere su Godot dopo più di trent’anni. Ma il valore del progetto Babylonian Twins va ben oltre il semplice porting: mostra come strumenti di AI applicata al codice possano aiutare a recuperare software storico, interpretare formati proprietari mai documentati e ricostruire logiche strettamente legate a hardware ormai non più attuale.

È un tema che tocca direttamente la conservazione del software. Molti programmi e videogiochi degli anni ’80 e ’90 sopravvivono ancora con sorgenti incompleti, floppy, binari e strumenti di sviluppo difficili da eseguire sulle piattaforme moderne. In casi simili il problema non consiste soltanto nel “farli partire”: bisogna capire come funzionavano davvero, quali assunzioni facevano sull’hardware e quali informazioni erano incorporate implicitamente nel codice.

Rabah Shihab sviluppò il suo Babylonian Twins a Baghdad nel 1993 su un Amiga 500 con 512 KB di RAM e senza hard disk, lavorando in assembly 68000. Il progetto comprendeva decine di migliaia di righe di codice, formati dati personalizzati, accesso diretto ai registri Amiga e meccanismi grafici costruiti attorno a Copper e Blitter (due coprocessori specializzati dell’Amiga: il primo gestiva cambiamenti grafici sincronizzati con la scansione video, il secondo accelerava operazioni su blocchi di memoria e immagini).

Dopo 33 anni Shihab ha usato Godot 4 e Claude Code per ricostruire quel software senza affidarsi a una semplice emulazione del vecchio binario.

Un porting che parte da 72.758 righe di assembly 68000

Il risultato è interessante soprattutto per un motivo: l’AI non si è limitata a trasformare vecchia sintassi in codice moderno: ha contribuito a leggere 72.758 righe di assembly, confrontare binari, dedurre la struttura dei livelli, interpretare bitfield (valori numerici in cui singoli bit, o gruppi di bit, codificano proprietà e informazioni diverse), individuare differenze tra assembler e ricostruire comportamenti che neppure l’autore ricordava più con precisione.

L’aspetto più interessante non è tanto che un modello linguistico abbia prodotto codice GDScript: il punto è che la ricostruzione si è basata sul contenuto di 26 file sviluppati per il microprocessore CISC Motorola 68000, senza una documentazione moderna e con commenti molto incompleti.

Shihab ha usato Claude Code non come semplice generatore di sorgenti ma come agente con accesso al terminale e alla directory del progetto. Poteva quindi leggere file, modificarli, eseguire compilatori, avviare il gioco, analizzare l’output e ripetere autonomamente molte verifiche.

Un modello generativo che risponde in chat può suggerire come interpretare una struttura binaria; un agente collegato agli strumenti può formulare un’ipotesi, ricompilare il programma e verificare immediatamente se i byte prodotti coincidono con quelli originali.

Anthropic descrive infatti Claude Code come uno strumento agentico che opera nel terminale e direttamente sul repository. Nel caso di Babylonian Twins questa caratteristica ha permesso di costruire una sorta di ciclo sperimentale: leggere l’assembly, formulare una spiegazione del comportamento, modificare il porting, compilare, eseguire e osservare il risultato.

Copper e Blitter: perché l’Amiga non può essere tradotto alla lettera

Babylonian Twins nasce su una macchina in cui il processore Motorola 68000 non svolgeva da solo tutto il lavoro grafico. Come accennato in precedenza, l’Amiga disponeva di circuiti specializzati, fra cui Copper e Blitter.

Il Copper è un coprocessore capace di modificare registri hardware sincronizzandosi con la posizione del fascio video. La documentazione Commodore descrive appositamente le Copper list e le istruzioni WAIT e MOVE per cambiare parametri grafici anche a metà schermo. Il Blitter, integrato nel chip Agnus, accelerava invece copia di blocchi, operazioni logiche, riempimenti e disegno di linee.

Nel codice originale Shihab disabilitava gran parte dell’intervento del sistema operativo durante il gioco e accedeva direttamente ai registri hardware nell’area che inizia a $DFF000. La documentazione Amiga conferma, ad esempio, JOY0DAT a $DFF00A per la lettura del controller e CIAAPRA a $BFE001 per i pulsanti di fuoco.

Godot non ha ovviamente alcun equivalente diretto di una Copper list. Bisogna ricostruire l’effetto finale, non simulare necessariamente il circuito originale.

Il porting non contiene un emulatore Amiga

La versione 2026 di Babylonian Twins (Definitive Edition) non esegue il binario Motorola 68000 originale: grafica, musica e dati compressi sono stati decodificati una volta tramite script Python e trasformati in formati ordinari come PNG, WAV e JSON. I comportamenti ricavati dall’assembly sono stati poi riscritti in GDScript, linguaggio di scripting principale di Godot, pensato per programmare logica di gioco, scene, input e comportamenti direttamente nel motore.

Si tratta quindi di una reimplementazione fedele, non di emulazione. Per eseguire il vero programma del 1993 servono le immagini ADF originali e un ambiente come FS-UAE, WinUAE oppure un Amiga reale.

La Definitive Edition di Babylonian Twins è già disponibile su iOS e Android; arriverà su Steam in autunno. Per eseguire invece i floppy Amiga originali su PC si può ricorrere a FS-UAE, emulatore disponibile per Windows, macOS e Linux. Le immagini complete del gioco originale sono state pubblicate gratuitamente su itch.io: due floppy ADF da 880 KB, oltre al disco della demo storica.