Indice della guida
Il JIT di Kaffeine non si ferma più ai programmi di prova. Su AROS ARM64, nell’ambiente QEMU che riproduce una Raspberry Pi 3, applicazioni Amiga 68k originali stanno eseguendo operazioni concrete: Personal Paint disegna, salva e ricarica un’immagine; Directory Opus copia e ritrova file; TurboText apre un documento e riceve input. È un avanzamento rispetto al precedente punto sul progetto, non una dichiarazione di compatibilità completa.
Questo aggiornamento di laboratorio descrive i risultati documentati nel repository pubblico e nelle catture originali. Distinguo le prove in emulazione dai benchmark su hardware fisico e non attribuisco al JIT una registrazione realizzata con un altro backend.
Che cosa sto costruendo con Kaffeine
Kaffeine è un’infrastruttura open source per far convivere software Amiga 68k e applicazioni native AROS. Parte dal lavoro di AROS su m68kemu.library, evoluto nel progetto come kaffeine.library. L’obiettivo non è avviare un intero Amiga virtuale dentro una finestra, ma eseguire il programma 68k collegandone le chiamate di sistema alle API native dell’host.
Il ponte deve fare molto più che tradurre istruzioni: converte strutture, gestisce librerie, finestre, messaggi, callback e processi con rappresentazioni differenti tra 68k e ARM64. Moira resta l’interprete predefinito e il riferimento di confronto; il backend JIT traduce blocchi di codice 68k per AArch64. Ogni applicazione sceglie il backend all’avvio, non passa automaticamente da uno all’altro a metà esecuzione.
Personal Paint: dal disegno al ricaricamento
Personal Paint 7.2.1.0, con il suo eseguibile 68k originale e le preferenze di blitting CPU usate nella demo precedente, ha raggiunto l’editor anche con il JIT. Le sessioni da Shell e tramite Run sono terminate normalmente con codice zero; i contatori diagnostici identificano il JIT e i blocchi tradotti. Non sono misure di accelerazione.
Il controllo più significativo è un ciclo salvataggio/ricaricamento su un’immagine 320×200, otto piani e 256 voci di palette. Si disegnano un rettangolo e una linea, si salva in IFF/ILBM, si aggiunge un altro rettangolo visibile e si ricarica il file: il disegno originale viene ripristinato.
Il file salvato pesa 9.386 byte. Una decodifica indipendente con FFmpeg e il confronto dell’area del disegno confermano l’uguaglianza dei pixel con il canvas catturato prima del salvataggio e dopo il ricaricamento. Barra strumenti, titolo e puntatore sono esclusi dal confronto. Il controllo non equivale a una validazione di tutti i formati o delle funzioni dell’editor.
Directory Opus e TurboText: risultati diversi, limiti diversi
Directory Opus 4.12 JR si apre con il JIT, copia un file di testo da 73 byte e un binario da 1.024 byte, rinomina il testo, esce e ritrova entrambi dopo la riapertura. I byte estratti corrispondono alle sorgenti. È una verifica utile del ponte verso filesystem e interfaccia, non una certificazione dell’intero file manager: i campi di data e orologio mostrano ancora valori non validi.
TurboText 2.0 supera invece un controllo di apertura, caricamento del documento e inserimento di un singolo carattere. Il launcher e le librerie originali girano con il JIT su Workbench a 24 bit; il testo e l’indicatore di modifica reagiscono all’input. Salvataggio e riapertura non fanno parte del risultato accettato in queste catture. Restano inoltre difetti nativi AROS di posizionamento dello schermo e composizione indicizzata: lo screenshot conserva il comportamento osservato.
Il video di Personal Paint, con il backend giusto
La registrazione seguente dura 3 minuti e 41 secondi e mostra l’avvio dall’icona del desktop, il disegno e il salvataggio. È la demo precedente con Moira, non un video del JIT. La includo per mostrare l’esperienza applicativa e il lavoro del ponte; i nuovi risultati JIT sono documentati separatamente sopra.
I controlli tecnici e ciò che manca
La documentazione del backend riporta 11.364 controlli della suite di traduzione sul sistema host, con confronto rispetto a Moira e verifiche mirate anche con ASan/UBSan. Sul target ARM64 sono distinti i test della libreria, dei task, delle finestre e dei requester dalle prove delle applicazioni. Il numero di controlli superati non misura le prestazioni né garantisce che qualunque programma Amiga funzioni.
Il JIT resta sperimentale: copertura delle istruzioni incompleta, eccezioni e operazioni FPU/MMU non supportate, nessun ripiego automatico su Moira durante l’esecuzione. Personal Paint salva anche un’immagine 1024×768 nel test separato documentato, ma riaprirla segnala ancora “The image is too large”; dopo il dialogo di caricamento è stato necessario commutare gli schermi AROS. Prestazioni native e comportamento delle cache su Raspberry Pi fisico rimangono da verificare.
La direzione è rendere utilizzabile il patrimonio software Amiga senza legarlo a una sola CPU. Il prossimo passo credibile è ampliare operazioni ripetibili e copertura, conservando originali e risultati confrontabili. Codice, istruzioni del backend e limiti aggiornati sono nel repository pubblico di Kaffeine. Questo articolo fotografa lo stato documentato al 31 ottobre 2026, non annuncia una release di compatibilità generale.
Copertina: illustrazione concettuale generata con OpenAI. Le schermate e il video nel corpo sono catture autentiche, non immagini generate.