Don't worry, there's no chance I'm stopping the project - I'm invested too much at this point and I like to see things through to completion once I've started them.
I've been tweaking the schematic a little, and if I drop the aux serial port, I can come up with a compromise design. I branched off the 'xio' schematic to 'xio2', which still has the USB-c interface, but also has space for a PATA serial cable connection - kind of like a mini VHDCI since it only has 40 pins. You can get "round" cables for not very much money (even cheaper on eBay), and the connector is a simple 2x20-way 0.1" rectangular header, so also very cheap.
The schematic doubles up, so if we're using it in parallel mode, with a parallel bitstream loading into the FPGA, then everything flows to/from the parallel port to the FPGA, STM32, and slots. If we're using it as a USB-c interface the FPGA regenerates all the parallel bus signals from the serialized data-stream, and the parallel bus becomes a transport between the STM32 and the FPGA.
This means I can get it up and running in the simple mode (low speed parallel communication, test stuff out, and then move to the USB-c mode once the basic stuff is working without re-spinning the board. If it turns out that this is beyond me, then it's just a 'no-stuff' option in the build process, and no harm, no foul. If people *really* wanted that extra serial port, well, there are slots.
In this scheme, the FPGA acts as the bus-controller and arbiter, so I can react instantly to bus changes, and it requests data from the STM if needed, parsing the bus traffic so the STM doesn't have to and handling the generation of /EXTSEL and /MPD without software intervention. This makes the software side a lot easier. The FPGA will also generate /CCTL, /S4 and /S5 from the address bus, so we don't have to transfer them across the PATA bus from the host, meaning we only need 32 signal wires, which fits nicely into a 40-wire cable, assuming we also common the GND, with seven wires to spare. I ought to be able to squeeze SIO (5) and audio (2) in there too if it's coming from an 1088XEL, making this (almost) functionally identical to what we had with the VHDCI.
From the cartridge perspective in the parallel interface case, it's actually on the bus, modulo bus drivers, just like it would have been in a normal Atari, so that's straightforward as well.
So it's not *quite* as nice as that - in the parallel case, I need 5 wires for the direction control of the bus-driver chips that sit on the board that plugs into the host. There's a couple of options:
- Say sayonara to the SIO wires, and just use the available wires for control
- Add some programmable logic at the host end (currently it's a dumb interface) and encode what we want to send using a protocol over the available lines, then let the programmable logic do its thing to actually control the wires. We can fit that into 2 lines, leaving the 5 left over for SIO.
What I'll probably do, when I get to laying out the host board, is a combination of the two - so I can initially get stuff up and running using the simpler first approach, and if that works, I'll be able to switch over to getting the more complex option working, which will give us SIO plug-ins in the slots.