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.