Indice della guida
Personal Paint 68k arriva al suo editor su AROS ARM64 attraverso Kaffeine. Nello screenshot di laboratorio si vedono l’area di lavoro e la barra degli strumenti: non è più soltanto una finestra di avvio. È un primo risultato concreto per il progetto con cui sto lavorando alla compatibilità del software Amiga su AROS nativo.
La precisazione importante viene subito: questa esecuzione usa l’interprete Moira, dentro una macchina virtuale AROS AArch64 in QEMU. Il JIT di Kaffeine ha una propria prova sperimentale, separata. Non sto annunciando Personal Paint accelerato dal JIT, né la compatibilità completa dell’applicazione.
Che cosa mostra davvero lo screenshot
La schermata originale del 28 ottobre 2026 mostra il titolo di Personal Paint, il canvas e gli strumenti laterali. Dopo l’avviso iniziale e il cambio di schermo, l’editor diventa visibile. Questo è il traguardo documentato: un’applicazione grafica 68k supera una parte significativa dell’avvio e costruisce la propria interfaccia su AROS ARM64.
Non basta però una schermata per certificare il programma. Disegno interattivo, apertura e salvataggio delle immagini, uso prolungato e chiusura completa richiedono ancora verifiche dedicate. Il runner di quella sessione è terminato per inattività: il suo timeout non è un verdetto di successo sul ciclo completo dell’applicazione, e non va confuso con un crash dimostrato.
Kaffeine è un ponte, non un Amiga completo in emulazione
Il repository pubblico di Kaffeine descrive un’infrastruttura open source per il software dell’ecosistema Amiga. Il primo obiettivo operativo sono i programmi 68k su AROS ARM64; le altre direzioni del progetto restano una roadmap, non piattaforme già supportate.
Nel test ci sono tre livelli distinti. QEMU esegue la macchina ARM64 su cui gira AROS. Dentro AROS, kaffeine.library carica il programma 68k e Moira ne esegue le istruzioni. Quando il programma chiama una libreria di sistema, il ponte converte quella richiesta verso le API native di AROS.
È proprio l’ultimo passaggio a rendere il lavoro interessante. Una finestra classica non si può passare alla cieca a un sistema a 64 bit: cambiano larghezze dei puntatori, rappresentazione delle strutture, ordinamento dei byte e proprietà delle risorse. Il ponte mantiene rappresentazioni compatibili di finestre, schermi, messaggi e altri oggetti, senza esporre indiscriminatamente gli oggetti nativi al codice guest.
La correzione che ha sbloccato questa tappa
L’ultimo passaggio integrato al momento di questa fotografia è la correzione dei parametri NewWindow e delle porte IDCMP. In termini pratici, il ponte deve rispettare i valori con cui il programma classico chiede di creare una finestra, oltre alle eventuali opzioni che li modificano.
Fra quei valori ci sono gli eventi che la finestra deve ricevere. Perdere l’informazione durante la conversione significa ottenere una finestra apparentemente esistente ma priva della porta messaggi attesa dal programma. La soluzione è riprodurre il comportamento dell’API, non rendere permissiva una chiamata successiva che riceve un puntatore non valido.
Questa tappa arriva dopo altri interventi su schermi e palette a 8 bit, layer e clipping, bitmap, informazioni di disegno e AppIcon. Sono presenti anche uno scheduler cooperativo limitato per i task guest e la gestione dei pacchetti DOS. Sono parti di compatibilità verificate entro confini precisi, non la promessa che qualunque programma Amiga funzionerà.
Le prove registrate e il loro perimetro
L’ultima validazione collegata alla correzione NewWindow riporta 46 eseguibili della suite host superati, controlli mirati con sanitizzatori e un probe finestre da 52 controlli senza errori, sia da Shell sia tramite Run su AROS AArch64 in QEMU. I riferimenti nativi servono a confrontare il comportamento delle API, non a riempire una percentuale di compatibilità.
Queste prove e lo screenshot rispondono a domande diverse. La suite host controlla componenti e regressioni; i probe dentro AROS verificano percorsi reali dell’ambiente; Personal Paint mette insieme richieste che un programma applicativo fa davvero. Nessuno di questi livelli sostituisce una prova su hardware fisico o una sessione completa di lavoro nell’editor.
Il JIT ha mosso un passo dentro AROS
Il probe di traduzione 68k verso AArch64 nasce per verificare un secondo motore CPU scritto per Kaffeine. Nel laboratorio del 28 ottobre, una sua versione standalone ha eseguito codice tradotto dentro AROS ARM64 in QEMU, passando 38 controlli sia da Shell sia da Run.
La prova comprende memoria eseguibile, accessi big-endian, una chiamata attraverso il dispatcher nativo, callback annidate e invalidazione del codice tradotto dopo una modifica del guest. È un risultato tecnico distinto dall’apertura di Personal Paint: il backend applicativo resta Moira, mentre l’estensione nativa del probe è ancora lavoro sperimentale locale.
Il sottoinsieme di istruzioni del probe non equivale a una CPU completa, e non ci sono misure che dimostrino un’accelerazione di Personal Paint su AROS. Emu68 è un riferimento studiato, non il motore integrato: il codice del suo traduttore non è incluso in Kaffeine.
Da dove parte il progetto e dove voglio portarlo
Kaffeine costruisce sul lavoro di AROS e della sua precedente m68kemu.library, oggi evoluta in kaffeine.library. Il motore operativo è Moira di Dirk W. Hoffmann. Le attribuzioni contano: il progetto integra e sviluppa un’infrastruttura esistente, non presenta come scritto da zero tutto ciò che usa. AROS e le modifiche del progetto seguono APL 1.1; Moira usa MIT. Le risorse proprietarie impiegate nelle prove non fanno parte del repository.
Il manifesto di Kaffeine mette al centro la continuità del software mentre cambiano CPU e hardware. Il prossimo risultato utile non è un numero più grande di assert: è aprire un’immagine, modificarla, salvarla e uscire in modo affidabile. Poi viene l’accelerazione, misurata sulle stesse operazioni, e la verifica su una macchina fisica.
È una direzione complementare al lavoro raccontato con EdgeSnap in RetroLab: rendere l’ambiente Amiga più utilizzabile, non soltanto conservarne una fotografia. Per chi vuole seguire o studiare Kaffeine, il punto d’ingresso è il repository con sorgenti e istruzioni di compilazione; al momento della verifica non risultano release precompilate pubblicate. Questo articolo documenta una tappa di sviluppo, non una distribuzione pronta da installare.