Me: I could do with a quick win to get me going again.

Also me: I shall learn a proprietary object oriented dialect of C, where the only way to learn it is to plough through 1150 pages of documentation.

Psion doesn't have a formal name for the object oriented version of C that it created for EPOC16. I've been calling it "Psion OO C", but the main library that it uses is called OLIB, which contains the root class. The others are:

• HWIM: The OO graphics library
• FORM: On-screen formatting 
• XADD: Additional graphics library for 3a onwards (but not the Series 3 "classic")

To Psion's credit, their OO ecosystem is well documented in the SIBO C SDK across 5 books (hence the 1150 pages mentioned above). Each of the libraries has its own, dedicated book. There's also an "Object Oriented Programming Guide" which acts as an introduction to the whole ecosystem. I don't have the latest versions of all of these books - they seem to be lost to time. But I have all the 3 and 3a features documented, plus (I think) all of the 3c/Siena extensions. (3mx-era EPOC16 remains sadly undocumented.)

What's nice about Psion's approach to OO is that they assume no prior experience with object oriented programming. They just assume that you know roughly what OO is, and that you can write some C code.

What follows is a collection of a few posts I made on Mastodon, plus some things I posted on the Psion Discord, fleshed out and turned into a proper blog post.

NOTE: If I have any of this wrong and you know better, please get in touch! As the title of the post suggests, I definitely do not know everything. I want the correct knowledge to be out there, and I don't mind if my ego takes a bruising in the process.

First Thoughts... "Ew"

This was my early, uneducated summary/hot take.

Instead of working with JPI/Clarion to add a "proper" OO C module to TopSpeed, they wrote a preprocessor. But it only does preprocessing on the class *definitions*. Methods are just functions that have to take a pointer to the class definition.

It feels bolted on to the side, not a cohesive whole.

To be honest, Psion not wanting to write a plugin for the TopSpeed compiler is understandable. As far as I've been able to find out, plugins for TSC are written in Modula2, much like the compiler itself. This was not the most popular language and it could be that it was just easier for Psion to write a few preprocessors in C and be done with it.

Even so, at this early stage, I wish Psion had gone a bit further.

The "language"

In spite of my discomfort with the tooling, Psion OO ecosystem is a fully object oriented, event driven "language." It's not so much a superset of C, but a separate class-definition language with some extra C functions to handle methods. In the Object Oriented Programming Guide, they say:

Psion's Object Oriented Programming system is similar to Object Pascal.

I don't know why, but this made me chuckle.

The manuals never mention Smalltalk, but Psion's OO uses message passing talk to methods instead of invoking them. If you've noticed Smalltalk and C together and thought of a different language... I'll come to that later.

Psion's Classes

Classes are defined in category (.CAT) files with its own proprietary syntax. It's a similar format to Psion's own resource file syntax, but that's unhelpful if you're new to programming for EPOC16.

Methods are stored in a separate .C file. The .CAT file is passed through a preprocessor called CTRAN.EXE that generates headers (.G), C files and object files. You then create a C file that holds your methods and #include the relevant .G file.

(I need to investigate the preprocessor situation more to clarify, as I think there might be more CLI apps involved. There might also be an intermediary object file generated that needs translating.)

Note that the preprocessor only processes the .CAT files. It doesn't touch your methods.

Of course, proprietary syntax is a pain in the modern world. It means no syntax highlighting, no language server, etc.

EDIT: I've just been told this by a former Psion engineer:

The language was based on the language Eiffel as defined by Bertrand Meyer in his book "Object-oriented Software Construction" (1st edition).

I've heard of Eiffel before but never looked at it. It's now on my research list.

Inheritance is everywhere. If you use HWIM to create a new app, you have to create a new object that inherits the window server WSERV class and then replace its init method with what you want it to do. Same with any other on-screen widget.

There is one annoying thing. There are no private methods or properties. From the Object Oriented Programming Guide:

"... the idea of private and protected data and functions does not exist."

"Although not enforced ... property should be considered as private to a particular class ..."

So if you implement getters and setters, they're just for show.

I guess this is because CTRAN only processes the .CAT (class definition) files, not the main C code. Without processing the main code, there's no way to check for and prevent private things from being accessed from outside of a class. TSC doesn't know you want your method to be private, because it doesn't know what a private method even is.

Methods are named classname_methodname, because they're all defined in regular C. You need to use this naming convention so that it matches the files generated by CTRAN.

Calling Conventions

This isn't specific to Psion's OO C, but it makes use of it more than regular Psion programming with plain old PLIB.

Looking through some Psion C code, I've seen CDECL a few times. Being a noob, I didn't know what they were or why they were there. So, looking at Wikipedia...

https://en.wikipedia.org/wiki/X86_calling_conventions

CDECL is a "caller clean-up" calling convention using the stack. This is pretty common in the x86 world, but is explicitly used in Psion code. Why?

TopSpeed C uses its own "callee clean-up" calling convention, using registers for the first 4 int parameters. The SDK regularly mentions that this method is much faster, and might also fit better with the way that EPOC16 manages memory. Sticking with the "pure" small memory model (preserving the CX register) means that 64K code and data blocks can be moved around memory without interfering with the program running "within."

However, there are other calling conventions that Psion uses, straight from an example in the Object Oriented Programming Guide.

Now, p_enter() is a PLIB call that (I think) allows for returning of error codes separately to whatever is returned by a regular function.

ENTER_CALL is defined in p_std.h as:

Whereas METHOD_CALL is defined in p_object.h as:

So the only difference is that missing mention of the cx register.

I don't know enough about any of this yet to say what's going on here. I'm sure more experienced C programmers will have a better understanding.

"This reminds me of Objective-C..."

Yeah, it's a bit like that, isn't it? Smalltalk plus C normally only means one thing.

A few years back, someone who used to work with me on this project actually suggested to me that whole of Psion's OO C should be reimplemented in Objective-C. At the time, I was pretty skeptical/cynical, as I felt that a direct recreation of TSC and Psion's tooling would be more sensible. With a little more knowledge behind me and having taken a dive into this legacy ecosystem, I'm more open to replacing it all.

This is some sample code that he sent to me. The first is some Psion OO code. The second is a direct transliteration to a theoretical Psion Objective-C. The third is a refactoring of the ObjC code.

As you can see, it's a pretty straightforward translation in this example. I'm not sure how well the .CAT files would translate to Objective-C header files, but I'd be willing to believe that they'd look a lot nicer.

No matter what your thoughts are about Objective-C (in my research, I have seen that people definitely have thoughts!), it is compelling. There would be no need to pre-process your class definitions, as it would all be done in the principal language and understood by the compiler.

And no, I will not be writing an Objective-C compiler that targets EPOC16 unless someone wants to pay me much money to do it and agrees for it to be a FOSS project.

Much money.

Brain fog

It's still early days for me, trying to learn a programming ecosystem straight from text books - something I've never been good at. Psion's OO is slowly making more sense to me, but I'm still struggling to comprehend it. This could simply be because it just doesn't feel 100% cohesive to me, at least not yet. Given time I'm sure I'll feel more comfortable.

I do want to learn to use OLIB, HWIM and FORM, mainly because of the new word processor I'm planning on developing The Psion OO ecosystem does seem to be the best way to create graphical apps for EPOC16 without switching to OPL. And I'm not about to reinvent the wheel by rewriting libraries and compilers.

If you'd like to take a look at Psion's special flavour of object oriented C, it's all in the SDK, available here:

https://archive.org/details/psion-sibo-c-sdk

I spent some time today testing out a couple of RS232 adapters with various bits of Psion software. I wanted to write a quick summary of what works and what doesn't:

Notes

CH340

Seems to work in most places, but DOSBox and DOSBox Staging are very unreliable with it. It's very cheap and up until recently was what I recommended, but as I've tried to use SDBG for debugging on real hardware, I've needed something more reliable.

PL2303TA

Great all-rounder so far! I've been using an adapter by UGREEN with this chip in, and it's been solid.

There's just one problem. Prolific discontinued the chip in 2020. Getting drivers to work in newer versions of Windows is a pain. This won't affect you if, like me, you're not running anything newer than Windows 7. Modified versions of older drivers are out there to make the adapter work on Windows 11. Also, stocks will probably run out in the not-too-distant future. Linux, of course, works fine with it.

PL2303RA

I really wanted this to work with everything. You can get boards very cheaply from AliExpress, and my plan was to create two all-in-one Psion RS232 cables - one with a 9 pin mini-DIN for the older machines, one with a Honda connector for the newer ones. But PsiWin 2.3 won't talk to it.

Conclusion

I really want to be able to recommend a good all-rounder for Psion work, no matter what you want to do with the device. The PL2303TA might well be that, but its EOL status might put people off. The PL2303RA was so close to being perfect, but the pickiness of PsiWin 2.3 has scuppered my plans.

I will update this as and when I test more chips. For now I will stick to the UGREEN PL2303TA and separate cables.

It's been a while, hasn't it?

My work on this project has been relatively sporadic over the past 12 months. I've not found it easy to find a balance between this, my day job, and other projects I'm working on. As a result, there have been some relatively intensive periods of work on Psion shenanigans, followed by burnout or other priorities needing to take precedence.

Yesterday I hit a mental brick wall and decided it was time to take a break for a few days. But before I do, I thought I'd post a quick update on what I've been up to Psion-wise over the past year.

EDisAsm

At the beginning of the year, I decided that I needed a small project to ease me back into the world of SIBO/EPOC16. After some thought, I decided to pick up an old open source project.

EDisAsm was a project by Matt Gumbley. The original aim was for it to become an EPOC16 disassembler, but it never quite reached that stage. However, it is a great tool for poking around the memory of a SIBO machine. It could also dump the memory of a SIBO machine over serial, including the EPOC16 ROM. (Bear this in mind for later.)

I felt that it would be a great scaffold for getting back into programming and getting to grips with Psion's proprietary C libraries. So, I asked Matt if he would be happy for me to adopt EDisAsm and take it further. He very kindly agreed to release the code under the Apache2 License, and I was away!

There were a few small bugs, but they didn't take long to fix. I then set to work on adding features. In no particular order:

• Detects screen size, so runs on all ASIC9 machines: Series 3a/c/mx, Siena, Workabout, Workabout mx.
• Specific ranges of ROM and RAM can now be dumped with the sendbanks9000 xx yy command, where xx and yy are 8-bit hex numbers representing memory banks.
• Can now display EPOC16 version and ROM version.
• Can now dump SSDs over serial.
• Can now dump one SSD to another SSD as a file.

I'll write a full tutorial on EDisAsm in the future. For now, if you want to play with it, the latest release is on GitHub.

PsiDrive (Psion SIBO USB Drive)

If you've followed this project for a while, you will know that I've been able to dump SIBO SSDs for a few years. The earliest attempts were done by Karl and I on an Arduino Uno. Richard Warrenden then added directly calling the Uno's pin registers, dramatically increasing the speed.

After spending weeks looking for appropriate level shifters to move between 3.3v and 5v logic, I migrated the code over to ESP32, and then to the Raspberry Pi Pico. I also moved from the Arduino IDE to PlatformIO (a decision I'm still wrestling with). The humble Dump.ino was merged with some of my FEFS code, became libsibo.

Last year I decided that I'd had enough of having everything running on a breadboard and started to work on a PCB. For some reason, I just couldn't work out how to route the board properly. In the end I shelved it, knowing that I'd have to come back to it at some point.

Last weekend I decided that I wanted to have another crack at routing it. After some major shuffling around, I had most of it done by the end of Sunday. On Monday I did some fine-tuning and then checked my work. On Tuesday I ordered five PCBs from PCBWay, and on Thursday I ordered the parts.

At some point during the rework, I decided to name the project PsiDrive. I've asked around and people seem to like it, so it's sticking for now.

I'll be doing a few write-ups of this in the coming months. I'm considering writing a new document about the SIBO Serial Protocol (SIBO-SP), based on the HDK but adding my observations.

libsibo

Other than one bug fix two weeks ago, I have done very little work on libsibo over the past year. My excuse was that I put it on hold until I'd finished the first PsiDrive board. Soon there will be no excuse!

What I will say is that I did do a little testing with libsibo and tinyusb. With some very hacky code, I was able to mount a RAM SSD as a proper FAT12 drive. Writing wasn't stable at all, but reading seemed pretty reliable. It's a good omen for the future.

You can use libsibo by downloading it from GitHub.

MAME

Earlier this year, emulation for a range of SIBO machines was added to MAME. I haven't written any code for this, but I've been part of a small group of people helping out the developer, providing information and ROMs for testing.

For example, I wrote KeyScan, a little tool that shows the column and row of a key on a keyboard, so that the developer could emulate a Siena keyboard properly.

Currently emulated are all ASIC9 machines (Series 3a/c/mx, Siena, Workabout and Workabout mx), the HC and the classic Series 3. MC machines aren't working yet due to an issue with RAM initialisation.

Having an emulator that runs on a modern OS without DOSBox has been fantastic. You can pick your machine and ROM (including the Acorn Pocket Books and some non-English versions of EPOC16), mount SSDs and run games. It will also write to RAM SSD images (just FAT12 volumes made with mtools) and remember your RAMDrive between launches.

One thing that doesn't work perfectly yet is serial comms, which is something I'm really eager for.

You will need to obtain your own EPOC16 ROMs and SSD images. Many of these are obtainable online from wherever you get your MAME ROMs. Eventually you will be able to generate FEFS images, which leads me to...

SIBOIMG and FEFSgen

One thing I did discover this year is that the Psion Flash Filesystem is actually called FEFS. It was originally designed by Microsoft in the 80s and heavily adapted by Psion for their needs.

The other thing that I discovered is that there are two main types of FEFS. 99% of the time, FEFS uses 24-bit pointers. However, a handful very old FEFS volumes use 32-bit pointers. This includes original MC System Disk SSDs and some Psion test SSD images I've found. I've called these FEFS24 and FEFS32 for ease.

FEFS32 makes up a tiny minority of volumes. It's largely not needed, because Psion didn't make SSDs bigger than 8MB. However, I'd be negligent if I didn't include it in my code, so SIBOIMG can now extract files from FEFS32 images. I haven't got around to releasing compiled binaries for this yet, but you can compile it yourself for Linux, BSD, macOS and Windows from the GitHub repo.

But what about making FEFS images? Well, that's where FEFSgen comes in.

FEFSgen is a project written in Go that I started last weekend. Eventually it will make SSD images from a set of switches and a folder structure. Right now it's a private repository on GitHub that I'm using as a playground for me to work out what I'm doing.

FEFSgen is giving me a way to quickly prototype making and modifying FEFS volumes. Eventually I will rewrite these routines and put them into libsibo.

Digging up other Open Source apps

If you look around my GitHub account, you will see a couple of other repos. These are open source apps and games written for EPOC16 that I have found online, checked that they compile, and published them with binaries. These are:

• Pyramid - A Patience Card Game for the Psion Series 3
• nfsc - A VT100 terminal emulator for Psion EPOC16 machines

There is also an empty repo for Elvis, a clone of Vi modified for EPOC16. I do have the code for this, but it currently won't compile with version 2.20 of the SDK. I haven't tested it with earlier versions yet, but I will when I get the chance. At some point soon I will upload the code in its current state, whether or not it compiles.

I'm also working with a handful of other developers who have provided me with their source code. I won't talk about these right now - there may be issue with copyright due to them having had commerical releases through software houses. As I'm sure you realise, if I can release the code, I will.

Mastodon

I've spent a lot of time in the Fediverse this year. The retro computing community has been so incredibly supportive. If I ask a question, I've had a reply almost every single time. People have encouraged me every step of the way, even (and especially) when I've needed to take a break. I've even had a little mention from Sean of Action Retro! You can follow me at bitbang.social.

Discord

The Psion Users Discord has been invaluable. A lot of the work on this project happens over there, both in public channels and behind-the-scenes. We've had people looking at new metal cases for Series 5 machines, new software being developed, investigations into long-abandoned code. In fact, most of the research discussion around the MAME project has happened on Discord. If you're interested in joining in, sign up here.

The Documentation Project

I've really not done enough work on this! I have a lot of notes that desperately need writing up. I also need to think about whether to stick with BookStack or move to something else. I welcome feedback on this. In the meantime, head over there and see what information you can find, as it might help you out.

Final Thoughts

Reading this back, I've done a lot more work than I thought I had. As someone who finds it difficult to recognise his own achievements, this is actually good to acknowledge. It's a tiny drop in the sea of Psion research, let alone the vast oceans of retrocomputing, but it something.

I do want to write more up, and I'll try not to leave it as long next time.

Finally, it's here! Some proper code for reading SSDs and (eventually) other SIBO peripherals.

I've spun off some the Arduino code from SIBODUMP, added the FlashFS code from SIBOIMG, ported it to PlatformIO, and pushed it to GitHub.

So, the TL;DR is:

• Two major bugs squished.
• It works with more boards now (Pico, ESP32, Arduino Nano)
• It's still uses the Arduino libraries, but it's now based on PlatformIO
• You'll need level shifters for 3.3v (I've included an example)
• Would regular Raspberry Pi compatibility be useful?
• Next steps
• Discord chats

So, take a look at the code over on GitHub, then read on.

https://github.com/PocketNerdIO/libsibo

Bugs? What bugs?

In my attempts to tidy up the code, I'd completely broken the PORTD code for Arduino boards. This was specifically with Data Read frames. Basically, I'd added a return where one wasn't needed. This meant that I wasn't sending the final idle bit, shortening the length of the frame to 11 bits and completely confusing the SSD. In addition, I wasn't returning anything to the main code, so it just sent back x. I removed the erroneous return, and everything went back to normal.

Also, it turns out I'd completely broken device selection (used for SSD bank shifting) after I moved the code into a class. There was code to select a device in main(), there was code to use a device number in the selectAddress() method, but there was no way for main() to actually send the device number. This meant that the class always thought that it needed to speak to device 0. On an SSD with four devices (banks), it would just send the contents of the first device four times. 10 lines of code later and it was working, but I was definitely kicking myself for missing that.

Why stick with the Arduino libraries?

I decided to stick with using the Arduino libraries for a few reasons. First, I wanted this to be compatible with as many microcontrollers as possible so that anyone could have a go at running the code. DigitalWrite() might be slow, but it's going to work on everything that Arduino runs on. I did seriously consider focussing solely on the RP2040 SDK, but that would have meant that people couldn't just use an Uno they had in a drawer. Besides, the beauty of the RP2040 cores available is that they all include the RP2040 SDK as well, so I can have the best of both worlds.

Second, I wanted development to be as quick as possible, without worrying too much about the vagaries of specific microcontrollers and their SDKs.

So far, libsibo has been tested on the following board/core combinations:

Note that the Arduino MBED core for the Pico doesn't currently support the RP2040's PIO, which I think is a major oversight. Luckily, Earle Philhower's RP2040 core does, and it supports many more RP2040-based boards. For now I'm keeping compatibility with the MBED core, because it doesn't seem that difficult to keep it in. There is also the Wiz-IO core, but he seems to be unhappy with the Raspberry Pi Pico team... Drama in the microcontroller world?

I may abandon ESP32 development in the future, as I think the RP2040 is a more suitable platform. Also, at this early stage I don't really need WiFi or Bluetooth. I'm almost certain that any USB SSD Drive that I design will be based around the RP2040.

Why PlatformIO?

Two reasons. First, I really dislike the Arduino IDE. It's fine when you start off, but I really need more features in my IDE. Visual Studio Code is far from lightweight, but it does its job very well. PlatformIO sits nicely inside VS Code. (Side note: I am considering switching to Neovim, but that's a whole other discussion.)

The second reason is that PlatformIO makes it really easy for me to compile code for multiple boards and cores. One click on the status bar and I can find out if the new code I've just written for the Pico will break compatibility with the Uno.

How do we get 3.3v microcontrollers to work?

Level shifters! I do want to write a dedicated log about this, but for now I'll post a screenshot of the shoddy schematic I've knocked together for the Pico. In this diagram, GPIO14 is DATA, GPIO15 is CLK, GPIO16 is DATA direction, and GPIO17 is CLK. The 74xx chips mentioned are the exact one I'm using now - they work with the ESP32 and the RP2040.

One of the main reasons why I've kept in Uno and added Nano support is that life is much easier with 5v for SIBO kit. You only need to use two GPIOs - CLK and DATA - whereas you need the extra 2 to control the level shifters.

What About the regular Raspberry Pi?

This hadn't crossed my mind before, but someone mentioned it to me a couple of days ago. It would be possible to have a LInux app that uses libsibo as its "back-end." Libsibo would then talk directly to the Pi's GPIOs. Again, it would need some level shifting, but it's certainly doable. Let me know if you'd like this and, if I have time, I'll see what I can do.

What's to come?

A lot! I really want to get the code working with the RP2040's PIO (you can probably tell I'm excited by this). Everything's currently on a breadboard, and I want to at least put it on perfboard so I don't have flying leads everywhere. There's a lot of work to do on the Psion Flash Filesystem code. The whole of the hardware code needs redoing from the ground up to be more intelligible. Most SIBO peripherals that aren't SSDs also use interrupts, so they will eventually need to be implemented. And that's just for starters.

I hope this has given you all an update on how things are going. Over on Discord, some of our members are trying to find the best way to get EPOC32 machines (Series 5, Series 5mx, Revo) on the Internet, so if the ARM based machines are more your thing then head there.

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.

Near the end of last year I hit a wall. After spending months trying to learn VHDL and feeling very much like I was failing, I decided to put my participation in the project on hold. I had burnt out and it was time to walk away, if only for a little while.

Now, almost a year on (and what an insane year it's been!), I've recently got in the mood to take another look. On a personal note, I'll be approaching it a little less frenetically — I'm working on a couple of other personal projects and want to try to share my time between them, not to mention having a day job as well. But my enthusiasm for the project is still strong and I really want to see where it goes, even if it takes me a few years to get there.

As before, my next step is to attempt to recreate Psion's ASIC4 chip in VHDL and then get it running on an FPGA. This, to me, would give the retro community something very interesting to play with. First, it would provide a never-ending non-destructive supply of ASIC4s. And second, it would make ASIC4 customisable.

Both of these points are important for the WiFi Pack, but would also be really useful for other projects. For example, having the ability to translate SIBO-SP into SPI would mean SD card access.

Early last year I bought a few breakout boards that were, in short, the right size for an ASIC4 chip. My plan was to cannibalise an SSD, remove its ASIC4, solder it to the breakout board, and then basically build a massive SSD. That way I could easily test all of ASIC4's pins and see exactly when traffic was happening. For example, precisely when are the address lines made active to write to the on-board memory?

But so far I haven't done this. I've not been confident enough with my own surface-mount soldering skills (let alone desoldering) to risk breaking an ASIC4. However, I know how much it would help.

Another thing I've done is message Zebra Technologies (the current owner of the Psion SIBO/EPOC16 IP) on Twitter to see if they can help. I'm hoping that they might have some old backups of, say, a server around 1995 that might include some documentation on ASIC4 and ASIC5. If anyone fancies giving them a nudge, feel free - I could use all the help I can get!

I'm also planning on moving the https://psion.info site around a little in the coming weeks. The Documentation project will be shifted to its own subdomain, and the main site will be some static pages including links to resources and (hopefully) a few useful downloads like the original SIBO C SDK and HDK. There are some concerns about copyright, but this is all pretty much abandonware so I'm hoping Zebra won't mind too much.

On the subject of documentation, I have a pile of hardware — some purchased, some kindly given to me by very generous people — that I'm slowly going through, testing and tearing down. One thing I'm interested in is the Honda RS-232 port on the 3c, 3mx and Siena. It turns out that this isn't a pure RS-232 port, and there might be some SIBO-SP pins hidden away. Using a Siena SSD drive, I need to solder together a little man-in-the-middle cable to monitor those pins to see what they do. I'll update here when I get around to putting that together.

I'm also still digging through an archive that a former Psion exec sent me early last year. There's a huge amount in it (just not much about ASIC4), which I would just publish if it weren't for the potential copyright issues; the SDK has been available on various sites for a while now, but this archive includes schematics for things like the MC range of laptops that (I think) were never released to the public. (Hey, Zebra, nudge nudge...)

One other thing I did... I bought a display cabinet for my Psion kit. Here's a photo. On the top shelf is an MC400. Those Really Useful Boxes at the bottom are project boxes, each one stuffed with pulled-apart SIBO machines. It fits in nicely in my old Victorian house.

So yeah, that's where I am so far. Not sure when I'll be updating this next, but if anything crops up I'll let you know. In the meantime, please feel free to message me with questions and missives of undying support.

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) 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.

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.

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. Or just in the comments below.

UPDATE: The latest version of SIBODUMP has just been released along with binaries for Windows and macOS. Take a look here: https://github.com/PocketNerdIO/sibo-ssd-dump/releases/tag/0.0.3

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.

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!

https://github.com/PocketNerdIO/sibo-ssd-dump