Running Amix on Real Hardware

If you have an actual Commodore 68030 Amiga, you can run Amix on it — but the machine, CPU, RAM, SCSI IDs, and graphics must fall inside a narrow envelope the kernel hard-codes. This page collects what you need to bring up Amix 2.1 on real iron: which machines and ROMs work, the disk-ID-6 / tape-ID-4 rule that trips up everyone, how people substitute modern flash-SCSI (ZuluSCSI) for the long-dead hard disk and tape drive, and the realities of feeding it a distribution and a network in 2026.

Most of the machine facts here are ✅ verified from the Ditto paper and the install scripts on the root floppy. Almost everything about modern substitutes (ZuluSCSI, tape-free installs, finding 10 Mbps Ethernet) is 🟡 community-reported — credible hobbyist practice, not primary-verified. Where this page is uncertain it says so.

If you just want to run Amix today, emulation is far easier than real hardware. Start with the WinUAE setup guide; this page is for people committed to original Commodore gear. The actual OS install steps (partitioning, streaming the distribution, kernel build, patch disk) live in the installation walkthrough and apply identically on real hardware and emulators — the only difference is the SCSI back end.

The two official machines

Amix shipped on exactly two Commodore configurations. ✅

A3000UX

The reference platform. ✅

• 68030 @ 25 MHz with a 68882 FPU @ 25 MHz (the FPU is mandatory — see below).
• 1–2 MB Chip RAM + up to 8 MB Fast RAM as shipped.
• On-board (A3000) SCSI controller.
• A3070 QIC-150 tape drive (the original install medium).
• A2065 Zorro II Ethernet card (10 Mbps; see networking realities).
• Optional A2410 "Lowell" color graphics card (TMS34010, 1024×768) for color X11; without it you get monochrome X on the built-in chipset.
• "Superkickstart 1.4" bootstrap ROM: a special A3000 boot ROM that decides at power-on whether to boot Amix or AmigaOS. Hold the right mouse button at power-on to load an AmigaOS Kickstart instead of booting Amix; default (no button) boots Amix from SCSI. ✅
• 3-button mouse (X11 and the AT&T windowing tools expect three buttons).

A2500UX

An A2000 pre-configured for Unix. ✅ The "UX" suffix means it shipped with Amix pre-installed; the hardware is otherwise a standard A2500:

• A2000 chassis + A2630 accelerator (68030 @ 25 MHz + 68882 FPU).
• A2090 or A2091 Zorro II SCSI controller (no on-board SCSI on the A2000).
• First publicly demoed at Uniforum, Dallas, January 1988 (then running SVR3, not SVR4). 🟡 (event + year documented; the machine and month are community-reported)

A2500UX has no Superkickstart. The dual-boot-by-mouse-button behavior is an A3000UX feature of its boot ROM ✅. On an A2500UX you boot from the SCSI disk (or a boot floppy) the normal way.

Hard requirements (the kernel will not negotiate)

These are absolute and enforced by the kernel or the install scripts; you cannot patch around most of them because the relevant source was not shipped. ✅ throughout unless tagged.

Requirement	Detail	Why it's fixed
CPU	68020 or 68030 with a real MMU	Amix uses the 68030 MMU (HAT layer); a 68EC020/68EC030 (no MMU) cannot run Amix
FPU	68881 or 68882 mandatory	No soft-float; the kernel and userland assume hardware FP
No 68040/68060	A4000 cannot officially run Amix	Kernel predates the 68040 MMU — see the 040/060 status page
Fast RAM	4 MB minimum; the old "16 MB maximum" is retracted	No first-party sighting of the "mis-mapped SCSI drive"; 32/64 MB run on stock kernels, 128 MB on the 040/060 kernels — the real limit is describable RAM (RAM ceiling)
SCSI disk	ID 6 (convention)	Installer prompts for the disk target; ID 6 is the universal default, baked into device names once installed
SCSI tape	must be SCSI ID 4	Hard-coded in install scripts (/dev/rmt/4h)
No Zorro III	Zorro II cards only	The memory-mapping layer can't address Zorro III space, and that source wasn't shipped, so it can't be community-fixed

For the full hardware story — supported SCSI/graphics/network/serial cards, the AUTOCONFIG mechanism, the RAM-ceiling failure mode — see the hardware reference page.

On the Z3660 accelerator the emulated modes size the Amix window with the amix_ram knob (default 16 MiB, bounded 128; the firmware docs recommend 64 for a shipping config) ✅ — the earlier "compile-time fixed, no knob" statement described the investigation-era firmware. Under the real-CPU mode the card's 128 MB is presented directly and the 68060 kernels run there daily ✅. When the Amix-interop mode is enabled, its emulator presents a single window of that size and maps a dummy bank above it so nothing can coalesce past the ceiling; the same mode disables the accelerator's large CPU-RAM board, which is incompatible with the Amix memory map. (The dummy bank is guarding the separate total-describable-RAM limit — see the Amix RAM ceiling.) The historical "address not in section 1" panics came from presenting more than 16 MB or a split/second window — never from 16 MB exactly, which is the intended, working configuration. (One consequence: the metal Amix console is display-only, so unlike emulation there is no serial-log capture of the SVR4 boot banner's memory line.)

The Z3660's effective config is two layers — the preset overlay wins. ✅ z3660cfg.txt declares the hdfN disk-image files, but the active presets/presetN.txt (chosen by presets/preset.txt) overrides every key it sets — boot mode, amix_mode, the Kickstart choice, and the scsiN <hdf-index> assignments — and the env parser handles only the scsiN indices, never hdfN declarations. The practical trap: editing z3660cfg.txt alone to re-map which image sits on which SCSI ID is silently inert when a preset carries scsiN lines. Change both layers (declare the image in the base, remap the SCSI ID in the active preset), and always confirm from the firmware's own boot print — it logs the effective join as [CFG]/[ENV] SCSIn assigned to ….

The Amiga's own keyboard is a second, live input into the accelerator's firmware boot menu ✅ — and that menu is a single-key consumer, where one keystroke can start a destructive operation. A host-side console guard on the serial line can neither see nor mediate it: the guard's whole model is that serial is the only way in, and it is not, whenever someone is physically at the machine. Rule: no scripted boot-menu operations while anyone is hands-on at the box. The same property bites confirmation prompts — a firmware overwrite? (y/n) can be answered by a stray keyboard byte before the scripted answer arrives over the serial line, so a script that sends its command and its confirmation as separate writes has a race it cannot see. Send both in one write, so the answer is already in the serial FIFO when the prompt reads it.

For the reset, halt and serial-capture laws that go with this — a warm reset is not a clean-state reset, a successful remote halt looks like a transport failure, and a stray reader eats the console stream — see quirks 47–52.

Why SCSI ID 6 and ID 4 matter so much

The install scripts on the root floppy stream the distribution from the tape at the literal /dev/rmt/4h / /dev/rmt/4hn, and reference the disk through a $SCSI variable (/dev/dsk/c${SCSI}d0s${BOOTPART}). ✅ The tape must be at ID 4 — the installer looks nowhere else for the distribution media. The disk is ID 6 by convention: the installer prompts for the disk target, so another ID would work, but pick 6 — the chosen ID is baked into the device names (/etc/vfstab) once installed, so changing it later means editing that file 🟡. Set the tape to SCSI ID 4 and the disk to SCSI ID 6 before you start. Getting the tape ID wrong is the single most common reason a real-hardware install can't find its distribution media. ✅/🟡

This same ID rule is what the emulator configs reproduce: WinUAE/FS-UAE put the disk hardfile on SCSI ID 6 and the tape image on SCSI ID 4 (see the WinUAE guide).

Modern SCSI: replacing dead disks and tape with flash 🟡

Original SCSI hard disks and QIC-150 tape drives are 30+ years old, unreliable, and increasingly impossible to source. The community substitutes a modern SCSI emulator — most commonly a ZuluSCSI (or BlueSCSI-class device) — that presents SD-card-backed images as SCSI devices. This is 🟡 community-reported hobbyist practice; it is not described in any Amix primary source.

The principle is straightforward because Amix only cares about SCSI IDs, not the underlying media:

• Configure the SCSI emulator to expose a disk image on SCSI ID 6 (this becomes your c0d0 Amix hard disk, RDB-partitioned). 🟡
• Configure a second device on SCSI ID 4 to stand in for the tape, if you need a tape-style install path. 🟡

Warning (🟡, unverified depth): This page does not have a primary-verified ZuluSCSI profile for Amix. SCSI emulators vary in how faithfully they emulate a sequential (tape) device versus a block (disk) device, sector sizes, and parity/termination behavior — and Amix's SCSI handling is old and picky. Treat any specific device-profile recipe you find online as unverified until you reproduce it. The reliable, well-trodden path most people use is the tape-free install below, which sidesteps tape emulation entirely.

For how the disk is laid out once Amix sees it (RDB scheme, the 2 MB boot partition, swap, UFS-vs-s5 choice), see filesystems and disks and the installation walkthrough.

SD cards through the Z3660 on an extension cable need sd_clock 25 ✅ (2026-09-14): at the firmware default of 50 MHz the card does not enumerate and Amix sees no SD-backed devices at all; at 25 it boots and passes a write/read-back stress cleanly, at roughly 15 % lower sequential throughput — numbers on the benchmarks page.

Keep partitions reasonably small 🟡

Keep Amix partitions roughly ≲ 1 GB each. 🟡 This is community guidance, not a documented hard limit — but combined with the 16 MB RAM ceiling and the era's filesystem assumptions, oversized partitions are a known source of trouble. A modern SD card is enormous relative to what Amix expects, so size the Amix RDB partitions conservatively rather than the card.

Tape-free install (dd/cpio from another host) 🟡

You do not need a working tape drive to install Amix. The distribution is streamed from tape only because that was the 1992 medium; the actual data is a cpio archive, and you can deliver that archive by other means. Building the distribution onto a disk/swap area from another host (Linux or AmigaDOS) and extracting it with cpio is documented on comp.unix.amiga 🟡.

The mechanism mirrors what the installer does from tape. The install scripts on the root floppy run, in effect: ✅ (the command form is verified from the root.adf scripts)

# What the installer does when reading from real tape at SCSI ID 4:
dd if=/dev/rmt/4hn bs=256k | cpio -imdcu
# (a variant pipes through zcat for a compressed stream)
#   dd if=/dev/rmt/4hn bs=256k | zcat | cpio -imdcu

The tape-free approach replaces if=/dev/rmt/4hn with a regular file (or a raw partition such as swap) that already contains the same cpio stream — written there beforehand from another machine. 🟡 In outline:

1. On a modern host, write the Amix distribution cpio image to a SCSI/SD region that the Amix installer can read as a device (for example, a spare partition or the swap area). 🟡
2. Boot Amix from the boot floppy and into the root miniroot as usual (walkthrough).
3. Point the extract step at that file/device instead of the tape: dd if=<file-or-device> bs=256k | cpio -imdcu. 🟡

Note: The exact device/partition you stage the image on, and how you wire that into the installer's package flow (amixpkg -i -r /mnt), are not primary-verified here — the precise recipe is community lore and varies by setup. The fact that tape-free installs are possible and were done is 🟡-documented on comp.unix.amiga; the byte-level how-to is left to that source. See the installation walkthrough for the package-install flow this plugs into.

A verified from-scratch metal install (Z3660, no tape, no CD) ✅

Beyond the community tape-free lore above, a complete from-scratch install has been proven end-to-end on a real A4000+Z3660 ✅, using a self-booting RAW source disk — a single .hdf deployed to the accelerator's SD card and mapped at SCSI id 0, carrying its own installer miniroot, boot chain, driver payload, and a raw package-image slice. Load-bearing facts that generalize:

• A purpose-built miniroot kernel boots straight from SCSI id 0 (the source disk), while the blank target sits at its own id — no floppy, no CD, no tape in the loop. The 16 MB memory contract holds exactly, with no D245.
• Boot-priority does the post-install hand-off for free. Give the source disk's bootable partition a lower RDB boot priority than the freshly-written target's; the Kickstart scan cleanly skips the target's empty bootable slice before install, then — once the installer has written the target's real boot chain — the target wins the next scan with no media swap or config edit.
• The device-name minor number is (slice << 4) | id on the Z3660 SCSI stack, the same encoding as everywhere else — useful when hand-deriving /dev nodes on the metal box.
• The outcome is byte-identical to an emulator-built install: the installed tree's attestation digest matched the bench reference exactly. Emulation-built install media produces a bit-for-bit identical result on real hardware.
• An installer-minted root can be attested end-to-end from the box's own package database ✅ — the digest is computed over the installed standard package set as the box itself records it (/var/sadm), not over the media it came from. That is what separates a golden image from a disk that merely boots: its contents are provable against the installer's own manifest without trusting the host that built it.
• Budget minutes per iteration on metal. A cold power-on to a networked multiuser box (run level 2, the ethernet interface up) takes ≈270 s on this rig, reproduced over two cold boots ✅ — an order of magnitude slower than the emulator loop, and the single biggest cost in any metal test matrix.
• Ops note: some large packages hold the console silently for many minutes during extraction — that is normal, not a hang; the metal Amix console is HDMI-only (the accelerator's serial log ends at the firmware→Amix handoff).

A from-scratch install on a real 68060 — unattended, from an SD card (Z3660, 2026-09-15) ✅

The line above installed under the Z3660's emulated CPU. On 2026-09-15 the same installer completed its first install on real 68LC060 silicon (A4000D + Z3660, bootmode CPU, 128 MB), unattended: insert the card, power on, the miniroot boots the proven 060 kernel, the installer authors the target and installs the eight base packages in about 15–17 minutes, halts, and the installed disk boots to a login prompt in about a minute — roughly 2.7× faster than the emulated-040 reference for the same packages ✅. Two facts made it work, both earned on the wire: the miniroot must root on the Z3660 (card 1) and never touch the phantom A3000 SCSI controller at card 0, whose first register write bus-errors in kernel mode on a real A4000 (the emulated modes supply a chip there; the metal does not) ✅; and the first-boot script must not run the stock atdevs /dev probe, which opens a card-0 node first ✅. The installed system then updates its catalog from the public package repository at pkg.amigaux.org over the Z3660's own ethernet and installs and removes packages with no operator configuration ✅ (hostname form only: the repository is a name-based virtual host, so a bare IP in the client's repo= line returns 404 ✅). The next day the same system pulled the stock X stack (xcore, xbasic, olcore — about 11 MB, fitting a 100 MB disk with room to spare) and X2410 came up on the 68060 at 128 MB — the first X server started on a real 060 Amix ✅; start it as xinit -- /usr/bin/X11/X2410 (the server is not found by name on the default lookup path ✅). One client limit surfaced on the way: the 1992 apkg fetch had a 60-second total deadline, which an 8 MB package cannot meet at the ~37 KB/s a single TCP stream from the 68060 reaches against a distant host; the fix is an idle timeout that resets while bytes flow ✅ (shipped as the next apkg version). One operational law from the same day: the unattended raw install has no blank-target gate — a power-cycle with the source medium still mapped re-installs and erases the target — so the card ships two firmware presets, install and installed, and the operator switches after the halt ✅.

Non-standard tape drives: viper_kludge 🟡

If you do use a real tape drive that isn't the original A3070, note that the root floppy ships viper_kludge (by Frank "Crash" Edwards), which patches kernel memory so a non-standard Archive Viper 2150S drive works. ✅ (it is present on root.adf, with viper.README). Its own README warns it is incompatible with the A3070, Caliper, Wangtek, and Sankyo drives — do not run it with those. ✅ It does not help with arbitrary modern SCSI-emulated tape devices; it is specific to the Viper 2150S.

10 Mbps Ethernet realities

Amix networks over the A2065 Zorro II card (Amix device aen0). ✅ The A2065 is a 10 Mbps card 🟡 (10Base2 coax / 10BaseT in the original A3000UX configuration), and that creates practical problems on a 2026 network:

• Modern switches are gigabit-only and often won't negotiate 10 Mbps. You typically need an old 10/100 hub or switch, or a media converter that explicitly supports 10BaseT, between the Amix machine and your modern LAN. 🟡 (This is general 10 Mbps-vintage-hardware reality, widely reported by the retro-Amiga community rather than stated in an Amix primary source.)
• For coax-only cards, you may need a 10Base2-to-10BaseT converter and proper terminators. 🟡

On the software side (✅/🟡, from the brief's networking notes):

• Static IP only — there is no DHCP client. ✅/🟡
• DNS is off by default; Amix resolves names from /etc/hosts. To enable resolver DNS you relink the socket library and configure a resolver:

  ln -f /usr/lib/libsockdns.so /usr/lib/libsocket.so
  # then configure /etc/netconfig, run in.named (or point at one), and write /etc/resolv.conf
  

• The default route requires a metric: route add default <gateway> 1. ✅/🟡
• NFS client and server work. SLIP is buggy (reboot between sessions); there is no PPP. 🟡

For the fuller networking picture (STREAMS TCP/IP, TLI + sockets, the A2065/Hydra options), see the networking page.

What "real hardware" buys you, and what it doesn't

Be honest with yourself about the trade-off:

• Emulation (WinUAE) is the reference target and is what almost all current driver work is built and tested against. ✅ It is easier to set up, snapshot, and recover. Start there: WinUAE, FS-UAE. (Note: Amiberry 8.x also runs and installs Amix now — it emulates the A3000 SCSI disk + tape. ✅)
• Real hardware gives you authenticity and native I/O, but you inherit every hard limit on this page plus the sourcing problem for 68030 boards, FPUs, working SCSI/tape, and 10 Mbps networking.

If your goal is to develop drivers or explore the system, emulation is the pragmatic choice. If your goal is to run Amix on the metal it was written for, this page is your checklist.

See also

• Installation walkthrough — the OS install steps (partitioning, streaming the distribution, kernel build, patch disk) that run identically on real hardware
• Hardware reference — supported cards, AUTOCONFIG, the 16 MB ceiling, RAM/CPU/MMU requirements in depth
• Emulation with WinUAE — the recommended way to run Amix today
• Filesystems and disks — RDB layout, the 2 MB boot partition, UFS vs s5
• Networking — STREAMS TCP/IP, DNS, NFS, the A2065
• Quirks checklist — the SCSI-ID, RAM-ceiling, and Y2K gotchas in one place
• amigaunix.com — the most authoritative community resource for end-user install/history/media

Sources

• Research brief §2 (Hardware & requirements: A3000UX/A2500UX specs, Superkickstart, 68020/030+MMU+FPU mandatory, 4–16 MB Fast RAM, SCSI disk ID 6 / tape ID 4, no Zorro III, no 68040, A2065 networking) — primary facts ✅, expansion notes 🟡.
• Research brief §9 (Installation flow: dd if=/dev/rmt/4hn bs=256k | cpio -imdcu and … | zcat | cpio variants reconstructed from amix_21_root.adf scripts; viper_kludge / viper.README; tape-free installs documented on comp.unix.amiga 🟡).
• amix_21_root.adf analysis via tools/inspect-adf.sh (install scripts: BPART=/dev/dsk/c${SCSI}d0s${BOOTPART}, /dev/rmt/4h, viper.README) ✅.
• Research brief §11 (Networking: A2065 aen0, static IP only, DNS off by default + relink recipe, route add default … 1, NFS, SLIP/PPP) ✅/🟡.
• Research brief §8 (Emulation: WinUAE reference target; Amiberry 8.x adds A3000 SCSI + tape support — BlitterStudio/amiberry issue #1376, implemented). First-hand confirmation on Amiberry 8.1.6.
• ZuluSCSI/flash-SCSI substitution, old hub / media-converter need, and the byte-level tape-free recipe: community-reported (🟡), retro-Amiga community practice and comp.unix.amiga; not primary-verified in any Amix source.
• The Z3660 Amix-interop firmware fork — the compile-time-fixed single 16 MB window (AMIX_A3000MEM_MB), the dummy bank preventing coalescing past the ceiling, the amix_mode-forces-CPU-RAM-off contract, and the "not in section 1" panics coming only from >16 MB / split windows: read from Z3660_emu/src/uae/uae_emulator.cpp, Z3660/src/config_file.c, AMIX_SCSI_design.md, docs/AMIX.md ✅.
• First-party thermal soak session, real A4000D + Z3660, 2026-08-31 ✅ — the Amiga keyboard as a second live input into the accelerator's firmware boot menu, found when a stray keyboard byte answered a firmware confirmation prompt ahead of the serial-side answer; and the single-write fix that closes the race. Performance and temperature figures from the same session are on performance benchmarks.
• The 2026-08-14/15 golden-regeneration event (workspace record), real A4000 + Z3660 ✅ — the first root image minted by the installer rather than inherited, attested from the box's own package-contents database and cold-booted twice; and the ≈270 s cold-power-on-to-networked-multiuser figure measured across those two boots. Image names and digests are project bookkeeping and are deliberately not reproduced here.
• The Installer-NG Waves 5–6 field campaign (amix-installng @ 7106f1b, amix-packagemanager @ 4539ad2), 2026-07-22/24 — a blank-disk→bootable-install effort that root-caused these platform behaviours on the Amiberry bench and the real A4000+Z3660 (acceptance-run captures, s5/UFS state reads, and the on-metal digest attestation) ✅ (🟡 where tagged).