#psidrive — Public Fediverse posts

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

• Get as many of the #Psion SIBO C SDK apps rewritten as possible. I really enjoy using #FreePascal for this! It's vastly underrated for writing cross-platform CLI apps.
• Make some code run on #EPOC16 from a tiny/toy #compiler of my own. Not an entire C compiler, just something where I've generated some 8086 (or NEC V30) assembly from something very basic that actually runs, including implementing the TopSpeed calling convention.
• Work out how the #MAME debugger works so that I can add 4MB RAM support to EPOC16. Maybe learn some things about the internals of EPOC16 along the way. Eventually write this updated EPOC16 ROM to flash and get it running on real hardware.
• Make a #PsiDrive PCB that can write to flash drives. Just needs a +16V boost converter added to the board.
• Get an #RP2350 to pretend to be a small Psion SSD, using the on-die RAM and PIO. Bonus if it uses a battery. Extra bonus if it can write to external RAM or Flash.
• Move #libsibo away from the Arduino libraries and over to the Pico SDK. This just feels like the right move, but means I'll need to learn cmake as well.
• Learn how to write good unit tests. It's not a problem with learning frameworks - both fptest and fpcunit are simple enough. My brain is freezing when trying to decide on what to test and why. I know my code will improve once I've grasped this.

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?

#retrocomputing

Current main projects:

• #ecobj: Another piece of the #Psion SIBO SDK rewrite puzzle. ECOBJ.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.
• Get my website running #GoHugo (this is almost done!).
• #CTRAN: Still haven't started writing unit tests. Also, complete a full write-up of what it took to get the thing working.
• Research into compilers: I'm nowhere near ready to start yet, but I'm learning as much as I can.

Upcoming projects:

• #siboimg: Rewrite in Pascal, and add the ability to create and modify FEFS images.
• #plptools: I'd like to see two-way transfer working for EPOC16 -- I'm sure I'll need the help of the rest of the maintainers to get this working. I can't do much with the #HaikuOS port until the USB serial drivers are "fixed" (hardware flow control added) -- I don't think I have the skills for this, so it'll have to wait until some kind soul has the time to work on it.
• #PsiDrive: Add a ~17V boost converter to allow writing to Flash SSDs.
• NAS/home server: Rebuild or replacement of DEATH, my Microserver gen8. It's been over 18 months since DEATH's RAID died. It's lead me to thinking that maybe I don't need the sort of server I thought I need. TBD.

Maybe next year, maybe not:

• New Psion SSD with RP2350: I doubt I'll get anything made, but I'd like to experiment to see what can be done with the protocol.
• Rewrite the rest of the SIBO C SDK tools.
• Compiler: Recreation of the JPI/Clarion TopSpeed C compiler, targeting the SIBO/EPOC16 platform (8086 and V30). I was hoping to get going with this around July this year, but it just didn't happen. This is my Everest. I know I'm not ready yet. I need to train for it.
• Vine: New word processor for EPOC16. Trying to start this project in 2023 lead me to rewriting the SDK, so we're quite some way away from getting this done.
• Research into Objective-C: Not Foundation, just the syntax. For compiler shenanigans.

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

#Psion

Current main projects:

• #plptools: Resurrecting old ports (#FreeBSD, #NetBSD) and working on a new port to #HaikuOS. It's an opportunity to get more familiar with the code and maybe find bugs along the way.

Upcoming projects:

• #CTRAN: Still haven't started writing unit tests. Also, complete a full write-up of what it took to get the thing working.
• Get my website running #GoHugo.
• Rebuild of DEATH, my Microserver gen8, probably with #FreeBSD. (Yes, it's been over a year since DEATH's RAID died.)
• Pick another SIBO SDK tool to rewrite. (Probably EMAKE or RCOMP.)
• Add a 17V boost converter to #PsiDrive.
• Make #fefstool create FEFS images. (I'm half-tempted to rewrite fefstool in Pascal to make it easier for me to finish.)

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.

https://youtu.be/fgIlNfnWocM

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.

An infodump on #PsiDrive, #PlatformIO, and the #RP2040 and #RP2350.

Testing libsibo (the basis of the PsiDrive firmware) on the Pico2 has reminded me that I was planning on revisiting the tooling I'm using for libsibo.

I'm currently using PlatformIO with VS Code. The main pros are usability and portability. It's very easy for me to target multiple platforms - in my case Arduino Uno, ESP32, RP2040 and RP2350 - and switch between them using a single, simple menu. Plus it means I don't have to use cmake with the Pico SDK.

But there are cons. The main issue is that PlatformIO stopped accepting pull requests on their Pico support. Basically, PlatformIO asked Raspberry Pi Trading for a recurring fee to maintain the support, and RPi said no.

Now, there is a very popular Arduino-Pico core maintained by Earle Philhower, with a PlatformIO plugin for it by Max Gerhardt. This is what I've been using so far and it's been very reliable. I can write Arduino C code that runs on any compatible board, and then tailor the code for specific boards (i.e. directly calling the Pico SDK for a speed boost). But that might not last forever.

I've been considering making libsibo RP2040 and RP2350 for some time. ESP32 support was a temporary stop-gap before landing on the RP2040, and I didn't feel like it was the right microcontroller for the job. The Uno was where it all started, but it's far too slow for use in the eventual PsiDrive device. I think I'd be better off maintaining a separate sketch that I bundle with sibodump for people who just want to dump Psion SSDs using an Uno.

This would mean I could switch completely to the pure Pico SDK - I wouldn't be reliant on any other intermediary packages. I could focus libsibo on a single platform, a single toolchain. I could also use the Pico Probe properly.

But there are downsides. I'd no longer have the safety net of the Arduino core, plus I'd probably have to rewrite some of the code to port it to the pure Pico SDK. I'd lose the nice interface, but I'd probably swap to NeoVim anyway. Plus there's cmake, but I'm going to have to learn to use it at some point anyway.

Anyway, those are my thoughts. Feel free to reply with yours, or not.

Good news! The #RaspberryPiPico 2 is a drop-in replacement for the original Pico in the #PsiDrive!

It seems that the pulldown issue-that-is-officially-not-an-issue doesn't affect this version of the PsiDrive board. I've tried dumping a ROM SSD and it worked with no changes to the code.

Very happy!

#Psion #retrocomputing #rp2350 #PiPico2

Moved instance, so time for a new #introduction!

I'm Alex and I have a PDA problem.

In 2018, after 16 years of using various #Psion portables, I decided to try my hand at developing hardware and software for my beloved Series 3c to help me with journalling and creative writing.

6 years and repeated sidequests later, I've ended up doing a lot of research into the SIBO/EPOC16 platform, and done my best to document it when I can. I've also nudged former developers into open sourcing their old Psion apps.

My current main projects are:

• #PsiDrive, an #RP2040-based USB drive for SIBO SSDs.
• Rewriting the Psion SIBO (16-bit 8086) C SDK, including updating the docs (with #AsciiDoc) and rewriting the original DOS tools as FOSS apps. I'm currently using #FreePascal to create a drop-in replacement for #CTRAN, the Psion OO C preprocessor. (I want to eventually write a new compiler targeting EPOC16. Eventually.)
• Anything else that tickles my bouncy brain.

Outside of #retrocomputing, I'm your common-or-garden British nerd. I'm a Linux user - mostly Arch, but I dabble with others. I also like a bit of #HaikuOS and I'm planning on giving #FreeBSD a go very soon.

I used to be a senior computer monkey, specialising in on-prem SME infrastructure (I lament the loss of vSphere). Now I train others to become computer monkeys (for better or worse). As a result, sometimes you'll see me wrestling with old Cisco ASAs, Ubiquiti APs, or modded kit running #OpenWrt.

Generally, I like making things do stuff, especially if it's stuff that the thing wasn't originally designed to do.

Upcoming projects:

⏸️ Learn #Psion's proprietary 16-bit OO C.
⏸️ Rewrite more of the SIBO SDK.
⏸️ Learn about designing #compilers and #assemblers.
⏸️ New version of #PsiDrive PCB.
⏸️ Vine: A new #FOSS #EPOC16 word processor aimed at writers/authors, with Vim motions and #AsciiDoc compatibility.
⏸️ Converting the Psion SIBO C SDK to AsciiDoc.
⏸️ #fefstool: Like #mtools but for #Psion Flash (FEFS) volumes.
⏸️ #MAME null modem mod, so that it can talk properly to #DOSBox.
⏸️ psion.info redux.
⏸️ More docs!

So, after #ctran, what projects are afoot in the near future? Hardware!

- A RAM upgrade for the #Psion 5mx.
- A possible RAM upgrade for the 3mx (I have a hunch).
- Possibly a new #PsiDrive board revision with fixes and a voltage booster.
- Something not #retrocomputing at all! Gutting a Roberts internet radio and replacing the innards with an #ESP32 or #RaspberryPiPico W. (Because the BBC discontinued their ShoutCast streams last year.)

I might also pick another SIBO C SDK tool to rewrite.

My musings from last night about the #Psion Siena SSD Drive, plus a couple of pics of the #PsiDrive.

I know this is a long shot as there aren't many former Psion employees here. But if *anyone* has the schematic for the Siena drive (or any other information, such as the 3a schematic, or information on the Condor chip), please get in touch.

#RetroComputing #VintageComputing #RetroDev #16bit #RaspberryPiPico #RP2040 #OldTech

https://hackaday.io/project/186446-psidrive-a-usb-psion-ssd-drive/log/225072-the-psidrive-and-thoughts-on-the-siena-ssd-drive

All #Psion SSDs are 5V - some are TTL (ASIC4), some are CMOS (ASIC5), but they're all 5V.

So, is this is where the 74HCT126D comes in? Is that what's converting the 3V (or 3V3?) to 5V?

Here's the datasheet: https://assets.nexperia.com/documents/data-sheet/74HC_HCT126.pdf

This is important to me, because in the #PsiDrive I'm using a 74AHCT1G125 and a 74AXP1T45 for level conversion from the RP2040 on the Pico. If there's a different way of doing it, I want to know.

I need to get a scope on this to properly work out what's going on.

Thought I'd take a look at the PCB of the #Psion Siena SSD Drive. My aim with the #PsiDrive is to make something the same size as the Siena drive, so I want it to be the same size.

Here's a shot of the PCB.

I have no schematics and I haven't scoped it yet, so what follows is all guesswork.

So, now the MAME/Haiku project is essentially done (just waiting for my PR to be merged now), I'm thinking about what to work on next.

Outstanding #Psion projects:
- #FEFSgen (golang) to make flash SSD images
- #libsibo: add write for RAM SSDs
- #PsiDrive: add boost converter (set to ~17VDC) for writing to Flash SSDs
- Psion SDK to #AsciiDoc: SO MUCH DOCUMENTATION TO CONVERT!
- Blogging: SO MUCH DOCUMENTATION TO WRITE!
- #EDisAsm: because there's always room for more features

As I'm busy compiling stuff in #HaikuOS for some future #Psion shenanigans, I thought I'd try compiling SIBODUMP and SIBOIMG to see if I could use the #PsiDrive to dump an SSD and extract the files.

They worked first time! I don't know if that's a testament to my programming skills, or if it's just that the apps are so simple that they'll compile and run on anything vaguely POSIX-compliant.

For some reason, dumping was VERY slow. Don't know if that's VirtualBox or Haiku at fault.

At some point I want to develop a smaller #PsiDrive board with an integrated #RP2040, rather than adding a #RaspberryPiPico.

This article on @hackaday didn't just link to a great article on the subject. The advice in the comments is also really useful.

#RetroDev

https://hackaday.com/2023/10/11/how-not-to-build-an-rp2040-board/

IT LIVES!

Please welcome to the world the #PsiDrive, a #Psion USB SSD Drive using a #RaspberryPiPico.

This works with the SSDs that were used with the SIBO range of computers, including the Series 3 and MC400.

This prototype can only be used to dump SSDs, but future versions of the firmware will let you write to RAM SSDs, and future versions of the board will let you write to Flash SSDs.

#retrocomputing #retrodev #rp2040 #pcb #90s

I'm not working on the #PsiDrive this morning. Been to the gym and I'm about to head out for a morning outside. But I thought I'd fill you all in.

So... There's something wrong with the CLK circuitry.

Somehow the decoupling cap for the AHCT 5v rail shorted. Removed the cap, and now there's no CLK signal on the 5v side. The Pico is working fine, as is the AXP for DATA.

I don't know if I've blown the AHCT, or I've done something wrong with ~CLK_OE.

For now, though, I'm off to touch some grass.

EEEEEEEEEEEE!

#psion #retrocomputing #psidrive #pcb

Wrote up a summary of the past year on Hackaday IO (@hackaday) because it was rattling around in my brain.

OK, *now* I'm going to rest.

#psion #retrocomputing #EDisAsm #sibolib #mame #PsiDrive #epoc16 #pda #vintagecomputing #retrodev #retrospective

https://hackaday.io/project/161291-the-last-psion/log/222163-a-long-overdue-update-pcbs-emulators-and-more