Sibo-Sp on The Last Psion

The Siena SSD Drive

Sun, 17 Nov 2019 00:00:00 0000

It’s been an interesting morning. I’ve been digging around in the internals of the Siena SSD drive and made some discoveries.

The Siena SSD drive was released so that the diminutive Siena could still read SSDs. I bought one of these on eBay a week ago because I wanted to answer a question: “How did Psion get the SIBO Serial Protocol to work over RS-232?”

At first I thought there were two ways that Psion could have done this. First, the SIBO-SP packets (12 bits in length, although only 9 are ~~useful~~ significant) are repackaged so they fit into 8 bits. Or second, the Siena SSD drive tells the SIBO machine that it’s SIBO-SP compatible and then changes from RS-232 using to SIBO-SP (maybe still using RS-232 signal levels that are downconverted for ASIC4/5?).

Turns out there was a third way.

The only documentation I have for the Honda connector is from a Series 5 service manual. In it, pins 10,13 and 14 are shown as not connected. Turns out that’s not the case with the Honda SIBO machines (3c, 3mx and Siena). On the 3c board (pictured with the stripped-down drive) they connect to a MAX3212, an RS-232 transceiver.

This means that the Honda serial cable has a second set of serial connections, separate to the main RS-232 used for things like PsiWin.

The Siena drive has a passthrough RS-232 port with pins 9 to 14 disconnected. Having a second serial channel would explain how a Honda SIBO machine can do both regular RS-232 and read an SSD at the same time.

The white square in the top-middle of the Siena drive’s board seems to be another custom ASIC! All the SSD pins connect to this. I’ve not seen any information about this chip anywhere. My guess is that it splits the single-wire SIBO-SP into two wires for transmission along the second serial link, but until I can get a logic analyser on it I can’t say that for certain. The rest of the board must be providing things like Vpp for writing to Flash SSDs and lowering the 9v power supply to 5v.

This does sadly mean that, even with drivers, there is no way to get the drive to work on an EPOC32 machine, but it does potentially mean more exciting things for SIBO machines with Honda connectors, as it does look like there’s a way to talk SIBO-SP over the Honda connector.

UPDATE: 2026-04-15

Last year a few of us in the Psion Community came across an update to the SIBO C SDK that we didn’t have before.

At a conference in the late 90s, Psion handed out Word documents for developers to update version 2.10 of the SDK to 2.15. The latest version that I have of the Hardware Guide is 2.10. This includes a table that I have reproduced here with added information on ARM/EPOC32 machines:

Pin	Function	Direction
1	Siena: Vin at +6V DC ±10%	`<--`
	Series 3c/mx: 5V power out, 30mA maximum	`-->`
	ARM: 5V power out (max current unknown)	`-->`
2	`RTS` (RS232)	`-->`
3	`DTR` (RS232)	`-->`
4	`TXD` (RS232)	`-->`
5	`DSR` (RS232)	`<--`
6	`DCD` (RS232)	`<--`
7	`CTS` (RS232)	`<--`
8	`RXD` (RS232)	`<--`
9	SIBO: `SDOE` - data direction control	`-->`
	ARM: Vpcc	`-->`
10	SIBO: `EXTSTAT` - active low peripheral detect line	`<--`
	ARM: N/C	N/C
11	SIBO: `EXON` - external turn-on	`<--`
	ARM: Vpp	`-->`
12	SIBO: `INT` - peripheral interrupt	`<--`
	ARM: N/C	N/C
13	SIBO: `SD` - serial data	`<->`
	ARM: N/C	N/C
14	SIBO: `SCK` - data clock	`-->`
	ARM: N/C	N/C
15	`GND` - Signal and power ground	`---`
16	`GND` - Shield frame ground	`---`

Key:

--> Out of machine
<-- Into machine
<-> Bidirectional
--- Ground

Notable differences here between SIBO and ARM machines are pins 9 and 11. As no one has yet blown up a Siena drive by plugging it in to a Series 5, I assume this wouldn’t cause a problem with other peripherals.

Also, the last time I tried to attach an oscilloscope to a Siena SSD Drive, I slipped and blew up a regulator - one that’s no longer manufactured. Luckily I have two other drives, but these things are rare. I’ll be much more careful in the future.

The SSD Port and (finally) Some Logic Analysis

Sun, 21 Oct 2018 00:00:00 0000

I now have everything I need to get started on revealing the secrets of the Psion SSD Port. So, here’s what I’ve been up to this morning.

Rather than pull apart my “production” 3c, I’ve decided to get to work on a slightly broken 3a. I don’t like the idea of doing something dumb thanks to my inexperience and blowing up my 3c. The 3a’s battery compartment is in a pretty bad way, but it powers on quite happily with a Series 3 external PSU. So, I pulled it apart and got to work.

For some reason, this 3a smells really strongly of some spice or other, possibly cumin. It’s not pleasant and the unit could really do with a bath in alcohol.

I removed the door for Port A and directly attached six jumper leads to the six pins of Port A. The other ends of the leads were plugged into a solderless breadboard. I then ran a further six jumper leads from the breadboard to my SSD. Keeping my fingers crossed that I hadn’t miswired anything (it’s currently my only SSD) I powered up the 3a and… it still worked!

My next step was to find out what each pin did. I had already found the SSD pinout using this post from comp.sys.psion.misc, so I used that as basis and used my multimeter to test the voltages on pins 3 to 5. So, here’s the updated pinout, using the post on comp.sys.psion.misc as a basis.

Pin	Name	When the 3a is on	When the 3a is off
1	CLK (input to SSD only)	Clock (+5V)	0V
2	GND	GND	GND
3	Vbackup	+3.75V DC	+3.75V DC
4	Vpp (for Flash programming)	+15.75V DC	+9V DC
5	Vcc	+5V DC	0V
6	DATA (bidirectional)	Data (+5V)	0V

Interestingly, the Vpp voltage drop isn’t instantaneous, taking just under 10 seconds to drop from 15V to 9V.

So, I have a few questions:

~~What’s the point of Vbackup?~~
~~Why does Vbackup stay live when the unit is turned on?~~
Why does Vpp drop to 9V when the unit is off? Why doesn’t it go off completely?
Is there a reason Vpp takes time to drop, or is it just a capacitor taking time to discharge?

UPDATE: I now realise that Vbackup is there to maintain power to RAM SSDs so they don’t have to rely on their own internal CR1620 batteries when inside the Psion. This answers questions 1 and 2 - that power is needed even if the Psion is turned off. My guess is that RAM SSDs have Vpp disconnected, Flash SSDs have Vbackup disconnected, and ROM SSDs have both disconnected. It is also worth noting that Vbackup and Vpp are live even if there is no SSD connected and the Psion is off, albeit with Vpp running at 9V. This might prove useful in the future.

I felt it was now time to connect up my USB logic analyser and see if I could use PulseView to see the SIBO Serial Protocol at work. (The other device on the breadboard is an Espruino Pico, which I was using to generate signals to make sure the logic analyser was working.)

After trying various settings and finally setting the sample rate to 24 MHz, I managed to capture a conversation between the Series 3a and SSD.

The top line is DATA and the bottom is CLK.

PulseView and its backend library sigrok have the ability to do some analysis on the signals they capture. There are plugins for all sorts of protocols, such as I2C, AC ‘97, SPI. This made me wonder how difficult it would be to write my own plugin for the SIBO Serial Protocol. After a quick look on Google, I found this:

https://sigrok.org/wiki/Protocol_decoder_HOWTO

So I think my next step is to see if I can write a protocol decoder for SIBO using the HDK document as a basis. It will help me to understand the protocol better for when I finally get around to building the first SSD prototype.

SSDs, the ASIC4 and the SIBO Serial Protocol

Mon, 17 Sep 2018 00:00:00 0000

Psion were a clever bunch, but like many companies in the early 90s they didn’t really do standards. Although the 3c and 3mx had a proper RS-232 serial port (albeit using a very odd connector), all of the earlier models used a proprietary protocol called the SIBO Serial Protocol. All Series 3 models used SSDs that also communicated using this proprietary protocol.

A significant part of developing this equipment involves working out how to emulate an SSD or Psion peripheral. Luckily, while trawling the Internet for Psion PDFs I found the Psion SIBO Hardware Development Kit. This book gives a breakdown of how to create equipment for the Psion Series 3 and 3a, including the controller chips needed, the Psion serial protocol, and how to write drivers for the Series 3 and 3a.

The controller chips are known as ASIC s, or Application Specific Integrated Circuit chips. As far as I can tell, Psion SSDs mainly use the ASIC4, which converts the SIBO Serial Protocol into addresses within the memory range of the SSD’s on-board memory.

The original ASIC4 has two modes. The first is SSD Mode. This makes the ASIC4 compatible with its predecessor the ASIC5. In this storage-only mode, the ASIC4 can use 21 address bits for memory. As far as I know, this is the way the ASIC4 is configured in every SSD.

The second mode that the ASIC4 can use is called the Extended Mode. This increases the addressable range of memory from 21 bits to 28 bits. Also, the ASIC4 Extended Mode also has a sub-mode called Mixed Mode, which tells the Psion that it’s talking to a device that consists of both storage and peripherals. Mixed Mode causes the addressable memory to be split exactly in half, with the lower half used for memory-mapped peripherals and the upper for storage. According to the HDK, this storage is typically used as a ROM including software and drivers to control the peripheral. However, it seems that it can also be used as RAM storage or Flash storage.

As you probably already know, the two aims of this project are to give the Psion both better storage and Wi-Fi access. I’m going to ignore the Wi-Fi challenge for the moment and focus on emulating an SSD, specifically an ASIC4 in Extended Mode. Being able to do that will be an achievement in itself, because it means my 3c will have some modern non-volatile storage.

My first challenge is to deal with the SIBO Serial Protocol. To briefly summarise, this uses a 5v half-duplex two-wire system - CLK and DATA. The 3c controls the clock and sends out 12-bit packets (0-11). Bit 0 and Bit 11 are start and end bits. Sometimes Bits 1 and 2 tell the slave device that it’s the slave’s turn to send data back on Bits 3-10.

Oh, and the 3c’s CLK runs at a nominal 3.84 MHz. Not fast, but not slow either.

What I really want to do is emulate an ASIC4. As far as I see it, I don’t need to totally recreate the ASIC4. All I want to do is make my 3c think that it’s talking to an ASIC4 in Extended Mode.

I can see three ways of tackling this:

Completely emulate the ASIC4 on Espruino. This is what I really want to do. But would the Espruino platform be fast enough to cope with the 3.84 MHz clock? I’m guessing pure JavaScript would be nowhere near fast enough to handle it, so a driver would need to be written in C.
Use an original ASIC4 chip. They’re not too difficult to get hold of (SSDs pop up all the time on eBay), but there is a finite supply. Also, I would need to remove the chip from an SSD, and I’m not quite at that level of soldering skill yet. Finally, I would need to work out how to get Espruino to talk to an ASIC4.
Emulate the ASIC4 in FPGA. This scares me the most. I haven’t got a clue about FPGAs. However, I know it would be insanely fast and mean that I wouldn’t have to break SSDs. Still, I’d need to work out how to get Espruino to talk to the FPGA.

If I do try to emulate an ASIC4, I don’t have to emulate the entire chip and all its pins. I just need to make the Psion think it’s talking to an ASIC4. What I don’t know, though, is if an ASIC4 can be connected to an SSD port in Mixed Mode and have the Psion recognise it. Or, to be more accurate, if I can make something that pretends to be an ASIC4 in Mixed Mode and have the Psion recognise it.

Once I have this first major stage working, I will look at emulating Extended Mixed Mode so that I can send commands to the Espruino to control the Wi-Fi.