Bootstrapped and Beamed In: Connecting an Apple II //c to My M2 MacBook (Part 1)

#tech

Bootstrapped & Beamed In: Connecting an Apple //c to an M2 MacBook (Part 1)

Overview

This project documents my process of getting a 1984 Apple //c communicating with a modern M2 Pro MacBook using ADTPro, a Java-based disk transfer tool for Apple II systems.

The objectives for Part 1 were:

  • Get ADTPro running natively on macOS (ARM).
  • Configure Java and serial libraries correctly.
  • Validate the serial adapter stack before any physical transfers.

Spoiler: it works, but it required a few deep dives under the hood.

Project Goal

The end goal is a reliable pipeline that lets me move software from my Mac to the Apple //c:

Mac → ADTPro → Serial Interface → Apple //c

That covers ProDOS, utilities, and games without depending on fragile, 40-year-old floppies.

The main constraint: the Apple //c speaks DIN-5 serial, and modern Macs don’t.

Hardware & Adapter Chain

To bridge nearly four decades of hardware standards, I ended up with this stack:

Mac (USB-C)
  ⟶ USB-C → USB-A adapter
  ⟶ USB-A → Serial adapter (DE-9)
  ⟶ DE-9 → DIN-5 null-modem cable (Apple //c modem port)

At the time of writing Part 1, the DIN-5 null-modem cable was still in transit, but I wanted the software side fully working so that, once the cable arrived, it would be plug-in and go.

Software Environment

Component Version / Notes
macOS Ventura (ARM64)
Java Runtime OpenJDK 17
ADTPro v2.1.0
Serial Library JSSC 2.9.2

ADTPro relies on Java plus the JSSC library to talk to USB-serial hardware. That combination exposed a few compatibility issues on a newer ARM-based Mac.

Initial Roadblocks

ADTPro would launch via the GUI but crash on startup. The main problems were:

  1. Unsigned application warnings from macOS.
  2. Missing or unresolved serial library (jssc.jar).
  3. Native binary mismatch: libjssc.dylib was compiled for Intel, but the machine is ARM.

That pushed the project out of “double-click the icon” territory and into “treat this like a real piece of tooling” mode.

Setup & Fixes

1. Getting Past macOS Security

macOS initially blocked the unsigned JAR file. The quick fix:

System Settings → Privacy & Security → "Open Anyway" / "Allow"

That allowed the GUI to open, but the serial stack still wasn’t functional.

2. Fixing the Java Classpath

The jssc-2.9.2.jar library existed on disk, but ADTPro couldn’t locate it. The solution was to put it where the app expected it and relaunch from the terminal:

# Ensure jssc.jar exists in the main lib folder
cp lib/jssc/jssc-2.9.2.jar lib/jssc.jar

# Launch ADTPro with an explicit classpath
java -cp "lib/*" org.adtpro.ADTPro

With that in place, ADTPro would at least start consistently from the command line.

3. Resolving the Native Library Mismatch

Next, Java threw an UnsatisfiedLinkError for libjssc.dylib — the native piece that actually talks to the hardware. The shipped binary targeted x86_64, not arm64.

I unpacked the JSSC JAR to see what was inside:

jar xf lib/jssc.jar

Inside, there was a platform-specific native library at: natives/osx_64/libjssc.dylib. I moved that into ADTPro’s lib/ folder and launched with an explicit library path:

cp natives/osx_64/libjssc.dylib lib/

java -Djava.library.path=lib -cp "lib/*" org.adtpro.ADTPro

At that point, ADTPro was up, stable, and able to see the USB-serial adapter correctly.

Key Takeaways

  • Treat GUI utilities like developer tools when they fail – launch them from the terminal so you can see what’s actually happening.
  • Unsigned Java apps on macOS are noisy but manageable with the right security overrides.
  • JSSC depends on platform-specific native binaries; Intel vs ARM matters more than expected.
  • Serial tooling on modern macOS is still very possible — it just requires a bit of “jar-level archaeology.”
  • Good logging and a willingness to dig into packages makes debugging much faster than treating the app as a black box.

Current Status (End of Part 1)

Item Status
ADTPro running on macOS ARM
Serial adapter recognized
Native library resolved
DIN-5 null-modem cable 🔜 In transit
Data transfer tests 🔜 Part 2
ProDOS bootstrapping 🔜 Part 2

Coming in Part 2

Once the DIN-5 cable arrives, the next phase will cover:

  • Physical connection to the Apple //c modem port.
  • Bootstrapping ProDOS from scratch.
  • Serial data transfer performance and reliability.
  • Loading games and utilities onto real hardware.
  • Lessons learned from bridging retro systems to modern infrastructure.

I’ll also publish the full command list and configuration notes to GitHub for anyone who wants to replicate the setup.

Author: Ben Tankersley — Technical creator at CTRL+Strum, building weird bridges between music, vintage hardware, and modern infrastructure.

~ ben.tankersley ⌁
echo "last note sent."
cd /blogs/the-wall

💬 Comments