On this page
Kaffeine is being built as a shared open-source home for Amiga software, able to evolve with the hardware without losing its heritage. That is the project I am working on: a compatibility bridge on native AROS, a 68k-to-ARM64 JIT under construction, and a vision that extends beyond a single CPU.
Today that idea has a concrete image: Personal Paint 68k opens its editor on AROS ARM64, with its canvas and toolbar visible. This is more than a startup screen: a graphical Amiga application reaches its working interface. It is an important milestone, but above all it illustrates why we are building Kaffeine.
The destination: choose the application, not the CPU
The Kaffeine manifesto starts with a simple question: why should Amiga software remain tied to the architecture it was created for? The aim is not another faction in the ecosystem, or a demand to abandon existing systems. It is to reduce fragmentation for users, allowing supported applications to coexist on the same AROS desktop.
The experience I want to achieve is launching an original binary from the desktop or Shell, accessing files, loading dependencies, saving work and closing the application cleanly. Integration could then extend, where possible, to the clipboard, drag and drop, icons and communication between applications. Without having to manage a separate virtual machine for every program.
ARM64 is the first host, not the boundary. The 68k is the first compatibility environment, not necessarily the last. That is the long-term direction: preserve the ability to use software as processors and machines change, rather than merely preserving its files.
Personal Paint reaches its editor: the bridge takes shape
The October 28, 2026 test runs AROS AArch64 in QEMU. Inside AROS, kaffeine.library loads the 68k program and Moira executes its instructions; the bridge converts library calls into native services. QEMU is the laboratory environment for this test, not the intended end-user experience.
The Personal Paint editor is the visible result of less visible work: windows, screens and 8-bit palettes, layers, clipping, bitmaps and messages must honour the contracts the application expects. The NewWindow and IDCMP port fix resolved a crucial step for this milestone. This is not a shortcut keyed to the application’s name: the aim is general behaviour that other software can reuse.
The documented result is the open editor. Drawing, loading and saving images, extended use and a complete clean shutdown still require validation. The next application milestone is precisely to turn that visible interface into a complete, reliable workflow.
Our JIT: translating 68k into ARM64 instructions
The other major development effort is the JIT written for Kaffeine. An interpreter executes guest instructions one at a time; a JIT translator generates blocks of native ARM64 instructions from 68k code and caches them for reuse. The goal is to accelerate the same binaries while retaining the compatibility bridge and correct application behaviour.
Translating an addition is not enough. Registers and flags must be correct, memory accesses must respect big-endian data, guest addresses must stay distinct from host pointers, and native library calls must allow callbacks back into 68k code. When a program modifies its own code, stale translations must be invalidated; when ARM64 instructions are generated, they must be made executable and published to the CPU’s instruction cache. Those are separate problems, both essential.
The translation probe has already demonstrated these mechanisms within a controlled scope. Its native extension, now integrated into the repository through PR 21, passed 38 checks both from the Shell and through Run inside AROS ARM64 in QEMU. Coverage includes translated arithmetic, big-endian memory, a native thunk call, nested translated callbacks, and invalidation followed by retranslation of modified code.
This is a real first piece of the engine we are building, not just a plan on paper. Personal Paint still runs through Moira: the JIT probe covers an instruction subset and is not yet the application backend. Emu68 is a reference we studied; this translator contains none of its code.
From a probe to an application engine
The priority is to grow the JIT without sacrificing compatibility. Moira remains an operational base and comparison reference, alongside independent expected results. A possible hybrid mode, switching to the interpreter when necessary, needs explicitly designed and verified transitions: it is not already available, and copying only the most visible registers would not solve it.
The meaningful measurements will come from real programs: cold startup, warm execution, compilation cost, memory use and transitions between guest code and native libraries. Probe microbenchmarks help development, but they do not measure Personal Paint acceleration on AROS.
We want a faster application that still behaves correctly, not a spectacular number obtained by isolating five instructions from the rest of the system.
Beyond ARM64: reuse compatibility, change the engine
The lasting asset is what we learn about Amiga APIs and objects. A window, message or library should not have to be rebuilt from scratch whenever the host CPU changes. That is why the project separates the compatibility environment, binary loading, CPU execution and platform services.
RISC-V is a candidate for a second host, starting with the interpreter before any dedicated JIT. The ARM64 code generator would not automatically become a RISC-V generator, but reusable loaders, bridge code and verification could preserve the work already done.
Further ahead, the vision also includes a PowerPC engine and an initially bounded environment such as WarpOS, with PowerUP assessed separately. Compatibility with MorphOS or AmigaOS 4 applications would be another project: executing PPC instructions does not automatically provide those systems’ ABIs, libraries and services. These are prospects, not announced support.
The practical road from here
- Make 68k applications useful on AROS ARM64: complete real operations in Personal Paint and other programs, with correct resource management.
- Bring the JIT to applications: expand coverage, integrate the engine and measure benefits without regressions.
- Consolidate on physical hardware: verify interaction, stability, memory use and performance beyond QEMU.
- Expand to other hosts and environments: preserve the shared bridge, adding only what each new platform needs.
Kaffeine builds on AROS and its earlier m68kemu.library, with Moira by Dirk W. Hoffmann as the current engine. The project follows APL 1.1; Moira uses MIT. Attribution and licensing remain part of the work. The public repository and technical README are the entry points for following development and contributing, not a promise of universal compatibility.
As with EdgeSnap in RetroLab, the point is to make the Amiga environment usable today and able to continue tomorrow. Personal Paint is the first major visible sign. The JIT is the engine we are preparing. The ultimate goal is an open-source home for every part of the Amiga ecosystem.