Recent searches
Search options
#psion
1 post1 participant0 posts today
Replied in thread
@rpimag Been working on the enclosure for my #Psion project. This is the top of it. The "blades" at the top are so the hinges don't get too stressed. I can appreciate their level of stress, today especially! 
#MakerMonday
This could be really handy!
Unfortunately I can't find the part mentioned in the article for less than £45 on eBay, so it might not be the most affordable choice in the UK or EU. But hardware-wise it looks like a really good option.
This should work with all #Psion Honda machines - 3c, 3mx, Siena, 5, 5mx, 5mx Pro, 7, netBook, netBook Pro.
https://www.cloudcube.info/2025/03/27/diy-psion-series-5mx-serial-cable-at-a-relatively-low-cost/
www.cloudcube.infoDIY Psion Series 5mx serial cable at a relatively low cost – CloudCube's digital gadgets blog
HIVEMIND: Does anyone have a copy of the TopSpeed Pascal 3.10 compiler?
I've discovered something. I can't unsee it. So now I have to follow it through.
The [TopSpeed] Pascal compiler could also be used to develop software for the Psion series 3 in a roundabout way if used with the PSION s3 SDK, as the environment allowed you to develop Pascal code with C code, headers and libraries you could get functional s3 apps by linking the Pascal code with the required C headers/libs and then compiling everything with the PSION SDK, in rare cases needing a little bit of glue C code.
Source: http://www.edm2.com/index.php/TopSpeed_Pascal
Does anyone have a copy of TopSpeed Pascal? I need to try writing Pascal software for #EPOC16. The documentation would be really handy, too.
www.edm2.comTopSpeed Pascal - EDM2
Any #3dprinting design advice for me? I have this case for the #Psion Pi project that I want to print (see pic). The trouble is, Cura is estimating > 24 hours each for the two "big bits". I am reluctant to print at home THAT long as it'll disturb sleep/others in bouse. Can I split the bits up somehow and assemble? 
Next project! Psion Pi keyboard conversion – more details as we go!
My next project is to successfully convert a Psion 5 keyboard for use as a Raspberry Pi keyboard.
You can find all the details, in the form of a build log, here!
Continued thread
Further investigations with #Psion ramdrive shenanigans, this time including the 3mx in MAME (which currently has 512KB). Plus some other notes on the hardware, some guesses, MAME debug tools, and a small but helpful #EDisAsm update.
512K
In this mythical device (emulated in MAME), the root of M: starts at page 07, 0xDFF0. Ramdrive filesystem blocks are 256 bytes on this machine, so smaller than normal for FAT12 (they're 512 bytes on the 2MB 3mx).
The astute among you will have noticed that page 07 is the last block in 512K RAM. From 0xDFF0, blocks for M: are added in reverse order. So the block for the first file is at 0xDEF0, then 0xDDF0, then 0xDCF0, etc etc.
This is what I'd assumed would happen with all models of the 3mx - root record at the top of RAM, then working backwards so that normal working RAM doesn't interfere with the ramdrive. But that isn't the case with the 2MB model (starting in page 08, working up from 0x4200, and probably isn't with 4MB (currently looking like page 08, working up from 0x6660, but still broken). I haven't checked with older ASIC9 devices yet (3a, 3c, Siena, Workabout 1).
Also, I got it wrong before: 512K model is 1x 4Mbit chip (256Kbit * 16 bits), not 2 chips.
ASIC9MX
According to the SDK, ASIC9 can address up to 16MB RAM. It has 4 RSEL lines (used in the ASIC9MX as chip selects), and 2 CSEL lines (upper and lower halves of the 16 bits). AFAIK, each window is 2MB (pages 0x00 to 0x1F). So how on earth does it fit in 16MB when it only has the space for 8MB? Unless it does something from 0x80 onwards? (EDIT: It does! My current guess is that it uses column 9 to switch between 00-7F and 80-FF).
Current Assumptions for 3mx
This is pages 00-7F. This is all mirrored at pages 80-FF.
- 512KB: pages 00, 08, 10 and 18 are mirrors. Then the same for {01, 09, 10, 19}, {02, 0A, 12, 1A} ... {07, 0F, 17, 1F}. Nothing but static after that.
- 1MB: same as above, then repeated for {20, 28, 30, 38}, {21, 39, 31, 39} ... {27, 2F, 37, 3F}. Nothing after that.
- 2MB: only 00-1F and that's it. No mirrors, everything above is static from floating pins. (We know this for sure.)
- 4MB: 00-3F, no mirrors, everything above is static.
I could really do with some more 3mx (or Workabout mx, which is basically the same machine in a different form factor) boards and appropriately sized RAM chips to see what they do.
EPOC16
I'm currently testing with EPOC16 4.08F. However, I have a French machine with 4.14F and a Workabout mx with 4.31F. Both of these could have bug fixes that sort the issues with more than 2MB RAM.
For all I know, it might have the same issue with 1MB (2x512K), and it's some bug with running two chips on this version of EPOC16.
If anyone has a 3mx or Workabout mx with a newer version of EPOC16 (I can tell you how to work it out) then please let me know. We could use your ROM for testing.
EDisAsm
Some slight mods, but they make a difference. Rather than use one universal bank/page number, it now uses four separate variables for the four separate banks
psel0for RAM Bank 1 (addr 0x6:0000)psel1for RAM Bank 2 (addr 0x7:0000)psel2for ROM Bank 1 (addr 0x8:0000)psel3for ROM Bank 2 (addr 0x9:0000)
(N.B.: psel is Psion speak for "page select")
You can now set these individually from the command line in EDisAsm. So I can have psel0 at RAM page 08, psel1 at RAM page 19, psel2 at ROM page 9A, and psel3 at ROM page 80.
Now when using db and dw to dump bytes or words to the screen, it will auto-detect which block of memory you're in and will use the correct psel accordingly.
The implementation needs a lot of tidying under the hood, but it works much better than before.
MAME
I've worked out how to dump the RAM in MAME without having to use EDisAsm. This is handy, because serial isn't implemented yet in the 3c or 3mx machines in MAME. You need to use the MAME's debug command prompt:
save asic9ram.dmp,0:asic9:asic9_ram,1000000
Other tests are currently happening in MAME with different RAM sizes, but that's not my work. Stay tuned!
Continued thread
#Psion 3mx RAM dumps have happened.
Please correct me if I'm wrong, but this looks a lot like FAT to me.
Also of note: The block size is 512 bytes, which sounds about right for FAT12.
Continued thread
I originally thought that it was just a hardware thing - solder on another chip, job done. After all, the pads were on the board, so why wouldn't #Psion have made #EPOC16 work with 4MB RAM?
But maybe a 4MB 3mx just wasn't a priority for Psion any more. #EPOC32 and the Series 5 were in full swing by the time the 3mx was released. The two Psions were drifting apart, too - Psion's hardware business ended up refocusing on Windows CE machines.
Psion had the ramdrive working with 2MB machines since the 3a2. The code probably hadn't been touched in ages, and it might have been too much hassle to update for the returns they thought they might get.
This is all speculation, of course. But it would make sense.
Some success with the 4MB #Psion 3mx!
I've been able to write directly to a page of RAM in the upper 2MB of memory, using #EDisAsm. I modified one of the memory-dumping assembly routines to basically go in the opposite direction. It writes 16 bytes to bank 0x6000, page 0x20. Then I dumped that to a file.
It worked! There's no corruption, and I can't see it mirrored anywhere. Using this basic test, we can pretty safely say that ASIC9MX is able to address the extra RAM (like the SDK says), and that the second chip is soldered correctly.
However, this doesn't explain why #EPOC16 doesn't like it. To recap, although EPOC16 reports that it has 4MB RAM, the ramdrive (M:) is inaccessible - apps report that the "media is corrupted", and the OS says it's unformatted. Any attempt to format the ramdrive fails silently.
The current guess is that the ramdrive "driver" can't handle more than 2MB RAM. It might be just the formatting routine, but it could be the ramdrive filesystem can't handle it. However, there might be a hard limit on pointers. This could be a bigger issue: the ramdrive in EPOC16 resizes dynamically, so the ramdrive "driver" and the filesystem's pointers would need to be able to handle the bigger filesystem size.
Unfortunately, this filesystem is undocumented - Psion never expected anyone to need to fiddle with it. Fortunately, EDisAsm can dump all memory, so it would be possible to analyse it. Dump a freshly booted 2MB 3mx, add a file, dump it again, delete a file, dump it again...
If it turns out that this is the case, it might be necessary to create a custom EPOC16 ROM. This would require a few things: working out how to modify the driver (and anything else) successfully, putting together a new EPOC16 image with the be driver, and a 3mx that's been modded to take flash. Bearing in mind that no EPOC16 source has been unearthed.
In conclusion, definitely progress, but there's still a long way to go.
For my #Psion project, I want to have a clamshell case. However, there will need to be at least one, perhaps two, ribbon cables that need to go from one side to the other. My Google-Fu is failing me in trying to search for a hinge which will take the ribbon cable through without mangling it. Any ideas? I don't really know what to search for, is one problem!
Replied to Michael Horne
@recantha I had a Psion Series 5mx back in 2000. I LOVE that form-factor. To have it in a more useful implementation (RPi) would be pretty intriguing. Anxious to see more. Nice!
Some of you might vaguely remember that I have a mildly modified #Psion Series 3mx. It's got an extra 2MB RAM, bringing it to 4MB. One snag - it doesn't work.
When I last left it (a few months back), #EPOC16 couldn't see the extra 2MB RAM - the OS was saying the machine only had 2MB RAM. However, #EDisAsm (the EPOC16 disassembly/debugging/dumping tool) was able to see and dump the upper 2MB of the 4MB RAM. This means that ASIC9MX's NRAS0 and NRAS1 are clearly working, acting as chip selects. Something else was wrong.
Yesterday, I decided to revisit it. I discovered that pin D1 on the second RAM chip wasn't making contact with the pad. A quick reflow of all the pins on that chip and... a familiar error!
"Media is corrupt"
So now EPOC16 can see the second chip, but it doesn't like something about it. Last time this happened, it was because I'd put in the wrong type of RAM chip (10 rows by 10 columns, rather than 12 rows by 8 columns), so the address lines were messed up. This time I know it's the right chip, because it's identical to the first RAM chip. And the first chip is fine, because if it wasn't then the machine wouldn't boot.
I loaded EDisAsm onto an SSD and dumped the entire 4MB RAM over RS232 to see if I can see any patterns in the higher banks of memory (0x20 to 0x3F). I've also dumped the RAM from a normal 2MB 3mx to see if there are any clues.
Of course, the chip could also be faulty, causing the corruption. (I have spares.) It could be that there's another data pin not connected properly (I did re-flow all the pins and check continuity, but you never know). Alternatively, EPOC16 might just not like seeing more than 2MB RAM, even if ASIC9MX supports it, meaning it's never going to work without some software hackery.
I'm going to leave it again for now as I have $dayjob stuff to be getting on with. I don't know whether to feel encouraged or discouraged by this, but I guess it's progress of sorts.
Does anyone know if there's an app that will check for repeating patterns in a dump of memory? (I'm on Linux, but can try Windows and maybe macOS tools.) I'm trying to work out if an address line isn't working properly on a special #Psion 3mx. #AskFedi #retrocomputing
with PDA (and 
) 
Replied in thread
Continued thread
So, I'm at a crossroads. I'm contemplating:
- Plough on with #CTRAN unit tests and refactor in #ObjectPascal and #NeoVim, and the write-up
- Try rewriting a different #Psion SIBO SDK tool in #ObjectPascal and #NeoVim
- Try a new project that's been on my mind for a long time, in C but use #VSCode
I feel like I'm slowing down with CTRAN development. After all, it "works"... but it's not "right."
The write-up is just a hard slog.
Moving on to a new tool might give me some inspiration on how to improve CTRAN. But I don't want to leave a trail of mostly-finished projects in my wake.
The C project is a bit special to me. It's also something people might actually use - unusual for one of my projects! It's for Psion #EPOC16 and would enable a huge number of old games to run on the Series 3a/c/mx.
I was hoping to use NeoVim, but with clangd being awkward, I'd have to use VS Code.