The Minimum Macintosh: 68K Hardware for AppleBridge over Open Transport, MacTCP, and Serial

The widening-impact note ended on a “footprint ceiling”: MacTCP and serial unlock lower-end machines in theory, but the daemon’s RAM appetite gates them in practice. This piece makes that concrete — the minimum 68K hardware to host AppleBridge over each of the three transports, Open Transport, MacTCP, and Serial — and then decomposes the daemon’s memory footprint to show exactly where (and how little) the transport choice moves it. The short answer is that the transport you pick barely moves the floor; the toolchain sets it. Captured as a design note on branch AppleBridge_mcp; not implemented.

Two floors, not one

“What is the minimum hardware?” hides two different questions, and conflating them is what makes the transport choice look more decisive than it is.

• The transport floor is the least machine on which a given network stack will run. This is what differs between Open Transport, MacTCP, and the Serial Manager — and it is what people picture when they ask.
• The toolchain floor is the least machine on which the AppleBridge daemon plus the MPW/ToolServer toolchain it drives will run usefully. This is transport-agnostic — it is set by RAM, 32-bit addressing, and a hard disk, none of which care which stack moves the bytes.

The result, stated up front: the toolchain floor sits well above the highest transport floor, so it is the binding constraint. The transport choice moves the minimum by one notch — a CPU grade here, a network card there — not by a class of machine.

The transport floors

What each stack demands of the iron, in isolation:

Three real differences live here. Open Transport raises the CPU floor to a 68030 and is by far the hungriest stack — it will not even load on the 68000/68020 machines (Plus, SE, Classic, LC, original Mac II) that MacTCP serves happily. MacTCP is the low-end TCP option, reaching back to the Mac Plus. Serial is the only transport that needs no networking hardware at all — every Mac from the Plus onward has two RS-422 mini-DIN-8 ports (modem and printer), so the host attaches with a serial cable (or a USB-serial adapter) and nothing else. Serial pays for that with speed: the printer port tops out around 230.4 kbps, orders of magnitude below the Ethernet path the transport benchmark measured.

If the transport floor were the whole story, the minimum machine for serial would be a 4 MB Mac Plus. It is not — because of the floor the transport does not set.

The floor the transport doesn’t set

AppleBridge is not just a network client; it is a daemon that hosts a development toolchain, and that imposes requirements no choice of stack can lower:

• The daemon’s partition is 12 MB preferred / 8 MB minimum, and the binary is marked 32-bit compatible. To grant the preferred partition the machine must run in 32-bit addressing mode and have the RAM to spare.
• The 32-bit dirty-ROM trap. The early 68030 Macs — the Mac II, IIx, IIcx, and the beloved SE/30 — shipped with “32-bit dirty” ROMs and are capped at 8 MB in their native 24-bit mode. Running them 32-bit (and past 8 MB) requires MODE32 or Apple’s 32-bit Enabler, or a clean-ROM replacement. The IIci was the first 32-bit-clean Mac. So even a perfectly capable 68030 SE/30 cannot give the daemon its preferred partition out of the box — it needs MODE32 first.
• The toolchain wants company in RAM. ToolServer and MPW each need their own multi-megabyte partitions, on top of System 7 (itself several MB) and the daemon’s. A machine that compiles comfortably wants on the order of 16–20 MB of physical RAM.
• A hard disk is mandatory. MPW, ToolServer, the System Folder, and the project tree do not fit on floppies; and the Basilisk shared folder is read-only from the Mac side, so compilation needs real local storage.
• System 7 throughout — AppleBridge requires the Apple Event Manager and Process Manager regardless of transport, and Open Transport pushes that to 7.1+.

Stack these and the real floor lands on a 32-bit-clean (or MODE32-equipped) 68030 with a hard disk and roughly 16 MB of RAM — for every transport. The network stack is a rounding error against it.

flowchart TB
    subgraph TF["Transport floor (varies)"]
        S["Serial: 68000, no NIC"]
        M["MacTCP: 68000 + NIC"]
        O["Open Transport: 68030 + NIC"]
    end
    subgraph DF["Daemon-partition floor (transport-agnostic)"]
        P["8–12 MB partition → 32-bit addressing
dirty-ROM Macs need MODE32"]
    end
    subgraph CF["Toolchain floor (transport-agnostic, binding)"]
        T["ToolServer + MPW + System 7 + hard disk
≈16–20 MB physical RAM"]
    end
    TF --> DF --> CF
    CF --> R["Real minimum: a 32-bit-clean 68030,
hard disk, ~16 MB — for all three transports"]

The memory footprint, decomposed — and where OT and MacTCP actually differ

The claim that “the transport barely moves the floor” deserves a numbers-level defence, because the intuition that Open Transport is “heavy” and MacTCP “light” is correct — it just lands in a place that does not change the daemon’s partition. The footprint splits into two scopes that are billed to different heaps, and the transport difference lives entirely in the second.

Scope 1 — the daemon’s own application partition (the SIZE heap, 12 MB preferred / 8 MB minimum). Its size is set by terms that have nothing to do with the network stack:

The partition is dimensioned by the worst-case peak: harvesting a large ToolServer reply briefly holds the Apple-Event descriptor (up to ~4 MB) and its 4 MB destination at once — the “~2×, 4 MB responses double-buffered” reasoning behind the 8 MB minimum, with 12 MB preferred as fragmentation headroom. That dominant cost is Apple-Event reply harvesting and the screenshot pixmap — both transport-independent. The transport’s own contribution is the last row, and it is negligible on either stack: Open Transport reads into the daemon’s own request buffer and allocates only a little endpoint state, while MacTCP asks the application to supply a small stream receive buffer (~8–16 KB) plus a parameter block or two. Within the partition, OT and MacTCP differ by a few tens of KB against an ~8 MB peak — immaterial. The partition is the same size on either transport.

Scope 2 — system-wide residency (the System heap and shared libraries), which is not charged to the daemon’s partition. This is where the two genuinely diverge:

So switching Open Transport → MacTCP saves on the order of ~1 MB of system RAM — and spends none of it inside the daemon’s 8–12 MB partition. That asymmetry is the whole memory story of the transport choice: it changes how much room the stack needs to load (which is exactly why MacTCP boots on a 4 MB Plus where OT cannot), and it leaves the daemon’s footprint untouched.

One scale note worth stating plainly: these multi-megabyte figures are caps, not steady state. An idle, PING-only bridge holds only code, globals, and endpoint state — a few hundred KB; the 4 MB buffers are reached only while a large command response or a screenshot is in flight. And they are daemon figures alone — ToolServer and MPW carry their own separate, transport-independent multi-megabyte partitions. (Library sizes above are period-typical estimates, not measured on this build, and assume the daemon’s single concurrent connection.)

Two tiers, concretely

The transport’s identity is only visible if you separate two modes of running the bridge:

• The thin bridge — the daemon connects, answers PING, and returns a screenshot, with no compiling. Here the transport floor is what one would expect to matter. Except it still doesn’t: the shipped daemon’s 8 MB minimum partition already exceeds a 4 MB Mac Plus, so even the thin bridge cannot run on the machine serial’s transport floor implies. The gate is the partition, not the stack.
• The full toolchain — SC, Link, the real point of AppleBridge. Entirely toolchain-dominated, ~16 MB and a hard disk.

In both tiers the only place the transport choice changes the bill of materials is the networking-hardware line: serial needs none, MacTCP and OT need a NIC or LocalTalk.

The minimum machine, per transport

Serial removes the most hardware (no card, lowest stack floor); Open Transport demands the most (a 68030/040 and the heaviest RAM). But all three land on the same class of machine, because the toolchain underneath them does.

Emulators make it moot

One honest caveat: none of this binds an emulated Mac. Basilisk II and SheepShaver satisfy every line above by configuration — allocate 32 MB, select a Quadra ROM, attach a virtual disk — which is exactly why the installer matrix called the emulators the easy host. This minimum-hardware question is for genuine 68k silicon, and secondarily a guide to how generously to configure the emulator (a Quadra-class profile clears every floor).

Verdict

If the goal is the least iron, Serial wins — it needs no network card and has the lowest transport floor, so it strips the hardware list to its shortest. But “least iron” still means a 32-bit-addressed 68030 with a hard disk and ~16 MB of RAM, because the daemon’s partition and the MPW/ToolServer toolchain set the floor, and the transport only trims its edges. The transport choice is a one-notch decision (a CPU grade, a network card), not a way down to a Mac Plus.

The footprint decomposition makes the mechanism explicit: an OT → MacTCP swap saves ~1 MB of system RAM but leaves the daemon’s 8–12 MB partition exactly as it was, because that partition is sized by Apple-Event reply harvesting and the 4 MB screenshot/response caps — not by the stack. So the lever that actually lowers the floor is a daemon memory diet — shrinking MAX_DYNAMIC_RESPONSE and MAX_SHOT_BYTES, or streaming them rather than buffering whole — not a different transport. That is the same conclusion the widening-impact note reached from the software side: widening the transport and slimming the daemon are complementary, and only the second one moves the wall. Until it does, MacTCP’s and serial’s reach toward the low-end Macs stays theoretical — the stacks would run there, but the toolchain will not.

Status: design note on branch AppleBridge_mcp; not implemented. The hardened, proven configuration remains a Quadra-class emulated Mac running Open Transport over etherhelper. The minimum-hardware and footprint figures here are for genuine 68k silicon and build on the transport-alternatives, installer-necessity, and widening-impact notes.