Ssd on The Last Psion

Psion SSD Drive, anyone?

Sun, 15 May 2022 00:00:00 0000

I wanted to put out an update about my various Psion projects. I’ve been away for a while, thanks to some mental health issues culminating in a career change. It’s only in the last week or so that I’ve felt able to look at projects like this again; projects I enjoy but for which I just didn’t have the mental energy.

I have started to work on something again, something I had kept quiet about because I didn’t want the outside pressure. But now I think that outside input might help, and I thought this would be the best place to post about it.

TL;DR: I’m designing a Psion SSD Drive, based on the RP2040, that will work over USB-C.

I had originally thought about using the ESP32 for this, and the early stages of this project were based on the ESP32. But I don’t need WiFi and I really want to play with the RP2040’s PIOs!

Near the end of last year I decided to take the code from sibodump and siboimg and squash them together on an ESP32. With the help of some friends at my local Hackspace, I picked some level shifters that do an excellent job of converting 3.3v to 5v and (with one chip) back again. I bought a small stock in case I blew one up (which I did), plus some breakout boards. I also bought a Raspberry Pi Pico, simply because it was cheap and I thought it might be fun. Then, with more help from the Hackspace lads, I worked out what circuitry I’d need to write to a Flash SSD. Finally, I tried to design a board, got too bogged down in the details, got annoyed with the project and put it in my Psion cabinet, where it sat for 6 months.

Last week I decided I’d take another look at the project. Long story short and almost on a whim, I decided to get the Pico out and try converting the code over. I then discovered TinyUSB, and in a moment decided that the RP2040 would be far more fun to play with than the ESP32.

To be fully compliant with the Psion SIBO HDK, I need 4 pins: DATA, CLK, DATA_DIR (to say which direction DATA is going), and CLK_OE (to disable CLK when it’s not in use). CLK_OE isn’t necessary for communication, but it makes the drive fully compliant with the HDK, so I’d like to try to implement it.

For USB communication, I’m planning on using TinyUSB in two ways. I’d like to make this a block device, but I’m not clear on how to do this well. But I would really like to implement a dummy ethernet device and run a web interface. This is going to give users a huge amount of flexibility, plus make the Drive as cross-platform as possible. I’ll probably keep some sort of serial comms available for debugging, too.

I want the Drive to be able to do regular read-write actions, but also rip and burn SSD images, show full details of the SSD hardware, and (if I can work out how) show the battery status of a RAM SSD.

I’m currently prototyping with a Raspberry Pi Pico and the Arduino libraries on PlatformIO. As time goes on I will probably try to use the Arduino libraries less and go straight for the RP2040 C/C++ SDK, but for now it’s made the code a lot easier to port to the Pico. Even switching from Arduino’s digitalWrite() to the SDK’s gpio_put() has given the code a huge speed boost; toggling CLK goes from about 350KHz to well over 20MHz, and that’s without using PIO. I’m also still not sure if PlatformIO is making my life easier or harder…

My next steps in no particular order are:

Move communication from software to PIO. There are four basic types of “frame”: Device Reset, Send Control Command, Send Data and Receive Data. Then I need to add DATA_DIR and CLK_OE.
Convert the Flash FS code from a series of functions to a class.
Work out how to write to a Flash SSD.
Work out how to read RAM SSDs (they use FAT) over SIBO-SP.
Add a simple web interface via TinyUSB.
Design a proper prototype board, rather than having everything on a breadboard.

I’d really love to hear your thoughts on this. I’ll be working on it at my own pace when time allows, so don’t expect it to be done in a month or even in a year. I haven’t created a GitHub repo yet, but I will once the code is at a suitable point. But I can see that I’m going to need some input from the outside world to make this work.

As an aside, rest assured that I will be revisiting the WiFi Pack at some point, but it’s not my priority right now.

Relevant links

sibodump: https://codeberg.org/thelastpsion/sibo-ssd-dump
siboimg: https://codeberg.org/thelastpsion/siboimg-c

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.

A long overdue update - ASIC replication and VHDL

Wed, 30 Oct 2019 00:00:00 0000

It’s been far too long since my last update on this project. It’s the usual excuse (“I’m sorry, but life just got in the way, blah blah blah.”) and to those of you who are taking an interest in my little WiFi Pack project, not to mention the rest of the efforts of the Last Psion project, I can only apologise. For now, here’s a brief update on what I’ve been up to.

My focus has shifted slightly, away from SIBODUMP and other C projects, over to the little chip pictured above. It’s Psion’s ASIC4, described by Psion themselves as “a serial protocol slave IC for addressing memory and general memory-mapped peripherals.” I’ve long thought that this wee beasty has been the key to getting the WiFi Pack working.

So, why pick ASIC4 instead of its older sister, ASIC5? Well, while ASIC5 is a very versatile chip (on-board UART, for example), it doesn’t offer as many options for peripherals. While ASIC5 can address 8MB of storage. ASIC4 can address up to 256MB split 50-50 between storage and peripherals.

ASIC4 is, of course, no longer being manufactured. Right now the only plentiful source of ASIC4s is the selection of SSDs that appear regularly on eBay. While this would certainly provide me with the silicon that I crave, it would also take SSDs off the market. It would also leave me with a large number of dead SSDs cluttering up my desk.

PCB of a ROM SSD (Autoroute) using ASIC4.

As with all similar retro projects, this has left me with a dilemma. Do I accept that I will be responsible for the massacre of countless retro storage modules? I think sacrificing a couple of copies of Autoroute for The Greater Good is acceptable, but it’s certainly not sustainable. What I really need is a way to make more ASIC4s.

Cue the wonderful world of FPGAs!

Also, cue headaches and defeatism while I try (and repeatedly fail) to learn VHDL.

And this is where I am right now, learning VHDL and digital design in general while trying to understand exactly how ASIC4 works. And I’m not going to lie, I’m not enjoying it as much as I wish I was. I like being creative, and right now it feels like there’s very little creativity in studying.

The creativity will come, of course. Once I have a working ASIC4 replica I will be able to modify it to my heart’s content. For example, how about adding an I2C interface? Or SPI? Or even a Z80 for some weird retro-on-retro gaming?

And yes, I know I could try to emulate ASIC4 in code rather than simulate (replicate?) it in hardware. The trouble is, I want to create something that fits into the SSD slot of a SIBO machine, something that’s ultra portable so that the user (i.e. me) doesn’t have to worry about forgetting to bring yet another device with him. A Raspberry Pi is just too big for this, and an ESP8266 is just too slow. ASIC2 and ASIC9 (the main ICs in the early and later SIBO machines) require immediate response from anything connected to them using SIBO-SP. If an ESP unit is busy doing other things, corruption will occur.

So, to you lovely hardware hacking people, I have a request. I would like to hear of projects where people have tried similar things, preferably by people who were, when they started, just as much of a newb when it comes to FPGAs as I am now.

Answers on a postcard, please.

Updates

Thu, 06 Dec 2018 00:00:00 0000

I can’t believe it’s been two months since I last posted here. Much has happened on this project and, although I don’t have time to write in detail about these things now, I wanted to give you a brief overview. Warning: Expect Exclamation Marks.

A Co-Conspirator Has Been Found!

Karl happened to be working on a Psion SSD project at the same time as me and asked me if I wanted to collaborate. I was apprehensive at first - us techies can be quite possessive of our projects at times - but it’s been working brilliantly. We’re approaching the SSD challenge from two different angles, which has actually helped in analysing the SIBO platform. So if I refer to “we” rather than “I”, you know I’m talking about Karl and me.

SIBO Serial Protocol Cracked!

I’ve finally managed to get a version of my SIBO-SP decoder released on GitHub. You’ll need a copy of PulseView and the sigrok libraries to use them. I’ll go into more detail about it in a later post, but I will say thank you to Karl for pointing out that the SIBO-SP data payload is sent LSB first instead of the usual MSB. This is implied in the HDK but not actually explained. Once I’d reversed the bits, suddenly things started to fall into place.

The decoder: https://github.com/thelastpsion/libsigrokdecode

Sample files: https://github.com/thelastpsion/sibo-sigrok-sessions

RAM SSDs Use FAT16!

This is so important, as it makes writing libraries and interfacing with an SD card so much easier. The ROM and Flash SSDs, however, use a different format that Karl is in the process of cracking.

New Software!

Karl and I have been talking about writing new software for the SIBO platform, especially RPG, platform and text adventure games. We’re putting together a Trello board of ideas. We welcome suggestions, but not too many - we’ve got plenty to keep us occupied right now!

I got a 3mx!

I found an upgrade. It was dirt cheap. You are allowed to be jealous.

This basically means I have been able to use my old “production” 3c as my main test device. I’ll still be using the 3a to check compatibility and also because it has the old-style SIBO serial port.

I got an MC-400!

Possibly the best laptop in the world, and yet is the most useless given that it’s practically impossible to get software for it. But I like the idea of trying to get modern software and SSDs running on it, maybe even running a newer version of EPOC16 on it. I’ll do a full teardown and review at some point in the future, but for now my focus is the Series 3 range.

There’s a lot more to cover, but all in good time. For now, just know that if you’ve got an old SIBO machine, chances are we’re going to be building something that’s very 21st century for you.

Further Logic Analysis, plus SSD Destruction

Sat, 10 Nov 2018 00:00:00 0000

It’s been a relatively fruitful month with this project. After struggling to work out why I was getting some weird signals being measured by my logic analyser (word to the wise: don’t forget to connect GND), I managed to get some relatively meaningful waveforms, meaning I could properly start to write a sigrok decoder.

Writing a decoder was a slight challenge as I had never touched Python before, but I was able to get something working in about 24 hours!

These screenshots were taken a couple of weeks ago. Since then, I’ve managed to add some more features to the decoder. I’m not going to lie, the code isn’t the prettiest, but it does work. I’ll be uploading it to GitHub once I’ve tidied up the code and added a few more features, along with some of the samples. Feel free to have a play!

The big issue I’m having with this part of the project, though, is not being able to tell which device is talking at any one time. This wouldn’t be a problem if the SIBO HDK had the full details of how a SIBO machine talks to an SSD, but unfortunately it only has details of the main SIBO Serial Protocol. While this is immensely helpful, I know that I’m missing a fair amount of information.

One suggestion was to add a resistor at the SSD end of the DATA line and use an oscilloscope to measure the slight voltage drop on anything transmitted by the SSD. Unfortunately I don’t (yet) own a scope and I don’t think my £4 logic analyser will read analogue signals.

Last week I came across a second way of detecting traffic direction in the SIBO HDK, something I’d missed in previous readings. Pin 59 on the ASIC4 is called SDIR, which goes high when it’s sending data. However, my SMD soldering skills aren’t brilliant and I think I managed to bork at least one SSD trying to do this. These SSDs will not have died in vain, though, as I will explain later.

Finally, there’s the man-in-the-middle option. I now own an Altera MAX II board that I think I could use to forward traffic both ways by detecting when the data line is pulled low at either side, then mirror the traffic on to separate pins. This question on StackOverflow gives an explanation of how this might be done based on some assumptions. However, as I’ve said before, my VHDL knowledge is non-existent. I’m going to be trying to read up on it as much as possible in the next week to see if I can at least bodge something based on the script in that link.

Even if none of the above work, there is a chance that I might be able to work out what’s going on. The ELKS Project was in part an attempt to get Linux running on SIBO machines. Deep in the code there is a very basic SSD driver written in 8086 assembly. This could help massively with writing the code for the eventual Last Psion module. Another option is to rip a copy of the ROM from a SIBO machine, find the driver and disassemble it.

All these options sound plausible, but they’re all just out of reach for me at the moment. I still have much to learn.

Now, the dead SSDs. I’m going to try to use them for parts and analysis. There aren’t currently any schematics of SSDs available, so I’m going to try to make a couple.

Also, I think the ASIC4 is probably still alive on at least one of them. I’ve ordered an SMD breakout PCB and some QuikChip, and I’m going to try to move the ASIC to the board. I’m hoping this is going to make it easier to play around with the ASIC, as long as I don’t destroy the chip in the process. I could even try to build an SSD using discrete parts…

Finally, one of the SSD enclosures has been “repurposed” as a breakout unit. I managed to connect the Vcc and Vdd around the wrong way on one SSD, which I’m pretty sure didn’t do it any favours. The breakout unit will hopefully make sure this doesn’t happen again, as well as make it easier for me to connect wires to the port’s pins.

Another thing I’ve discovered is that SIBO talks to Flash and RAM SSDs differently. Add to that the fact that some early SSDs use the ASIC5 rather than the ASIC4, plus that there are two types of Flash SSD, and you’ve actually got quite a variety of SSD types. I’m waiting for a couple of RAM SSDs to arrive in the post (I don’t currently own one), at which point I’ll tear them down and hope at least one has an ASIC4. After all, an ASIC4 RAM SSD is what I’m trying to emulate. It’s also worth knowing that the ASIC5 doesn’t have the SDIR pin that the ASIC4 has, so would make life a little more difficult.

I’m pretty sure that SIBO uses FAT16. I’m also pretty sure that the ASICs are acting as simple block devices. This would mean that all filesystem management is done in SIBO. This seems to be confirmed in the ELKS SSD driver code, which only talks about writing blocks to the ASIC4 rather than writing files or reading directory structures.

I’ve also finally ordered a 3mx. This should be arriving any day now and will probably become my “production” device. I will still be using the 3c as the target machine for this project. My plan is, of course, for this to work with any SIBO machine that can read an SSD. In that vein, I now own a Workabout MX with a half-working LCD - about half the horizontal lines are dead. Any suggestions on how to repair it, or places I can get a replacement screen, will be gratefully received.

Part of this month has also been spent getting in touch with a lot of people who used to be involved with the Psion world. I do plan on writing something about that in the future, but for now just know that it’s been really exciting to talk to these people who were so influential in the Psion world in the 90s.

Finally, I am putting out a scrounging request. If anyone has any old Psion equipment they would be happy to donate to the project, please get in touch. I don’t mind if it damaged or even dead, I will take it off your hands. Also, if anyone has any old Psion documentation then please let me know. I’ve managed to find the HDK and a lot of the SDK as PDFs on the Internet, but I know I’m missing a few documents.

Thanks for reading. I will try to write some more in the next week or so, as well as release the source code for the Sigrok decoder.

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.