m68k: FreeMiNT via emulation on the A9

Context

Where the X realm is a fabric reproduction of the 6502 Atari, the T realm targets the 680x0 Atari — ST, STe, TT — to run GEM/TOS-era software. The plan hosts the m68k by emulation on the spare Cortex-A9 (a JIT translating m68k → ARM, reusing existing open-source ST emulation) rather than building a 680x0 soft core in fabric.

Emulation wins here for two reasons:

The OS comes for free. FreeMiNT (with EmuTOS) is an actively-maintained, GPL multitasking TOS — real GEMDOS, AES, VDI, a pre-emptive scheduler, signals, Pexec(), and ST/STe/TT/Falcon device support. Running the real thing under emulation means running actual Atari software, not a reimplementation.
The A9 MMU provides the protection MiNT needs. A protected multitasking TOS wants memory protection between processes. Emulating on the A9 lets that protection map onto the A9’s own MMU directly — so there is no 68030 MMU to emulate (no format-B fault frames, no software page-table walker in the m68k). MiNT needs protection, not demand paging; the A9 MMU supplies exactly that. This is the same MMU that already backs XTOS’s protected process model.

So the question isn’t “how do we write multitasking for the m68k?” nor “how do we port a board-support package to a fabric core?” — it’s “how do we host FreeMiNT in an m68k emulator on the A9 and bridge its I/O into XTOS?”

What you reuse

Almost everything. The two big pieces both already exist:

Piece	Source	Role
m68k → ARM JIT	existing open-source ST/Amiga emulation	executes 680x0 code fast on the A9 core
FreeMiNT + EmuTOS	upstream GPL	the actual OS — GEMDOS, AES, VDI, scheduler, `Pexec()`, drivers

The work is integration, not reimplementation: stand the emulator up on the spare A9, point its memory at a region the A9 MMU protects, and bridge the guest’s I/O (file, display, input, time) to XTOS services.

Memory protection

FreeMiNT expects an MMU for inter-process protection. Two layers are worth separating:

The guest’s view. FreeMiNT runs its processes in the emulated m68k address space.
Where protection actually lives. Rather than emulate a 68030 MMU in software, the host maps the guest’s protection onto the A9 MMU — the emulator gives each MiNT process a host-side protected mapping, so a stray guest access faults on the real A9 hardware (fast) instead of in an emulated page-table walker (slow and fiddly).

The result is real per-process protection with none of the cost of emulating the 68030’s MMU, and no demand paging to model — MiNT only needs the protection, which the A9 already enforces for XTOS’s own processes.

Executables: real `Pexec`

m68k programs load through FreeMiNT’s own Pexec() — it parses the executable, reads its segments, applies the MiNT relocation table, sets up the process stack with argc/argv, and schedules it. This is upstream, debugged code running inside the emulator; nothing about it needs to be rewritten for this platform.

Integration with XTOS

The guest doesn’t talk to real ST chips — its I/O is bridged to XTOS services:

Files — GEMDOS file calls map onto XTOS’s filesystem.
Display — VDI drawing and the ST framebuffer are presented through the display compositor and xt-blitter, appearing as a scalable window on the 1080p desktop — or, run flat-out, using the desktop natively as a GEM surface.
Input — keyboard/mouse come from XTOS’s event bus.
Time — the scheduler tick and clock come from the host.

How GEM maps onto the three-layer model

GEM layer	m68k (FreeMiNT)	6502 (custom kernel)
AES (window management, events)	FreeMiNT AES — fully featured, multi-process with message queues	AES rewritten in xtc, same API, simpler implementation
VDI (drawing primitives)	EmuTOS VDI, bridged to the compositor/blitter	xtc direct blitter dispatch via `$D4Bx`/`$D4Cx` registers
GEMDOS (file I/O)	FreeMiNT GEMDOS → XTOS filesystem	XTOS filesystem via the same services
Process model	Real MiNT with `Pexec()`, signals, protection (A9 MMU)	Custom kernel with a `Pexec()` equivalent, simpler signal model

Verdict

Question	Answer
Feasible?	Yes — and emulation is the shortest path to a full-featured ST OS. FreeMiNT and a proven m68k→ARM JIT both already exist.
Why not a fabric soft core?	It would mean building (and timing-closing) a 680x0 with an MMU in fabric; emulating on the spare A9 reuses the A9’s MMU and a mature JIT instead.
What you get for free	The JIT engine, plus FreeMiNT’s scheduler, `Pexec()`, signals, GEM AES, GEMDOS, VDI framework, and ST/STe/TT drivers
Main work	Integration: hosting the emulator on the A9, mapping protection onto the A9 MMU, and bridging guest I/O to XTOS services
Status	Planned. The 6502 custom kernel is the primary native-fabric path; the ARM XTOS runtime is already built.