Cartridge Support

Cartridge support

Friday 4 May

So it would be really nice to have a cartridge slot on the expansion box, as a convenient place to plug things into when your device is a 1088XEL and I've taken up the cartridge slot with the expansion bus... This does however have some issues.
The original design was to make all data-access local to the 6502 bus. That's why there's an SDRAM there - to provide plenty of buffering RAM for the peripherals to use. The basic idea for how a peripheral would communicate with the host machine is:

  • Let's say we have a MIDI card that receives and sends data and wants to communicate with the host computer when it does so.
  • On boot, the peripheral sets up an IRQ handler in its own section of the SDRAM, and any routines sending data. These will be mapped into a standard location when the IRQ is triggered or when the send-data routine is called
  • {midi data arrives}, the peripheral transmits the data over the link to the SDRAM, and then triggers an interrupt. The data is already in local SDRAM before the interrupt happens
  • {send-data}, the 6502 copies to a local buffer (in SDRAM over the bus) and then calls a TRAP routine (essentially a software interrupt, so set up a few "registers" in SDRAM memory, and tell XMOS to transfer data).
The important thing is that at no time is the 6502 talking directly to the peripheral. That's a "long path" for the data to go:

  • 6502 writes address/control lines
  • XMOS [local] picks up address after 177ns
  • XMOS [local] transmits address/control lines over the link
  • XMOS [remote] receives the {address,control} packet
  • XMOS [remote] pushes signals out to peripheral
  • peripheral gets data (say a read-request) and pushes data out to its data-bus
  • XMOS [remote] gets the data off the local data-bus
  • XMOS [remote] packages data up and sends it over the link
  • XMOS [local] gets package and pushes data onto the 6502's data bus
The timing budget is given by

Stacks Image 1537

... which leaves me with (558-177)ns of time to do all the above. If *everything* synchronises up just perfectly, I think it's just-about do-able, but it's going to be very very tight if it's even possible. So, what else could we do ?
Option 1: De-serialise
I could ditch the serialisation approach and just transfer data over a parallel bus. There are 41 distinct signals (including GND and +5V) on the ECI. The simplest approach might be a 2x21 ribbon cable, but these are pretty bulky at ~6cm for the connector assembly, so would take up a lot of real-estate on the back-panel of an H80 case. The next simplest way of doing it would be to double-data-rate the signal and use an HD26 cable and sockets; these would take up 4cm x 1.2cm on the back panel. We're still only talking a data-rate of ~3.6MHz for this, so there's no need for differential drivers or even twisted pairs. If it came to it, we could use SCSI-2 cabling, although the only reliable source of cables I can find are the 50-way ones, which have sockets larger than the HD26 above, at 52mm long, although with 50 wires, there's no need for data-doubling, which might be worth it.
A major benefit is that it would make the electronics a lot simpler, and it still provides a single cable to the expansion box, even if it's a lot less flexible
Option 2: Emulate
There's a lot of work been done to identify cartridge types and how any individual banking has been done on those cartridges. I could leverage that, and (on boot) copy all the contents of the cartridge up to local SDRAM (banking as necessary to get all the data), then the cartridge could be emulated by the local XMOS. In this way, we're more in line with the original design. 
This does have some drawbacks though - there's no way that hardware cartridges (eg: USB, SIDEx, etc.) could be made to work. The hope would be that such functionality would be taken care of by the box itself, but it's still a barrier that I'd rather not have.
Anyway, food for thought. Is fully supporting a remote cartridge port worth a re-design... I was opposed to the idea of simply extending the parallel bus to the expansion box originally because I didn't want to have a ribbon cable coming out the back, but having looked around, there's a VHDCI standard which would give 68 pins and it still has a round (if stiff) cable coming out the back. The price of 2 connectors and a 16" cable would be ~$37, which is about the price of my BOM for the interface card, in other words it's a wash.
On the positive side, 

  • I can pipe the audio line through, so the expansion box can source/sink audio as well. That wasn't going to be possible on the purely-digital approach. Not a huge win, but a win nonetheless.
  • I have 68 pins and I need 40 for the system-bus, so I can put the SIO signals on there as well. Then people can design either SIO or parallel-bus expansion cards. That's actually a pretty big win.
  • It means I can just have a single firmware change for the cross-platform aspect rather than two chips. Simplifying that is a major win, in my experience. Anything users might have to update is best made as easy as possible.
  • From a technical standpoint, there's no possibility of the two sides of the link being out of sync - it would have been possible for the interface board with the SDRAM on it to be plugged in and working, but not connected to the expansion box. The firmware on both would have to manage hot plugging (or at least graceful failure).
  • Different hardware configurations are easier to support - no need for a 4-layer PCB and software control, just route the wires from the edge-connector to the correct pins of the VHDCI connector, and you're done. The XL (with its PBI) and any non-atari boxes just got a lot easier.
  • It *is* a simpler system, I'm generally a fan of the KISS principle...

I'm snowed under with work right now (I have a demo to give on Tuesday) but I've ordered a VHDCI cable and connectors. I'll rig it up and see what the signal integrity is like across the bus, and we'll go from there.
I'm envisioning 2 internal PCB's, in the configuration {card-edge interface}<---ribbon-cable--->{VHDCI interface} which ought to allow it to be placed anywhere on the back-panel of either a stock XE/XL or in the mini-itx case of your choice.
The first PCB would have the XE card-edge interface, line buffers/transceiver, and connections for ribbon cables of the following:

  • 2x34-way to the VHDCI connector PCB
  • 2x5-way for each joystick port [7 pins used] because why not {1088XEL-specific}
  • 1x7-way for the SIO interface [5 pins used] {1088XEL-specific}

There are 41 pins used for the system bus, so I have 8 currently 'spare'. I won't be running power across the link, but I can always use them as multiple grounds if there's no better use for them. I'll have to look at the C64 bus to see if there's any special requirements there as well.
The second PCB  would be the ribbon-cable-to-VHDCI connector. The VHDCI connector is a straddle-type, and I *think* the connector above would be panel-mountable such that it can be screwed to the back of the panel with some M2 hex standoffs, and then the VHDCI cable screw into the standoff.
Both of these PCB's can be 2-layer and they're simple designs with a short ribbon cable to connect them. Then there's the VHDCI cable to the expansion box, another VHDCI connector, and you're on the expansion box itself.