Yesterday, I assumed that ASIC4 Extended SSD mode only used 3 bytes for addressing + device select. But writing that list of ASIC4's modes earlier and re-reading the HDK prompted me to check. After some testing, I found that it does indeed use 4-byte addressing + device select, but for some reason can't use 256MB devices with the method I've outlined above.
So, there will be an update to the #PsiDrive firmware being uploaded very shortly, with added compatibility for a series of comparatively massive SSDs (for the 90s) that have never existed.
My first thought was that it could be a problem with the Pico 2, either with the code or the RP2350 A2 stepping chip. So, a couple of days before, I built a second #PsiDrive and put in a Pico 1. But the fault remained with with Pico 1.
This meant it was an issue with my code somewhere. I thought it was strange that I'd never noticed it before, so it must be some weird edge case.
Who wants a deep-dive into a tiny aspect of #Psion SSDs and their ASICs?
I was using a #PsiDrive a couple of months ago to dump a 2MB SSD. However, when I tried to extract the files, my FEFS extraction tool (siboimg) segfaulted halfway through. So, as I was in a rush, I decided to come back to it another day. Yesterday was that day.
🧵
Things I'd like to achieve next year
...with zero pressure - just stuff I'd like to do if I get the chance
There are a lot of moving parts to all of these. Some need me to learn multiple sub-skills, such as 8086 assembly. Like I said, this isn't a list of Things Alex Must Get Done Next Year. I'd be happy if I achieved just one of them.
I'm curious... Which one of these would you like to see the most?
Current main projects:
The Last Psion | AlexECOBJ.EXE takes an Intel OMF file (.OBJ) for a class and moves the class descriptor data into the code segment. I think I might be able to get this working by the end of the year.Upcoming projects:
Maybe next year, maybe not:
I've really struggled to get going with projects this year. That's fine, these things happen. But I'd like to find better ways to cope next year so that I can make a little more progress.
Why am I mentioning this? Well, different parts of me want to do different things.
A new #Psion SIBO SDK is, from the outside, not something all that interesting to those who don't understand what an SDK is. CLI tools are boring. This is not a bad thing - they should be boring! They need to get out of your way. But it's hard to go to a #retrocomputing con/fest and show the work that you've done on recreating a C preprocessor. Compilers (one day, one day...) are only interesting to other developers, and generally only appreciated by those who understand how difficult it is to write one.
Hardware is easier for people to grasp, figuratively and literally. I'd like to show a thing. #PsiDrive is good for this. Physical PCBs that you can show working. I would like to revisit making an SSD with an RP2350 - that would be useful for all sorts of reasons.
There's also all the research on the platform that underpins all of these. Logic analysers attached to pins, the ROM dumps, the photos of the PCBs, the uncovered or recreated documentation. Again, this is hard for people to see.
There is, of course a not-so-subtle subtext in those three paragraphs. There are projects that I think are useful, and there are projects that are more likely to grab people's attention. Those two categories aren't mutually exclusive, but they do vary from project to project. And many clearly have less of the latter.
I think we can all agree that I've picked a particularly niche area of #retrocomputing. In fact, if you count the fact that I really focus on #Psion's 16-bit machine, one could say it's a niche within a niche within a niche.
In spite of this, there is still so much that I can work on! A lot of SIBO (hardware) and EPOC16 (software/OS) hasn't been explored for decades, if it ever was by the community.
And modern advances in technology make it so much easier to do things. For example, #PsiDrive would have looked very different and been much more expensive to produce 15 years ago.
That's most of my projects moved to #Codeberg. #PsiDrive and #libsibo have been migrated, along with a few more minor repos.
https://codeberg.org/thelastpsion/libsibo
libsibo is due for a rewrite. I've been thinking about moving away from using the #Arduino core for about a year, and the recent Qualcomm news was the final nudge.
PsiDrive is definitely an #RP2350 project now. I've wanted to drop ESP32 support for some time anyway. If people do want to dump an SSD with an Uno, the original Dump.ino code bundled with sibodump (also on Codeberg) works perfectly.
So, it's time to shift the project to the RP C/C++ SDK.
It's just a matter of finding the time...
Current main projects:
Upcoming projects:
You'll notice that some of these projects have been sitting for a while. I've struggled to get going with things this year. I'm hoping that working though plptools will give me some mental energy to get going with other things.
For #PsiDrive, I need to add a 16.5V rail (Vpp) to enable writing to Flash SSDs. Vpp from a SIBO machine is unregulated - although schematics tend to say 16.5V, the real voltage can be somewhere between 16V and 20V (I think I once measured 21V, but that could have been an unreliable multimeter). Flash SSDs have an LM317LM which then regulates down to the required voltage.
This video should be a good start.
I also need to fix a small bug in the last PCB, which sent 5V to Vbackup for RAM SSDs. It should be 3.7V, to match the coin cell battery. Admittedly it might not matter, but I don't know if I want to chance it.
Once I've done all this, I can move on to adding more features to libsibo, such as writing to SSDs and properly using the PIO in the #RP2040 and #RP2350.
