#tech • #retrocomputing • #serial-io
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:
- Unsigned application warnings from macOS.
-
Missing or unresolved serial library (
jssc.jar). -
Native binary mismatch:
libjssc.dylibwas 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.
💬 Comments