Asic4 on The Last Psion

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.

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

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.