This note records a first: AppleBridge running not in an emulator but on real 68030 hardware — a Macintosh SE/30 with no Ethernet at all — reached over a plain serial cable. The bridge negotiated its protocol, read the machine’s hard disk, and captured the SE/30’s own screen, all over RS-422 with no network and no MPW on the target. The interesting part, as usual, was not the success but the two faults on the way to it: a hardware bomb and a silent baud mismatch.

The SE/30’s own 1-bit screen, captured over the serial cable — the AppleBridge daemon’s console showing the LISTDIR commands and the SCREENSHOT verb arriving live

The setup

The target is a Macintosh SE/30 (16 MHz 68030) running System 7.5, with a hard disk full of FoxPro and no networking hardware. The only wire is serial:

SE/30 modem port (mini-DIN-8, RS-422)  ──cable──▶  FTDI USB-serial  ──USB──▶  MacBook

On the Mac, host_server.py runs in serial mode (APPLEBRIDGE_SERIAL=/dev/cu.usbserial-… APPLEBRIDGE_BAUD=…) — no :9000 TCP listener; the wire is the daemon link. On the SE/30, only the faceless daemon is installed (delivered as a drag-install package, run once by the installer). There is no ToolServer and no MPW on the machine — this is the connectivity tier: STAT, HELLO, native directory reads, screenshots. Everything below needed nothing that a 1989 machine with a serial port and System 7 cannot provide.

Fault one: a hardware bomb (Error 11)

The daemon installed and auto-launched — and about thirty seconds later the SE/30 dropped a bomb: Error 11, a miscellaneous hardware exception. Every prior AppleBridge run had been on Basilisk II or SheepShaver; emulated serial had never exercised the real Z8530 SCC.

The cause is a classic of the platform: on a real Mac the SCC is shared between the serial ports and AppleTalk. With AppleTalk active, opening a serial port for raw I/O produces spurious SCC interrupts — exactly an Error 11. The fix was one toggle: Chooser → AppleTalk → Inactive. With AppleTalk off, the daemon opened the port and stayed up indefinitely. Lesson recorded: a serial target must have AppleTalk disabled.

Fault two: a silent baud mismatch

Now stable, the daemon printed “Invalid command format” in a loop, and the host fell back to a “legacy peer.” That looked like an old daemon — but it was a red herring. A byte-level probe of the line told the real story: the daemon answered every command with the same non-ASCII bytes. Consistent garbage is the signature of a baud mismatch — the UART sampling bits at the wrong boundaries. Probing the same port at a ladder of rates resolved it instantly:

baud=  9600:  ascii= 38%   (garbage)
baud= 19200:  ascii= 59%   (garbage)
baud= 38400:  ascii= 42%   (garbage)
baud= 57600:  ascii=100%   b'STATUS:-1\nSTDOUT:0\nSTDERR:39\ninitAE=0 found=NONE 0 no-ToolServer…'

At 57600 the response was perfect protocol. The daemon was running at its compiled default rate — the BAUD=9600 set in the Control Panel had never reached it (a prefs-propagation bug, tracked separately). The fix needed nothing on the SE/30: matching the host to 57600 was enough. The next line in the log was the one we wanted:

Serial mode: /dev/cu.usbserial-… @ 57600 baud
HELLO: negotiated protocol v2

The moral is procedural: when a serial link delivers consistent nonsense, suspect the rate before the wiring — and confirm it with a rate sweep, not a guess.

The payoff: reading the disk over the wire

With protocol v2 negotiated, mac_status answered from the machine itself — home=Hard Disk 2048:AppleBridge:, net=Serial, round-trips around 33 ms. Then the thing we came for: a directory read of the boot volume, served by the daemon’s native PBGetCatInfo walk (LISTDIR) — no ToolServer, no network in the loop:

Hard Disk 2048:
  Anwendungen/            Systemordner/         System 7.5 - Bitte lesen
  FoxStart.app  Genscrn.prg  Transprt.prg   (FoxPro, creator 'FOXX')
  SimpleText    Microsoft/   old Development/   AppleBridge/  …

The genuine contents of a real SE/30 — a FoxPro workstation running a German System 7.5 — arriving over a serial cable. And the screenshot at the top of this page is the same machine’s own screen, captured over that same wire: the daemon’s console with our LISTDIR commands and the SCREENSHOT verb landing live (it caught itself being read).

What this closes

This is the last piece of the serial-reach arc. The transport backend, the host serial mode, the drag-install package, and the Control-Panel selectors were all in place; what remained — the one thing an emulator could never prove — was the live round-trip on real serial hardware. It now works end to end on a Macintosh SE/30: a thirty-five-year-old machine with no business on a modern network, driven by an AI over a wire, answering with its own disk and its own screen.

The Control Panel on the SE/30, over serial: NET=Serial and Modem (A) selected (the port row un-dimmed), Baud showing 9600 — while the daemon actually runs at 57600 (the preference never propagated) — and the window running off the bottom of the 512x342 screen, its button strip clipped below the edge.

Two honest follow-ups fell out of the run: the daemon’s on-screen windows are too large for the SE/30’s 512×342 display and need a compact-Mac layout, and the BAUD= preference did not propagate from the Control Panel to the daemon. Neither blocks the result; both are now on the list.

Verified live on a Macintosh SE/30 (System 7.5) over RS-422 at 57600 baud: protocol v2, STAT, a native LISTDIR of the boot volume, and a screenshot of the machine’s own screen — all with no ToolServer and no network on the target. The serial transport backend and drag-install package shipped earlier (PRs #53/#54); this is the round-trip that proves them on the metal.