Sibodump 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

`sibodump` - Moving from high-level block puller to low-level ASIC controller

Sat, 29 Jun 2019 00:00:00 0000

UPDATE: The latest version of SIBODUMP has just been released along with binaries for Windows and macOS. Take a look here: https://codeberg.org/thelastpsion/sibo-ssd-dump

SIBODUMP and its partner sketch Dump.ino have slowly developed into a very handy toolkit for SSD ripping. In its current form it’s able to dump blocks from any ASIC5-compatible SSD (so that’s all of them). I’ve also started to get it to pull images in native ASIC4 mode - all but the very earliest SSDs have ASIC4, and being able to talk using ASIC4’s registers could open the doors to even more development.

However, Dump.ino has some strange issues with ASIC4 for any address above 0x8000. In order to test this I’m having to pull full images every time. For all I know it’s the way that Dump.ino is pulling the data from ASIC4 that is causing the problem. I’ll be posting more about this issue in a future blog once I’ve worked out why it’s happening.

At the moment SIBODUMP isn’t clever enough to pick a specific address without artificially skipping a load of blocks to get to the right place. I want to be able to pick a specific address and dump a specific number of bytes, perhaps even sending ASIC4-style commands.

This means some pretty major rewriting will be needed over this weekend. I want to keep the current high-level commands so a human can talk to Dump.ino over a serial connection and get human-readable results. But I need some lower-level commands including setting the address, pulling a specific number of bytes (not just 256 every time) and reporting which address Dump.ino thinks it’s currently pointing to.

However, once this has been done, it opens the door to something new: using an Arduino as an SSD drive. One idea I’ve had is whether SIBOIMG could have a new switch that lets users specify a serial device rather than a regular image. That way, files could be ripped directly from the SSD without having to rip an image first.

There are decisions to be made about how much logic goes where. How much should Dump.ino know about FAT or Psion Flash filesystems? The answer is probably “as much as will fit onto an Arduino Uno”, but still giving access to the lower level commands.

Also, how can SSD communication be made to be as fast as possible? To be honest, the bottleneck at the moment isn’t the serial communications, but the speed at whcih Dump.ino can flip a bit on a digital pin. There are definitely improvements to be made there.

This post is more about letting you all know that I’m still alive, still working on the project, still hacking around with these fantastic little portables.

`sibodump` - The Psion SSD Image Dumper

Wed, 06 Mar 2019 00:00:00 0000

To go with siboimg, there’s now sibodump! This is a tool of two parts: first an Arduino sketch which talks to the SSD using SIBO-SP, and a C app that controls the sketch over serial and dumps the image to a file. The app runs on Win32 and Win64, Linux and macOS. It should run on *BSD, but I haven’t tested it yet. You’ll also find some binaries for Win32, Win64 and macOS in the repository.

Oh, I also built a makeshift Arduino shield with a Veroboard that I can easily plug the SSD into.

If you just want to get going without some sort of Heath Robinson soldering, you can just use jumper wires. With pin 1 on the SSD being closest to its edge, connect the SSD to your Arduino as follows:

SSD Pin 1 -> Arduino Pin 2
SSD Pin 2 -> Arduino GND
SSD Pin 5 -> Arduino 5V
SSD Pin 6 -> Arduino Pin 3

SSD pins 3 and 4 aren’t needed for this.

If you don’t want to use the companion app and want to see the raw data coming through, you can use the Arduino sketch by itself with an app like RealTerm on Windows. Connect RealTerm to your Arduino’s serial device, set RealTerm to 57600 baud, start the capture and send “d” to the Arduino. The dump will start immediately.

As with siboimg, this is ALPHA-QUALITY SOFTWARE. The Arduino sketch is reliable, although it doesn’t currently handle SSDs with more than one “device” (chip). So, for example, my 4MB Flash II SSD is made up of 4x 1MB flash chips, so sibodump will stop after the first 1MB.

The Arduino sketch was originally written by Karl with new features such as the command interpreter and block-by-block dumping added by me. The companion app was written by me with the addition of argparse.

Try it, break it, give me feedback!

Useful links

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