Amix on 68040 and 68060 — Current Status¶

Stock Amix 2.1 does not run on a 68040 or a 68060, and no released version ever did. ✅ The kernel predates the 68040 MMU and drives the 68030 MMU directly through its HAT layer; the MMU model differs, so this is a fundamental limit rather than a missing driver you could add ✅. The practical consequence — an A4000 cannot officially run Amix ✅ — is covered on the hardware page and in the quirks checklist.

This page is a status stub. It exists so that "can Amix run on my 040/060?" has one honest answer to point at, and so that the answer can be updated in one place as the situation changes. It deliberately records only what can be stated publicly and shown.

What the wall actually is¶

The MMU. The kernel's memory management is written against the 68030 MMU. The 68040 and 68060 use a different translation model, so the kernel-side MMU enable, teardown and translation-control paths are not portable between them ✅ (the fact that "the MMU model differs" is established; the full technical comparison is out of scope for this stub).
The FPU. Amix requires a hardware FPU and ships no soft-float build ✅. A 68040 or 68060 has an on-chip FPU, but the context-save model differs from the 68881/68882 the kernel expects, so FPU handling is kernel-side work too 🟡. The 68LC060 has no FPU at all — so even a working 060 kernel would additionally need software floating point before it could run stock userland 🟡. What running without it looks like is now measured on an FPU-less 68k part: the F-line trap's stock mapping delivers SIGSYS ("Bad System Call", exit 140) — not SIGILL, not SIGFPE — and the failing set is any program that prints a float, because libc's _doprnt itself carries FP instructions on its %e/%f/%g paths (df -k and uptime die in the print call; awk dies even on 1+1, since it holds every number as a C double) ✅. See quirks §31–32.
Exception handling. Bus-error and other exception stack frames differ by CPU family, and the kernel's fault paths are written for the frames a 68030 produces 🟡. (For how load-bearing exact frame behaviour is on this platform, see emulation fidelity, where a single mis-built 68030 frame word was enough to corrupt files silently.)

None of the three is exotic in isolation; together they are a kernel port, and the Amix kernel is source-free for most of the code involved — see reverse-engineering the kernel for what working on it without source actually costs.

What a soft-FPU port would require¶

Stated as requirements, without any claim about existing work: an FPU-less 68060 (68LC060) needs the F-line vector to fan out three ways — FPSP040 for a 68040 with an FPU, FPSP060 for a 68060 with one, and a software FP emulator for a part with none — chosen on a boot-time probe of whether FP silicon exists, not on CPU type, because on an FPU-less 68060 every F-line event arrives as the "FP disabled" frame 🟡. A genuinely illegal F-line word must keep taking the stock path: handing it to an emulator would change the signal every bad F-line word in the system delivers, a user-visible ABI change 🟡. And the emulation path cannot let the stock trap arm deliver its signal — on an FPU-less part that arm says SIGSYS (see the FPU bullet above), so the emulator must construct the signal-info itself from what the emulation actually determined 🟡. Two 68060 frame-level facts any such port trips over — the software-maintained "Next PC" field and the immediate-operand length ambiguity — are on the quirks page as CPU properties.

One requirement on the same list that is not about floating point at all: the 68060 traps its unimplemented 64-bit integer instructions to an exception vector the stock SVR4 trap table never populated, so such an instruction is killed silently rather than emulated ✅ — a real 060 port has to add both the handler and the emulation, or constrain its toolchain to the 32-bit integer forms. The affected forms and the practical toolchain rule are on quirks §53 (✅ for the 64-bit MULx.L/DIVx.L forms, 🟡 for CMP2/CHK2/CAS2/MOVEP).

What is being worked on¶

Community work toward 040/060 support exists 🟡. As of this writing there is no published, bootable 040 or 060 Amix kernel that we can point at or verify, so this page states nothing about its content or its prospects. If and when something is publicly released, it will be documented here from public sources like anything else.
An 040-MMU emulation lane is in progress on our side, in the Z3660 firmware fork — the same codebase that already ships a working 68030 PMMU emulator that boots Amix on real hardware ✅. Adding an 040 MMU model there is integration work plus an exception-frame debugging campaign; none of the 030 campaign's frame-level results transfer 🟡. Note what this lane does and does not buy: it would let an 040 kernel be exercised on the accelerator, but it does not by itself make one exist.
The software-FPU (FPE) lane now exists and has run on real silicon ✅ — an FPU-less 68060 (68LC060) kernel that serves floating point through a software emulator boots on real hardware. What that took, and the one 68060 exception subtlety it turned on, are in the FPU-less 68060 lane below. This does not change the "no published 060 kernel" status above — grimoire records the measured behaviour, not the source.

The FPU-less 68060 lane: software floating point on real silicon¶

Separate from the Z3660 software-030 route — where the 060 executes a software 68030 and Amix never runs as native 060 code — a second line of work targets the 68060 directly: a kernel that executes as native 68060 code and supplies the missing floating point in software. On an FPU-less part (the 68LC060) this is the only option, since there is no FPU to context-switch at all. The finding worth recording is that it works — an FPU-less 68060 Amix kernel has been booted on real 68LC060 silicon with floating point served entirely by a software emulator (an "FPE" lane) ✅. This does not create a published, downloadable 060 kernel (there still isn't one, and this page states nothing about one); grimoire carries the measured behaviour, and the behaviour below is measured on real hardware, not projected.

Getting there turns on one 68060 exception-handling subtlety that is easy to miss and, before it was handled, killed exactly this instruction class silently. It is a different vector from the ordinary FPU-disabled trap, with a different frame — do not conflate it with the vector-11 Next-PC and immediate-length subtleties on quirks §33–34, which concern the format-$4 frame.

The unimplemented-effective-address class traps to vector 60, not vector 11 ✅¶

On a 68060, most floating-point instructions that reach an FPU-disabled CPU (no FPU present, or the FPU switched off) take the ordinary F-line "unimplemented instruction" path — the format-$4 frame at vector 11 — and are emulated from there. Four instruction forms are different: the 68060's integer unit cannot decode their addressing mode and traps them separately, to vector 60 ("unimplemented effective address"), with its own frame shape ✅. The four forms are:

an FP instruction with an extended-precision immediate operand (fmove.x #<ext>,FPn);
an FP instruction with a packed-decimal immediate operand (fmove.p #<packed>,FPn);
fmovem.x with a dynamic (register-specified) register list;
fmovem.l with an immediate source loading two or three FP control registers (fpcr/fpsr/fpiar).

All four were exercised individually on real 68LC060 silicon and each confirmed to route through the vector-60 arm rather than vector 11 ✅.

The vector-60 frame is leaner than vector 11's, and carries no length ✅¶

The 68060 stacks the short format-$0 frame at vector 60 — four words (SR, PC, and the format/vector word) — architecturally leaner than the format-$4 frame vector 11 uses. Two properties bite a handler ✅:

Its PC field names the faulting instruction itself, not an advisory "next instruction" pointer of the kind the format-$4 frame's software-maintained field carries. A real-hardware trace recorded vector 0xF0 (= 60 × 4) with the stacked PC disassembling to the exact faulting FP instruction, not the one after it.
No field of the frame carries the instruction's length. For the two immediate-operand forms the whole instruction is 16 bytes (2-byte opword + 2-byte FP command word + 12-byte immediate operand), and a handler that wants to resume past it must compute that length itself, by decoding the FP command word's own source-specifier bits — the same field a full FP emulator has to read anyway to know how many operand bytes to consume. Two independent decoders and a from-scratch host-side harness agree on the 16-byte figure ✅.

On a 68LC060, all four forms take this path — every time ✅¶

The practical headline: it is not the case that an FPU-less 68060 routes all floating-point work through the vector-11 F-line path with vector 60 as a theoretical corner case. Measured on real 68LC060 silicon, all four unimplemented-effective-address forms trap through vector 60 regardless of whether an FPU is present anywhere in the system ✅. (An earlier, narrower read had suggested vector 60 might be "structurally dead" on an FPU-less part, because a whole boot's idle traffic showed its counter at zero — that was a denominator artefact, not a fact about the vector: nothing had executed one of the four forms yet. A dedicated workload settled it — the same zero-behind-a-gate trap the quirks page warns about.)

Before it was handled, this class died as a silent SIGSYS ✅¶

On a first-cut FPE kernel with no vector-60 handler, executing one of the four forms on a 68LC060 produced a bare SIGSYS ("Bad System Call") with no counter anywhere in the FP-emulation instrumentation moving to record that a process had just died on a floating-point instruction — the event never reached the emulator's accounting, because a downstream FPU-disabled arm inside the vendor support package correctly declined (it recognises it cannot serve a part with no FPU) and fell through to the kernel's default unhandled-vector path, which SIGSYS's an F-line trap ✅. This is the same SIGSYS-not-SIGILL/SIGFPE signature the FPU bullet above describes, reached by a different route; the death was reproduced before the fix and absent after it, A/B on the same rig ✅.

The rule for anyone emulating or targeting a 68060¶

Software that emulates an FPU-less 68060 must raise vector 60, not just vector 11, for these four forms — the two are architecturally distinct exception classes with different frame shapes, and treating them as interchangeable produces a bench that cannot reproduce this silent-death class ✅. Conversely, code generating 68060 instructions (a compiler, a hand-patch) that emits any of the four forms must expect vector 60 on real hardware, with the frame and length properties above, and must not assume the format-$4 "advisory next PC" convention applies ✅. As a general statement about "any 68060 emulator" this is 🟡 — verified against exactly one emulator's codebase (found unable to raise vector 60 at all for an FPU-less configuration, until a narrowed guard closed the gap — see the vector-60 bench gap), not a survey of emulators.

What this page does not claim¶

Explicitly, so that nothing here gets quoted as more than it is:

Not that 040/060 support is coming, or that anyone has a date. 🔴 Any such claim is unverified.
Not that the A4000's processor works. The separate, verified finding that Amix boots fine on the AGA chipset with an AGA-aware bootstrap ROM is about the chipset, and it was proven with a 68030 + AGA configuration — the CPU wall is unmoved ✅. Do not conflate the two; see hardware.
Not that a 68040/68060 accelerator in a supported machine helps. The limit is the CPU the kernel executes on, wherever that CPU lives ✅.
Not that "68EC" parts are a route around anything — the MMU-less 68EC020/68EC030/68EC040 variants drop exactly the hardware Amix depends on ✅.

If you have an 040/060 machine today¶

Uniformly ✅.

You have	What runs Amix
A4000 (68040)	Not stock Amix. An 030 accelerator plus an AGA-aware Kickstart boots to console; X11 targets the supported display hardware, not AGA.
A3000 with an 040/060 card	Amix on the machine's own 68030, with the accelerator disabled — the kernel must execute on a 68020/68030 with a real MMU.
A 68060 accelerator with a software-68030 mode	This is the route the Z3660 takes: the Amix guest executes on a software 68030 with MMU, and Amix boots to multiuser on real hardware. The 060 runs the emulator, not Amix.

The table's last row is the software-030 route. There is also a distinct 060-direct route, where the 060 executes Amix as native code with floating point in software — measured on real 68LC060 silicon; see the FPU-less 68060 lane above. Both are real; they are different lanes.

Sources¶

sources/research-brief.md §2 (hardware and requirements: 68020/030 + real MMU + 68881/68882 mandatory; no 68040/68060; no A4000) — grounding for the headline limit ✅.
The hardware and kernel architecture pages of this site, which this stub extends rather than restates: the "kernel predates the 68040 MMU / the MMU model differs" finding, the no-soft-float requirement, and the AGA-versus-CPU correction ✅.
The Z3660 Amix-interop firmware fork — the shipped 68030 PMMU emulator that boots Amix on a real A4000 + Z3660, and the not-yet-wired 040/060 MMU model in the same codebase ✅ (the emulator is first-party and cited, not reproduced here; see emulation fidelity).
The existence of third-party community work toward 040/060 support 🟡 — reported, with no public, verifiable, bootable artifact at the time of writing; deliberately documented without further detail.
First-party 68040/68060 port campaign — the FPU-less-060 (68LC060) software-FPE lane, measured on real 68LC060 silicon across independent metal sessions (2026-08) ✅: the four unimplemented-effective-address instruction forms and their vector-60 routing; the format-$0 four-word frame whose PC names the faulting instruction and which carries no length field (the 16-byte immediate-operand forms, cross-checked by two independent decoders and a host-side harness); all four forms taking vector 60 on an FPU-less part; the pre-fix silent-SIGSYS class and its A/B disappearance after the vector-60 handler was added. Findings only — no vendor MC68060 / FPSP text and no port source is reproduced (paraphrase of measured behaviour), and no published 060 kernel is claimed. The bench-fidelity counterpart (an emulator that could not raise vector 60 for an FPU-less configuration) is on emulation fidelity.
The 68060's unimplemented-integer instruction class versus the stock SVR4 trap-dispatch table, whose populated range ends at vector 55 ✅ — the porting requirement noted under what a soft-FPU port would require: the vector the CPU uses for the 64-bit MULU.L/MULS.L/DIVU.L/DIVS.L forms has no handler in the stock table, so such an instruction reaches the default unhandled-vector path and the process is killed with no diagnostic — not emulated, and not an FPU matter, since the forms are integer ops. Full item, with the safe 32-bit spellings and the 🟡 CMP2/CHK2/CAS2/MOVEP class note, on quirks §53.