Amix on 68040 and 68060 — Current Status¶

Stock Amix 2.1 does not run on a 68040 or a 68060, and no Commodore release ever did. ✅ The stock kernel predates the 68040 MMU and drives the 68030 MMU directly through its HAT layer, so a 68040/68060 needs kernel-side work, not a driver ✅ — the hardware page and the quirks checklist state that limit for the stock kernel.

Since 2026-09-19 there is a public port that does it. asokero/amix-040-060-port — presented as "The Unofficial AMIGA/UNIX 68040/68060" port — takes your own stock AMIX 2.1c stand/unix, patches and relinks it on Linux, and produces one kernel image, unix-040, that boots on both a 68040 and a 68060 ✅ (the repo's README and build scripts). It is not a kernel distribution: the repository ships neither the stock nor a patched kernel image and no Commodore or AT&T source tree — it is a patch-and-override layer for a kernel you already own ✅ (the repo's own statement). Everything the port claims to run is listed below with its confidence.

Since 2026-10-29 the amigaux project develops against its fork, amigaux/amix-040-060-port, whose k46-module branch carries the module-kernel chain for amigaux 1.1; amigaux/amix pins a commit of it, and changes go back to Antti's repository as merge requests ✅ (amigaux/amix kernel/port/README.md).

This page is the one place that answers "can Amix run on my 040/060?". It keeps the technical record of why the stock kernel cannot, and what a port has to supply, because those facts did not change when the port appeared.

The public port (since 2026-09-19)¶

What it is and how it builds ✅¶

Uniformly ✅ — these are properties of the public repository itself (README, relink-040.sh, tools/check-env.sh), read at commit 087087d (2026-09-19):

Input: your own AMIX 2.1c full installation, specifically its vanilla stand/unix. The build checks that kernel's exact SHA-256 before doing anything and stops if it does not match the kernel the port was measured against.
Method: whole routines (MMU and cache handling, fault paths, floating-point glue) are replaced by weakening stock symbols and linking stronger implementations over them; smaller changes are asserted in-place edits (instructions, page-size constants, relocations, vector entries). The build rejects an unexpected input or patch site, and never modifies the source stand/unix — it works on a copy under build/.
Output: build/unix-040, one image for both CPUs; every CPU-specific path checks a loader-provided CPU type at run time.
Boot: it needs the patched AmigaOS loader unix_boot040 from the companion project asokero/amix-unix-boot — the stock boot2 enables the MMU with 68030 pmove instructions and gurus (8000 000B) on a 68040/68060 before the kernel ever runs. The native boot-partition path is still 68030-only.
Build dependencies (Linux): the gcc-cross-amix m68k-cbm-sysv4 toolchain, GNU m68k binutils, Python 3, and a pinned NetBSD 10.1 syssrc.tgz (hash-checked) from which Motorola's FPSP040, the 68060 support package and the NetBSD FPE are extracted at build time — they are not vendored.
Licence: new code MIT; the Motorola/NetBSD packages keep their own terms.

The port is by asokero; the A4000 + Z3660 line — the Z3660's emulated 030/040 and the real 68LC060 — was contributed by Jusii, this site's maintainer ✅ (the README's own attribution). Its STATUS.md is the port's canonical picture, KNOWN-ISSUES.md lists every defect found, and docs/ACCEPTANCE.md defines what each platform class can and cannot be evidence for.

What the port reports working¶

🟡 as a set — first-party claims from the port's README, each backed there by an acceptance document in its docs/ naming build, platform, test and result, but not reproduced by this site except where marked ✅:

Boots to login on a 68040, a 68060, a 68LC060, the Z3660's CPU emulation, and under Amiberry; real-hardware testing on an A3000 with a Mercury (040 and 060) and an A3640.
Caches on — instruction and data cache, data cache in copyback mode, by default.
FPU: Motorola's FPSP for the 68040 and the full 68060 package; the stock libm's fmovecr/fintrz sites go through it with results bit-identical to a 68030's (emulated 68040 ✅, stock libm). The 68LC060 software FPU (NetBSD's FPE) is merged and was brought up on real 68LC060 silicon (measured first-party ✅ — see the FPU-less 68060 lane), but the port has not accepted it, so an FPU-less part has no usable floating point yet ✅ (port STATUS.md @ baf3ddf).
The 68060's unimplemented 64-bit multiply forms used by the installed userland are emulated, with a counted fallback for unrecognised forms (compare the stock gap on quirks §53).
X11R5 on RTG hardware (Xsvga on a Piccolo, Xrtg on a VA2000) and Zorro III graphics: the VA2000 with its Zorro III firmware on both CPUs, at 2.45× its Zorro II bandwidth. (Why stock Amix cannot touch a Zorro III board without help — AutoConfig puts Zorro III boards at 0x40000000 and above, outside the kernel's identity map — is on the AutoConfig page.)
Console and telnet login, A2065 Ethernet, SCSI root, fsck, reboot/shutdown, NFS client (read and write), NetHack and the native C compiler.

RAM: the 040/060 kernels run at 128 MB on real silicon (measured on a real A4000D with a 68LC060 on a Z3660, 2026-09-14) ✅. The limit belongs to the kernel line, not the CPU: the 68040 and 68060 MMUs have no 2 KiB page, so these kernels use 4 KiB pages on both CPUs, and a 68040 gets the same one-region limit of up to 128 MiB 🟡 (no 68040 boot at 128 MiB recorded yet; port STATUS.md). The 68030 line differs: about 64 MB with 2 KiB pages. The old "16 MB" figure dates from the 68030 line under emulation and is no ceiling on the 040/060 line (on the stock 030 kernel it survives as a layout requirement — quirks §57); see the RAM ceiling. The port's own README answers the same question for its A3000 configurations: no 16 MB kernel ceiling observed; the current boot path uses only the one contiguous region that holds the kernel 🟡.

A4000T, first-party metal: Amix 2.1c boots to login: about 60 s after power-on on a real 68LC060 on a Z3660 in an A4000T, 060-direct (the card's CPU boot mode, not its 68030 emulation), with 128 MB of card RAM — 2026-09-25 ✅.

What the port reports as open¶

🟡 (the port's README, 2026-09-19): long-term stability is better but unproven; two intermittent faults (ISSUE-9, ISSUE-10) are captured on real hardware but not yet attributed; a few panics reachable from ordinary use are recorded but unfixed; shutdown -i0 crashes on the halt path (reboot works); init 6 hangs in userland (rc6) (a run-level change requested over telnet while nobody is logged in on the console also stalls in stock init on 68030 kernels — quirks §58; whether the port's report is that stall is not established 🔴); the s5 filesystem is unsupported; the 68060's store buffer and branch cache are still off; Zorro III is proven with one card only.

The two ways a 68060 runs Amix¶

060-direct — the port above: the 68060 executes Amix as native code.
Software-030 — the Z3660 route: the accelerator's 060 runs a software 68030 with MMU and the stock kernel executes on that; Amix boots to multiuser on real hardware this way ✅ (2026-06). The 060 runs the emulator, not Amix. This route is not part of the amigaux 1.0 kit, which runs 060-direct; support for the card's 68030 mode is planned for 1.1.

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 page).
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 (the public port reports meeting them with FPSP040, the 68060 package and NetBSD's FPE 🟡): 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).

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 is the work that became the 68LC060 support in the public port. 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 ✅. (A whole boot's idle traffic executes none of the four forms, so a zero vector-60 counter over a boot says nothing about the vector.)

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.

Two media limits: the stock boot floppy, and the CD filesystem¶

Neither limit is about the CPU port itself; both decide how an 040/060 machine gets Amix onto its disk.

The stock boot floppy cannot start an 040/060 kernel ✅¶

Two independent walls, either one sufficient:

The stock floppy loader dies first. The Amix boot floppy's bootstrap (reused unchanged by every Amix boot floppy built from it) turns the MMU off with 68030 pmove instructions — pmove to tc, crp, srp, tt0 and tt1 sit together in the bootstrap area of the stock 2.1 boot ADF. pmove does not exist on the 68040/68060: it is an F-line illegal instruction there, so the loader faults before any kernel is entered ✅ (the opcodes located in the stock boot ADF, sha256 0d8af1c0…; the same MMU-off code is the first of the two reasons the stock hard-disk loader cannot load an 040 kernel). The port's own loader, unix_boot040, runs from AmigaOS instead.
The full root filesystem does not fit. s5 is unsupported on the 040/060 kernels (the port's open list above 🟡; the problem is structural under their 4 KiB pages: an s5 root bus-errors in ordinary commands ✅, quirk 82), so an install miniroot for them must be UFS. A UFS miniroot carrying the full install toolset needs 957,440 bytes (≈935 KiB) under stock mkfs_ufs geometry — 56,320 bytes over an 880 KiB (901,120-byte) DD disk. Leaving out six tools the 040/060 install path never runs (three s5 tools, two tape-installer helpers and zcat) brings it to 856,064 bytes, which fits with 45,056 bytes free ✅ (a host-side UFS1 size calculator whose self-test reproduces a real Amix UFS root's measured geometry).

Both walls belong to the stock media, not to the CPU: a floppy route needs a loader without the 68030 MMU code and a trimmed miniroot. The project has built one — a 68060 boot floppy paired with that trimmed 880-block UFS root floppy, which booted, installed from CD and cold-booted the result in the emulator install matrix (2026-10-03) ✅ — but it is not part of the amigaux 1.0 kit, which lists the floppy (Gotek) route on the 68060 line as planned for 1.1. The 1.1 work boots a floppy pair on both lines with the project's own loader, in emulation so far ✅ (loadable kernel modules). The 1.0 kit installs a Z3660 with a real 68060 from a ready-made card or from CD (below); otherwise an 040/060 install starts from a prepared hard-disk image or RDB slice.

The CD filesystem: in the 1.0 CD-installer kernel, not in the port's relink¶

The stock kernel never had a CD filesystem, and the public port relinks your stock kernel without one ✅. The community cdfs (a port of ODFileSystem) now runs on the 68060 line: in the amigaux 1.0 kit the CD-installer kernel (68060-261010-70) carries it, and the CD install reads its packages through cdfs 1,3 from a CD on an A4092; the K1 card's own kernel does not carry it ✅ (the 1.0 kernel table and release notes). The obstacle that used to block a 68060 build — 64-bit integer multiplies in cdfs's kernel code, which a 68060 does not implement in silicon and stock Amix has no handler for (quirk §53) — was removed at the source: a scan of the kernel object for 68060-trapping forms went from 40 candidates to 0 (2026-10-02) ✅. On a real 68060 (an A4000 with a Z3660, the CD image on a ZuluSCSI behind an A4092) a first mount, ten unmount/mount cycles and a whole-file read equal to the ISO all passed 🟡 (one machine). The limits (release notes): the CD install is interactive only ✅, and only the CD filesystem may talk to the CD unit — never dd or fsck its /dev node, because a 512-byte read of a 2048-byte CD wedges the A4092 bus until power-off 🟡 (one machine). A Z3660 isoN image also presents as a read-only CD-ROM (quirk §60).

The 040/060 user address space¶

Two defects of the port's own 68040/060 VM setup, both fixed in emulation and not yet in a release. The fix is (4c6ea89, on k46-module), with its companion (c4058ad, on k46-module). The port records them as ISSUE-112 and ISSUE-110 in its KNOWN-ISSUES.md. The 68030 line has neither: its kernel uses no transparent-translation registers (the identity map).

Before the fix, ITT0 and DTT0 also matched user accesses ✅¶

Affected: every 68040/060 kernel of the port from its first 68040 bring-up up to 4c6ea89. That includes the amigaux 1.0 68060 kernels and the 1.1 68040/060 module kernel.

On those kernels the boot code loaded ITT0 0x003fc000 and DTT0 0x003fc060. Both have E=1 and S=1x, so the function code's supervisor bit was ignored and the window matched user accesses to logical 0x00000000–0x3fffffff as well. A user process could therefore read, write and execute physical memory below 1 GiB with no table walk ✅. In emulation (an A4000 with a 68LC060 on a Z3660) an ordinary user program:

read the chip-RAM vector at 0xC (a Kickstart address) and wrote it back;
read VPOSR at 0xDFF004 live from the custom chips;
read kernel text, the same longword adb reads through /dev/kmem.

A control access at 0x40000000, outside the windows, got SIGSEGV ✅.

The fix makes both registers supervisor-only (S=01): ITT0 0x003fa000 and DTT0 0x003fa060, as DTT1 (0x807fa060) already was. The kernel keeps its 0–1 GiB identity window, still cache-inhibited for data. A user access there now walks the process's own page tables and faults where nothing is mapped, as on the 68030. Verified in emulation: every access above faults (si_code 1 unmapped, 2 read-only), and the shared-library and exec tests pass ✅. Not yet verified on hardware or with X.

Statements elsewhere that DTT0 cache-inhibits the whole low 1 GB stay true for kernel accesses.

The root page is claimed twice unless the legacy segment-table growth is off ✅¶

Making the TT windows supervisor-only (above) exposed a second defect. User pages now go through the page tables, and on the 68040/060 kernel those tables were wrong at the very top.

The per-process 68040 root table (128 four-byte entries) lives in a 4 KiB page.
The retained stock hat_map still grows a legacy 68030 segment table for each new segment. hat_growsdt writes the 8-byte 030 section descriptor for quadrant s at root + s × 8, which covers native root entries 2s and 2s + 1.
In an even entry, the descriptor's first long (limit and descriptor type) reads as a resident pointer descriptor whose base is just above physical 0, that is, low chip RAM.

So user pages at 0–256 MiB in root entries 0, 2, 4 and 6 were looked up through chip-RAM words. Measured in emulation ✅: - a write to a read-only page at 0x00100000 (or to the zero page, quirk 97) looped in the fault path; - a page at 0x09000000 ended in PANIC: hat_pt2ptdat: invalid pte ptr.

While DTT0 matched user accesses, the window hid all of this.

The fix (c4058ad, on k46-module) stops hat_map's legacy growth for user address spaces (the kernel's own keeps it) and retires the legacy teardown. All sixteen entries 0–15 then fault correctly ✅ (emulation; hardware pending). The two fixes ship together.

Rule for anyone touching the 040/060 VM: the root page's first 32 bytes are claimed by both the native tree and the legacy 030 code unless the legacy growth is off.

What this page does not claim¶

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

Not that stock Amix runs on a 68040/68060. It does not; the port relinks a patched kernel from your own stock one ✅.
Not that the port is finished or production-grade. Its own README calls it hobbyist, unsupported, not for production use, with open issues listed above 🟡.
Not that the port's claims are independently verified here, beyond the rows marked ✅.
Not that "68EC" parts are a route around anything — the MMU-less 68EC020/68EC030/68EC040 variants drop exactly the hardware Amix depends on ✅.
Not that the AGA result is a CPU result. The separate, verified finding that Amix boots fine on the AGA chipset with an AGA-aware bootstrap ROM is about the chipset, proven with a 68030 + AGA configuration ✅; see hardware.

Package tools on 040/060: use APKG, not the stock binaries¶

The stock 1992 package tools are not safe on a 68060 kernel: installf -f crashed with a user bus error in an emulator run (2026-10-03), leaving a core file and a half-registered package entry, while the project's APKG installf did the same job cleanly ✅. Route runtime package operations through /usr/apkg/bin/… and treat the stock pkgadd/pkgrm/installf/removef as suspect — quirks §70.

If you have an 040/060 machine today¶

You have	What runs Amix
A3000 with a 68040/68060 card	The public port: relink your own 2.1c kernel, boot it with `unix_boot040` (on a 68060, run SetPatch first) 🟡. Or stock Amix on the machine's own 68030, with the accelerator disabled ✅.
A4000 (68040)	The port is the route for the CPU 🟡; the chipset side (AGA) needs an AGA-aware Kickstart for the console ✅. X on AGA is reported on the 68030 line only — the stock mono server and the third-party colour `Xaga` 🟡 (hardware) — and is untested on the 040/060 kernels. Stock Amix needs an 030 accelerator.
A3000, A4000 or A4000T with a Z3660	The supported route is the amigaux 1.0 kit: a 060-direct kernel on the card's real 68060/68LC060, from the ready-made K1 card (installed desktop plus interactive and unattended installers) or from the CD installer with an A4091/A4092 ✅ (128 MB on the 68LC060 measured ✅). Outside the kit: the port on the card's emulated 040 🟡, or the stock kernel on the card's software 68030 ✅ (measured on an A4000, 2026-06; not part of the 1.0 kit, whose support for the card's 68030 mode is planned for 1.1).
A 68LC060 (no FPU)	Only the port, with its software FPU (FPE) — stock userland dies on the first floating-point print without one ✅.

Sources¶

The 040/060 user address space (first-party record, 2026-11-01) ✅ — the 68040/060 port's emulator runs on an A4000 with a 68LC060 on a Z3660: a user-mode probe program, one access per run, before and after the fix (chip-RAM vector, VPOSR, kernel text checked against adb on /dev/kmem, the 0x40000000 control), and the root-page walks at 0x00100000 and 0x09000000 with the panic message. Port KNOWN-ISSUES.md ISSUE-112 and ISSUE-110 (2026-11-01); src/pstart040.s and src/hatmap_nosdt040.s; (4c6ea89, on k46-module) and (c4058ad, on k46-module). Not yet in a release; hardware pending.
The stock installf crash on a 68060 kernel and the APKG workaround (2026-10-03) ✅ — see quirks §70 (first-party record, 2026-10-03).
The amigaux 1.0 kit ✅ — the 1.0 hardware page and kernel table (amigaux.org/hardware: the Z3660 real-68060 line supported on the A3000, A4000 and A4000T; the card's 68030 and emulated-68040 modes not supported, 68030 mode and the 68060-line Gotek route planned for 1.1; which 1.0 kernel carries the CD filesystem) and Installer-NG (not public) docs/release-notes-amigaux-1.0.md (the K1 card, the CD route at cdfs 1,3, its limits).
asokero/amix-040-060-port — public since 2026-09-19; README at commit 087087d (2026-09-19): what it is, the build inputs and method, the unix_boot040 requirement, the "works / works less well / next" lists, the RAM and Zorro III answers, the licence and the no-kernel-binary statement ✅ for what the repo is and states, 🟡 for the capabilities it reports. Its STATUS.md, KNOWN-ISSUES.md and docs/ACCEPTANCE.md are the evidence the README points at.
asokero/amix-unix-boot — the patched loader the port requires (named in the port README).
sources/research-brief.md §2 (hardware and requirements: 68020/030 + real MMU + 68881/68882 mandatory for the stock kernel; no 68040/68060; no A4000) — grounding for the stock limit ✅.
The hardware and kernel architecture pages of this site: 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 stock Amix on a real A4000 + Z3660 ✅ (first-party; see emulation fidelity).
First-party A4000T metal record: Amix 2.1c reaches login: about 60 s after power-on on a real 68LC060 (the FPU-less 68060) on a Z3660 in an A4000T, running 060-direct (the card's CPU boot mode, not its 68030 emulation) with 128 MB of card RAM — 2026-09-25 ✅ (first-party record, 2026-09-25).
First-party metal record: the 040/060 kernel at 128 MB on the A4000D's 68LC060 (2026-09-14) ✅, with the dated retraction of the "16 MB" figure on the RAM ceiling.
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). 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.
The two media limits ✅ — the floppy loader: the 68030 pmove MMU-off sequence located in the bootstrap area of the stock 2.1 boot ADF (local read, 2026-10-02) and the same copyit.s code in the stock hard-disk loader (first-party record, 2026-08-18); the UFS miniroot size and the trimmed 040/060 root floppy: Installer-NG (not public) docs/miniroot.md ("The UFS miniroot — the 040/060 line" and "The 040/060 root floppy": 957,440 bytes needed, 56,320 over, 45,056 free with the six tools of miniroot/fd060.omit left out; the install-matrix proof of 2026-10-03, an emulator rig) and tools/lib/ufs_size.py. The CD filesystem: the amigaux 1.0 kernel table and release notes (above); amix-cdfs CHANGELOG.md (2026-10-02: no 68060-trapping 64-bit multiplies left in the kernel object, scan 40 → 0) and platform/amix-kernel/README.md ("No 32x32->64 multiply in the object"); the mount stress on a real 68060 behind an A4092 (first-party record, 2026-10-11) 🟡.
The 1.1 floppy pair and the k46 s5 row: amigaux/amix kernel/dlm/CHANGELOG.md (2026-10-25 "L11" floppy-change entries; 2026-10-27 s5 on the 4 KiB-page line) ✅.
The 040/060 page size and the 68040's RAM limit: amigaux/amix-040-060-port k46-module @ 587c18a STATUS.md, src/modelb_geom_probe.c (NBPP == 4096), docs/boot-path-map.md ✅/🟡 (the 68040 at 128 MiB not yet measured).