Smart Hamr: the card is a Liron card and FujiNet boots ProDOS through it
What I tried
The FPGA implements the whole Liron card: IWM, 4K ROM, all the TTL glue. I started from Steve Chamberlin’s original Yellowstone Verilog and hit a dead end. I asked him, and the answer was that the open-source release is the version he gave up on, with major problems, and the current Yellowstone II is a closed-source overhaul. So I went to the source documents. The IWM is built from the IWM patent, US 4,742,448, and the IWM Spec rev 19, cross-referenced against a disassembly of the Liron ROM to check every register access.
On the other side of the GPIO header is an ESP32 DevKitC WROVER running FujiNet firmware, wired straight to the FPGA’s 3.3 V I/O with no level shifting. The Apple’s 5 V side goes through the ‘245 transceivers as usual. I have a fork of the FujiNet firmware with hardening changes. I wanted to change as little as possible, but hardcoded timing and error paths that only make sense on production hardware needed fiddling.
What I measured
- ProDOS boots from the FujiNet SD card. I can browse FujiNet host repos, mount images, copy files to real floppies through the DuoDisk, load Merlin 8, run the Contiki browser, and play Total Replay.
- Moving the Q6/Q7 state bits to /DEV-clocked latches, as the patent shows, made things about 2.5x more stable.
- Two 22 pF caps to ground on the ESP32 lines took the maximum consecutive error burst from 848 to 5. Control command data packets went from failing their first checksum every time to failing sporadically.
- Total Replay hammers SmartPort loading game after game and holds up more often than not. There are still occasional hiccups and timeouts under heavy load.
What broke or surprised me
The IWM latches state off address bus edges under 500 ns long, serializes with FCLK-counted bit cells, and has handshake timing that punishes being one clock off.
- Metastability on Q7. Sampling the address bus directly in the FCLK domain put glitch spikes on the Q6/Q7 state bits. The /DEV-clocked latches from the patent fixed it.
- Write serializer race. A 2-flip-flop synchronizer on Q6 was correct for the clock domain crossing but narrowed the write-enable window to a 0.4 FCLK margin. The Liron ROM’s Q6 toggle loop during drain sequences missed writes, the serializer underran and checksums failed. Backing off to a single metastability stage got ProDOS booting.
- UNMOUNT deadlock. The ESP32 ISR only accepted data packets with a bad checksum for one specific control code. UNMOUNT uses a different code, so a bad checksum left the ESP32 state machine stuck with ACK low forever, and the Liron ROM polled forever. The logic analyzer showed WRDATA slamming and ACK flat until reset.
- Signal integrity. With no level shifters on the ESP32 link, the 1 MHz SPI lines ring and overshoot. Every Control command data packet failed its first checksum, and the system only worked because the Liron ROM retries five times. That is what the 22 pF caps were for.
Disk II emulation through FujiNet, which uses the ESP32 RMT peripheral for GCR track data, does not work. It is a different signal path and I have not started on it.
Next
Rev 2 with cleaner routing and connectors should remove the need for bodge caps. Open question: a real FujiNet board expects a Liron with 5 V TTL outputs, so it may need another set of level shifters, or it may just work at 3.3 V since the ESP32 is 3.3 V native. Extra shifting adds propagation delay, and SmartPort timing may notice.