En esta página
El JIT de Kaffeine ya no se limita a pequeños programas de prueba. En AROS ARM64, dentro de QEMU con el modelo de una Raspberry Pi 3, aplicaciones originales Amiga 68k realizan operaciones concretas: Personal Paint dibuja, guarda y recarga una imagen; Directory Opus copia y vuelve a encontrar archivos; TurboText abre un documento y recibe entrada. Es un avance respecto al hito anterior del proyecto, no una declaración de compatibilidad completa.
Esta actualización de laboratorio describe los resultados documentados en el repositorio público y las capturas originales. Las pruebas en un entorno emulado no son mediciones de rendimiento en hardware físico, y una grabación realizada con otro backend no se presenta como un vídeo del JIT.
Qué estoy construyendo con Kaffeine
Kaffeine es una infraestructura de código abierto para ejecutar software Amiga 68k junto a aplicaciones nativas AROS. Parte del trabajo de AROS en m68kemu.library, evolucionado en el proyecto como kaffeine.library. El objetivo no es arrancar un Amiga virtual completo dentro de una ventana, sino ejecutar el programa 68k conectando sus llamadas de sistema con las API nativas del anfitrión.
Traducir instrucciones es solo una parte: el puente convierte estructuras y gestiona bibliotecas, ventanas, mensajes, callbacks y procesos cuyas representaciones difieren entre 68k y ARM64. Moira sigue siendo el intérprete predeterminado y la referencia de comparación; el backend JIT traduce bloques de código 68k para AArch64. Cada aplicación elige el backend al arrancar, sin cambiar automáticamente durante la ejecución.
Personal Paint: dibujar, guardar y volver a cargar
Personal Paint 7.2.1.0 llega al editor con el JIT usando su ejecutable 68k original y las preferencias de blitting por CPU de la demostración anterior. Las sesiones desde Shell y mediante Run terminaron normalmente con código cero. Los contadores de diagnóstico identifican el JIT y los bloques traducidos: no son mediciones de velocidad.
La prueba clave es un ciclo de guardado y recarga de una imagen de 320×200, ocho planos y 256 entradas de paleta. Se dibujan un rectángulo y una línea, se guardan en IFF/ILBM, se añade otro rectángulo visible y se carga el archivo guardado: reaparece el dibujo original.
El archivo guardado ocupa 9.386 bytes. Una decodificación independiente con FFmpeg y la comparación del área de dibujo confirman la coincidencia de los píxeles con el lienzo capturado antes de guardar y después de recargar. Se excluyen la barra de herramientas, el título y el puntero. Esto no valida todos los formatos de imagen ni las funciones del editor.
Directory Opus y TurboText: pruebas y límites diferentes
Directory Opus 4.12 JR se abre con el JIT, copia un archivo de texto de 73 bytes y uno binario de 1.024 bytes, renombra el texto, sale y muestra ambos archivos al abrirse de nuevo. Los bytes extraídos coinciden con los originales. Es una comprobación útil del sistema de archivos y la interfaz, no de todo el gestor: los campos de fecha y hora siguen mostrando valores incorrectos.
TurboText 2.0 supera una prueba más acotada de apertura, carga del documento e inserción de un carácter. Su lanzador y bibliotecas originales funcionan con el JIT sobre Workbench de 24 bits; el texto y el indicador de modificación responden a la entrada. Guardar y volver a abrir no forma parte del resultado aceptado en estas capturas. También persisten defectos nativos de AROS en el posicionamiento de la pantalla y la composición indexada: la captura conserva el comportamiento observado.
El vídeo de Personal Paint, con su backend identificado
La siguiente grabación dura 3 minutos y 41 segundos y muestra el inicio desde el icono del escritorio, el dibujo y el guardado. Es la demostración anterior con Moira, no un vídeo del JIT. Permite ver la experiencia de uso y el trabajo del puente; los nuevos resultados del JIT están documentados por separado arriba.
Las comprobaciones técnicas y lo que falta
La documentación del backend recoge 11.364 comprobaciones de la suite de traducción en el sistema anfitrión, con comparación frente a Moira y pruebas específicas con ASan/UBSan. En ARM64 se mantienen separadas las pruebas de biblioteca, tareas, ventanas y requester de las aplicaciones. El número de comprobaciones superadas no mide el rendimiento ni garantiza que cualquier programa Amiga funcione.
El JIT sigue siendo experimental: la cobertura de instrucciones es incompleta, no se admiten la entrega de excepciones ni las operaciones FPU/MMU y no existe cambio automático a Moira durante la ejecución. En la prueba separada documentada, Personal Paint también guarda una imagen de 1024×768, pero al abrirla sigue indicando “The image is too large”; tras el diálogo de carga fue necesario cambiar entre pantallas AROS. El rendimiento nativo y el comportamiento de las cachés en una Raspberry Pi física siguen sin verificar.
La meta es hacer utilizable el patrimonio de software Amiga sin atarlo a una sola CPU. El siguiente paso creíble es ampliar las operaciones repetibles y la cobertura, conservando los originales y resultados comparables. El código, las instrucciones del backend y sus límites están en el repositorio público de Kaffeine. Este artículo refleja el estado documentado a 31 de octubre de 2026; no anuncia una versión de compatibilidad general.
Portada: ilustración conceptual generada con OpenAI. Las capturas y el vídeo del cuerpo son registros auténticos, no imágenes generadas.