The device interface

The devices are insulated from the workings of the 8-bit via a command/response packet protocol that is controlled by another XMOS chip. The XMOS chip relays packets from the host-interface over to the correct card, and collects responses and sends them back to the host interface. Conversely, it also allows a device to asynchronously send a packet either to the host or to another card in the system.

As part of the boot-up procedure, the device interface collects capability and identification information from all connected cards. These handles can then be queried for and used as identification by cards on the bus. The id 'cpu0' is always the 8-bit host computer.

Signal lines are as follows:

  • A dedicated 'tx' line per port, pulled low when the card wants to talk to the bus
  • A dedicated 'sea' line per port, pulled low when the device interface XMOS grants bus access
  • An 8-bit bi-directional databus driven either by the device interface XMOS chip, or by the card that currently has access
  • A 1-bit bi-directional clock, driven in the same way
  • A 3-bit identifier, where each line is pulled to +3.3v or GND depending on physical position
  • A dedicated 1-bit card-present bit that the card has to pull down to GND

When boot-up starts, the XMOS chip knows which slots are occupied via the card-present bits, and sends packets to each device asking for identification and device-driver code. To start with, the bus runs at 1 MHz, but one of the identification bytes specifies the bus speed that can be maintained (up to a maximum of 60 MHz). Once that speed is known, the bus keeps using that speed from then on.

The XMOS chip has up to 8 concurrent tiles that can each run a program with guaranteed latencies and timing. This ought to be plenty to handle the enclosure-bus protocol and the relaying over the Xlink back to the host-interface XMOS chip.

Examples of transactions, where PBIO is the host interface XMOS chip and PBX is the device interface XMOS chip:

Transaction sourced by the 8-bit host:

  • PBIO decodes $Dxxx
  • PBIO sends a message to a device within the PBX
  • PBX takes the appropriate select line active-low
  • PBX uses the 'clk' and bus lines to send the packet to the specific card
  • The clk and data-bus are reversed after the packet has been sent, such that the device can now control them
  • The device uses clk and data-bus to send a reply packet
  • PBX sends the response to PBIO
  • PBX lowers the device-select line

Or a transaction sourced from the device to the 8-bit host:

  • device sends 'tx' active-low
  • PBX sends device-select line active-low
  • PBX sends 'transmit-ok' packet
  • The clk and data-bus are reversed after the packet has been sent, such that the device can now control them
  • The device uses clk and data-bus to send a data packet
  • PBX relays the packet to PBIO
  • PBX sends 'data-uploaded to PBIO' packet
  • device responds with 'ack' or 'ackIrq' packet
  • device sends 'tx' high (ie: inactive)
  • PBX sends 'device-select' line high (ie: inactive)
  • If device responded with an ackIrq message, PBX signals PBIO to raise an IRQ with the 8-bit host


The PCB in the enclosure is responsible for providing power at 3.3v (with a budget of 500mA per slot for a total of 4A) to the individual cards. The PSU will be something like the Meanwell EPS-65S-3.3 and will be contained within the enclosure. An alternative would be to get an external PSU brick (laptop-style) and connect it using a barrel connector.

This latter approach would have the advantage of not being open-frame, and not having to deal with mains electricity in the enclosure, all the high-potential wiring would be self-contained. If I go down this route, I'll have to have 5v->3.3v converters on the rails exposed to the cards and XMOS, but these wouldn't have to cope with individual high current due to the current restrictions per card.

Motherboard integration

The PCB will also provide some integration with the 1088XEL pinouts. It will provide:

  • A power-switch interface so the entire enclosure can be switched on/off
  • A power source, so the 1088XEL can be powered from the same switch
  • A header for the front-panel USB-3.1 ports, which can each carry 9 signals including ground. An adaptor board which takes USB-3.1 on one side and exposes Atari joystick interfaces on the other could both extend the joystick range and make them easily accessible
  • Another header which could route the internal audio through the front-panel 3.5mm jack.
  • An LED for HDD operation - either linked to an existing header on the motherboard, or controllable via a register-based interface for other purposes.