Ever since the start of this project, the SIBO Serial Protocol (SIBO-SP) has loomed large as Something We Need To Know About. It's a protocol using 12-bit packets, a LSB-first data payload, and a series of reset and select control commands, all done on one data wire and one clock wire. As you'll see in previous logs, we've managed to decode a large amount of it and I've published my Sigrok decoder on my GitHub page.

The next step with the development of the decoder (and therefore the research into SIBO-SP) is the Slave Select Select Control Packet (SSel). Basically, how does a SIBO/EPOC16 machine know what it's talking to?

"Select" is kind of a misnomer, because in actual fact it's a question. The SIBO/EPOC16 device has a list of device IDs it knows how to speak to. Although these device IDs refer to specific ASICs and their modes, it's also possible to think of an ID as an ASIC's "language", For example, ASIC4 can "pretend" to be ASIC5 in Pack Mode. More on this later.

This SSel packet contains an ID number. This ID number refers to one of a number of different ASIC chips that could be in a slave device. Here's a list of the device IDs we've found so far and the devices they refer to.

Each SIBO/EPOC16 device has a list of IDs it can speak to. When a SIBO-SP port is initialised, the SIBO machine first sends a "Reset All" command. This tells all slaves to stop what they're doing and listen for a SSel packet. Then, the SIBO/EPOC16 device goes through its list of IDs, starting from the top. It asks the slave, "Do you speak ID:x?". If there's no reply, it goes to the next ID on the list until it gets a reply or runs out of IDs.

The list of IDs is different for SIBO Serial Ports and SSD ports. This makes sense - the types of device that could be connected to a SIBO Serial Port are different to what would be put in an SSD port. However, the different types of SSel IDs that each device sends  are interesting.

This is a list of SIBO devices with the IDs they send out on each port. Anything marked "unknown" is because I haven't been able to test it yet (I don't own an MC200 or Workabout 1MB and I don't have the right connectors for the MC or Workabout ranges).

¹ Wmx also sends ID:56 at boot on the SSD port whether the door is open or closed.

What's interesting is that for every SSD port I could test, it asks for at least one ASIC that can handle some sort of peripheral, all the way back to the MC400, possibly even further. Although I don't know this for certain, I assume an ASIC2 in Slave Mode was a precursor to the ASIC4 in Extended Mixed Mode.

However, I've come away from this research with even more questions. What were ASIC6 and ASIC8? What are these extra IDs that the Workabout mx asks for? Were there ever any SSD-sized peripherals that used ASIC2 in Slave Mode? Can these device lists be changed in software, or are they hard-coded on each ASIC?

But the most important one of all... Why didn't Psion make more of a thing about being able to build SSD-sized peripherals? The only clues to this being possible are in the SDK's Hardware Reference where a single paragraph refers to SSD ports being able to use interrupts in the newer ASIC9-based devices. It's such a shame that this never happened.

Well, not until now.