The Last Psion

By Alex Brown

What started off as a "simple" project to reverse engineer the Psion SSD and build a Wi-Fi adapter has grown into something much larger.We are performing platform necromancy, gathering together as much information as we can from long-abandoned websites, rattly hard drives and the back of rusty filing cabinets.The original plans of making new Psion SSDs and a Wi-FI adapter are still happening. But the scope has now widened into rewriting the SIBO C SDK and HDK from the ground up, creating a new C compiler and chipsets that will work with the platform, all for the 21st century.

Do you have documentation, software or source code we need? https://docs.google.com/spreadsheets/d/1fs34pJAH2Ues7ABdbZOr9H9hFkRE9D99Y_BpqwGbcms/edit?usp=sharing


Were you an EPOC16 developer? Release your old code!

Have you ever had a dream to create something that, on the surface, seemed pointless? Then, when you scratch away that surface, you realise exactly how insanely difficult that dream would be to achieve?

I had one of those dreams.

I started off wanting to build a device that will add modern storage and Wi-Fi to my ageing but beloved Psion Series 3c, one that would fit into its SSD port. Difficult enough, you'd think.

Then Karl got in touch with me.

After some months of discussions and work, the project has developed into an attempt to perform platform necromany.

We believe that the SIBO/EPOC16 platform deserves a place in the retrocomputing world, alongside giants like the ZX Spectrum and C64. We want to play to the platform's strengths: The massive battery life, the non-backlit screen, the full keyboard, the deep sleep mode, the simplicity, the expandability.

The SIBO/EPOC16 platform was well ahead of its time. We want to breathe new life into this vastly underestimated platform.

SIBO vs EPOC16

Over the years different conventions have been used to refer to the hardware and software that Psion developed. Various documents use SIBO, EPOC and EPOC16 interchangeably to refer to the hardware and software. For clarity, we have decided to use the following convention.

SIBO is the hardware platform, including:

  • MC200
  • MC400
  • Series 3 (and its clone, the Acorn Pocket Book)
  • Series 3a (and its clone, the Acorn Pocket Book II)
  • Series 3c
  • Series 3mx
  • Workabout
  • Workabout MX
  • Siena

Our main focus is on the 3a, 3c, 3mx and (to a lesser extent) the Workabout MX. All of these machines use the ASIC9 and have SSD ports. We will also pay some special attention to the MC400.

EPOC16 refers to the name of the operating system that runs on the SIBO hardware platform.

To refer to the whole hardware/software platform, we will use SIBO/EPOC16.

  • Creating a replacement for Psion's ASIC4 so that new hardware peripherals can be developed.
  • Build a storage device that mimics the Psion SSD based on this new ASIC.
  • Add Wi-Fi capabilities to this device using an ESP microcontroller so that files can be uploaded to and downloaded from cloud storage as well as an application and drivers to control the "non-standard" functions of the device.
  • Write EPOC16 drivers to control the Wi-Fi, maybe more.
  • Rewrite the Psion SIBO C SDK and HDK from the ground up.
  • Create a new C compiler.
  • Write software, such as a better word processor and many games!
  • Update the EPOC16 ROM with new applications and features.

TECHNOLOGIES AND LANGUAGES

  • C and C++ for Psion EPOC16 development
  • Python for writing sigrok decoders to analyse the SIBO Serial Protocol
  • Programmable Logic Devices and VHDL (for the bi-directional serial line, possibly more)
  • 8086 Assembly for writing new (and possibly analysing existing) EPOC16 drivers
  • APIs for at least one cloud storage service (e.g. Google Drive, Dropbox)
  • EPOC16's Filesystem Formats; each storage type has its own filesystem. RAM SSDs use FAT16, ROM SSDs have their own format, Flash SSDs use yet another format, and the system ROMs use something else.
  • EPOC16's File Formats, especially its word processor.
  • A lot more we haven't even thought about yet!

BUT WHY?

For years I have had an affection for the Psion Series 3 and Series 5 machines. I got my first Series 3a back in 2002 and loved it. Over the following years I used it as a journalling device, a platform on which to write while commuting. When the hinges on that 3a broke, I bought another one on eBay. Eventually the hinges on that one broke, too. I later bought a Series 5, but manage to crack the screen on it. I lived in a Psion-less abyss for many years. Life took over and my passion for these machines faded into the background.

This year I bought a Psion Series 3c. I loved getting back...

Read more »
  • Alex Brown10 hours ago 0 comments
  • Alex Brown12/06/2018 at 11:23 2 comments
  • Alex Brown11/10/2018 at 23:01 0 comments
  • Alex Brown10/21/2018 at 14:19 0 comments
  • Alex Brown10/13/2018 at 20:09 0 comments
  • Alex Brown09/19/2018 at 10:02 1 comment
  • Alex Brown09/17/2018 at 13:38 0 comments

      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 ASICs, 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:

      1. 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.
      2. 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.
      3. 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....

    Read more »

View all 7 project logs

Psiological wrote 09/28/2018 at 17:22

A fantastic idea to use the SSD slot!  All the other devices, such as the Workabout would benefit too and that would be MASSIVE.  I wish you success in your endeavour!

Are you sure? yes | no

Alex Brown wrote 10/13/2018 at 20:52

Thanks! I've still got a long way to go, but I do think it's doable. And I didn't even think about the Workabout. I don't have one currently, so if I get to a suitable point I might try to get hold of one.

Are you sure? yes | no

Artur wrote 09/20/2018 at 19:19

I'm very huge fan of psions there was a time when i have psion 3a,3mx,5,7 and a few 5mx and this last one was my favorite. I was wondering few times if there is possible to design custom expansion module for psion. After briefly look at http://www.scss.com.au/family/andrew/pdas/psion/hdk.pdf i thing there is no need to use CPLD or FPGA, and regular MCU will good enough.  So just use device like ESP32 or something familiar :) .

Are you sure? yes | no

Alex Brown wrote 09/21/2018 at 07:27

It would definitely make my life a lot easier if I could just use something like an ESP32. I'm just worried that it won't be fast enough to handle it. Perhaps I just need to try it, see how it goes and if it doesn't work add a CPLD in to the mix?

I've also got a 5mx, but it won't read any of the CF cards I've tried in it. One thing that might be possible is to replace the IrDA circuitry with a BLE device. Something I might try in the future.

Are you sure? yes | no

brtnst wrote 09/19/2018 at 17:08

Awesome project! I wish you good luck on reverse-engineering all the bits and bobs of your Psion. I am a big fan of Palm PDAs and I also struggled with limits of twenty-year old technology, I ultimately solved it by developing Palm 3 like PDA from scratch (SDA project here on HaD). I suggest you to do the same. Your project will likely take few years and great skills to complete and you will end up with a fancy add-on for old device that will be hard to get and hard to fix. You can use the same skills to make your own PDA, it will also take a few years, but you will end up with a better product.

Are you sure? yes | no

Alex Brown wrote 09/19/2018 at 18:51

I must admit, it has crossed my mind to build my own PDA. Maybe using the shell of a Series 3 or Series 5, replacing the LCD with an ePaper screen, the innards with something that would use as little juice as possible, a relatively simple OS, having WiFi and at least one SD card slot. For the moment, though, I'm going to stick with this project. Even if I abandon it after trying to reverse-engineer the storage, I'll still have learned enough to keep me going. If I get as far as synchronising files with Google Drive, then I can transfer that knowledge over too. Also, Psion 3a and 3c units come up on eBay all the time - I've actually got a spare 3c at home (cost me £15 with a Flash SSD), as well as a 3a with broken hinges that I picked up for under a tenner.

I have to say, though, I've just taken a quick look at your SDA and I'm really impressed! Is that a custom OS you're running on it? I'll read up some more later.

Are you sure? yes | no

brtnst wrote 09/19/2018 at 21:07

Creating your own hardware gives you real freedom, if you do not like something, you can always change it, update it, upgrade it, fix it or rebuild it. You are not locked in a mess of undocumented proprietary hw and sw. But I can see the beauty in updating an old device.

If the storage reverse-engineering fails, you can try to tap in the infrared port, it is basically a serial port and I think that it would be easier interface to connect psion to the ESP this way, then sync it to google by "beaming" the files. Or you can use the PC sync serial port. But creating custom wifi enabled ssd module would be the cleanest solution.

SDA is indeed powered by custom software, I have few project logs about the software and I also moved most of the sources on github.

Are you sure? yes | no