Hey all,
I've been designing an open-source NuBus FPGA accelerator card targeting the Quadra 700 (and other 68040 NuBus machines). The idea is to give the 68040 hardware acceleration for things it was never designed to do — TLS 1.3 cryptography, hardware blitting, basic video decode, DSP, and general-purpose compute — without replacing anything about Classic Mac OS.
I have a KiCad schematic, a design document, and a BOM ready for review. Looking for feedback before I move toward PCB layout.
GitHub repo: https://github.com/sailcat/phoenix-nubus
What's on the card
- FPGA: Lattice ECP5 LFE5U-85F (BGA-381) — chose this specifically for the open-source toolchain (Yosys + nextpnr + Project Trellis). 84k LUTs, which gives room for all target cores simultaneously with about 25% headroom.
- SRAM: 2x IS61WV51216EBLL — 1MB each, 10ns async. One dedicated to crypto/watchdog buffers, one to blitter/DSP scratch.
- SDRAM: IS42S16320F — 64MB, 166MHz capable. Frame buffer, video decode reference frames, bulk storage.
- Flash: W25Q128JVSIQ — 16MB SPI. Stores multiple bitstream images (switchable via DIP).
- Level shifters: 3x SN74LVC16T245 — bidirectional 5V/3.3V translation for the full NuBus bus (AD[31:0] + control signals).
- Power: 3x TLV62568 buck converters with TPS3700 supervisor for sequenced power-up (1.1V core → 2.5V aux → 3.3V I/O, per ECP5 requirements).
- Clock: 50MHz MEMS oscillator. FPGA PLLs derive everything else internally. 10MHz NuBus clock comes in through a level shifter.
Target accelerator cores
| Core | Est. LUTs | What it does |
|---|---|---|
| Crypto Engine | ~12k | AES-256, ChaCha20, SHA-256, Curve25519 — enough for TLS 1.3 |
| Graphics Blitter | ~8k | Hardware blit, scale, rotate, alpha blend |
| Video Decode | ~15k | Motion compensation, color space conversion, targeting 15-20fps @ 320x240 |
| DSP | ~10k | 8-channel mixer, sample rate conversion, wavetable synthesis |
| Compute Unit | ~8k | Vector MAC, matrix multiply |
| Watchdog | ~2k | Bus monitor + DMA for memory protection via 68040 MMU |
Total is ~63k LUTs out of 84k available.
How it talks to the Mac
The card sits in a standard NuBus slot and maps its registers into the assigned 256MB address window. A system extension (INIT) detects the card via Slot Manager, installs the interrupt handler, and exposes a shared library (PhoenixLib) with C-callable APIs for each accelerator core. Software talks to the card through memory-mapped register writes — nothing exotic.The card also supports DMA bus mastering for bulk transfers (frame buffer writes, watchdog shadow copies) and generates interrupts via /NMRQ for completion notifications.
The companion bridge concept
The card handles acceleration. A Raspberry Pi on the local network handles the internet-facing stuff — TLS termination, HTTP content simplification (strip tracking/JS/autoplay), protocol translation, media transcoding. The Pi prepares data, ships it to the card over Ethernet, and the card's crypto/video/DSP engines do the heavy lifting. The Mac never touches the raw modern internet directly.Current state
The schematic is architecturally complete — all components selected, all inter-sheet connections defined, design constraints documented. The full pin-level wiring (especially the BGA-381 fanout) needs to be finished in KiCad before layout. The design document in the repo covers component rationale, NuBus register map, PCB stackup notes, FPGA fabric allocation, and a preliminary C API.No HDL written yet. No PCB layout started.
What I need from you
Specific questions:
- Quadra 700 NuBus cage clearance — Does anyone have physical measurements of the vertical clearance above a NuBus card in the Q700? I need to confirm component height constraints. The board is designed as a short Eurocard (100mm height) but I need to know if tall components on the top side are going to be a problem.
- NuBus Declaration ROM — Has anyone here written an sResource directory from scratch? I've read Designing Cards and Drivers for the Macintosh Family but practical experience with the format would be incredibly helpful. If anyone has disassembled the ROM from an existing NuBus card and has notes, I'd love to see them.
- ECP5 vs Artix-7 — I went with the ECP5 for open-toolchain reasons, but the Artix-7 (XC7A100T) has more fabric and better DSP blocks. Anyone have strong opinions here? The ECP5 is well-proven in the open-source FPGA community (ULX3S, etc.) but I'm open to arguments.
- Level shifting approach — Is three 74LVC16T245s the right call for the NuBus interface, or is there a better approach people have used? The bidirectional direction control adds a bit of complexity since the AD bus is multiplexed. Particularly interested in how to handle /NMRQ (open-drain on NuBus).
- PCB layout help — I'm looking for someone experienced with BGA fanout on 4-layer boards. The ECP5 BGA-381 at 0.8mm pitch is the hard part. This would be a paid gig, not asking for free labor. If anyone does this kind of work or can recommend someone, please reach out.
- NuBus connector sourcing — Where are people getting DIN 41612 Type C connectors for new card designs these days? Any preferred suppliers?
Everything is on GitHub, open source (leaning CERN-OHL-S for hardware, MIT for software). Happy to answer questions about any part of the design.
Edited to Add:
I want to call out @Melkhior's NuBusFPGA project — which I discovered via the similar threads prompt right after posting this. That project has already solved several of the problems I'm facing, particularly the Declaration ROM development workflow (QEMU digital twin approach), NuBus bus interface design, and the LiteX/Wishbone bus fabric for connecting multiple devices inside the FPGA. Phoenix is targeting a different use case (accelerator cores rather than video output), but the NuBus interface engineering and driver architecture are directly relevant, and I expect to learn a lot from that codebase. If you're interested in NuBus FPGA work generally, that thread is essential reading.
Last edited:
