Recent searches
Search options
#psion
0 posts0 participants0 posts today
Prepare to have your mind blown as we dig into the new D&D Psion class that's just been released in the latest Unearthed Arcana Playtest. https://dungeonsanddragonsfan.com/new-dnd-psion-class/ #dnd #dnd5e #dnd2024 #dungeonsanddragons #dungeonsanddragons5e #dungeonmaster #psionics #psion #wizardsofthecoast #wotc #dndbeyond #UnearthedArcana #ttrpg #TTRPGCommunity
Replied in thread
Continued thread
Boom! If I can find a working PCMCIA wireless card, I'll be on SDF from the comfort of 2002.
https://www.hpcfactor.com/forums/forums/thread-view.asp?tid=12981&start=1
www.hpcfactor.comSSH - Windows CE 4.x .net - hpcfactor.com
What? Ancient, underpowered, unsupported portables? Oh God yes. #retrocomputing #netbooks #psion #wince
Continued thread
Had dog on lap problem last night when I got home. Well, not a problem, exactly, but it's hard to do anything else when Roxy decides she wants my undivided attention! Pics of #Psion fit tonight I hope!
Test fitted the lower half of my #Psion Pi project last night. It did not go well! Photos later. Suffice to say, might have to go back to the drawing board. Sigh 
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.
Mini-rant ahead:
I'm delving into #cmake to try to make it build a compile_commands.json file to work with #retrocomputing C header files, specifically the #Psion SIBO C SDK (from the early 90s).
I don't actually want cmake to do anything but tell clangd what to do, so that I've got a working language server in NeoVim.
I don't need it to build any Makefiles, I don't need it to tell a compiler what to do. I just want clangd to treat my old 16-bit real mode code correctly, and that the header files are in ~/dosbox/sibo-c/SIBOSDK/include/.
Note that I can't point it at the compiler, because the compiler (TopSpeed) runs in DOSBox. There is no modern compiler that will work.
So... Do I have to fake it somehow? For example, do I have to tell cmake that it's actually using a different compiler (e.g. #Watcom) to make it behave correctly?
I've been wondering which games might work well ported to EPOC16 or EPOC32.
I have now got it in my head to go through every copy of Your Sinclair, Sinclair User and Amstrad Action, find suitable games, find their authors, ask if they still have the source, and finally convert the Z80 code to 8086 and the SIBO C SDK.
This is obviously a ridiculous and probably terrible idea. But I'm still tempted.
I've released version 0.3.7 of my WIP #Psion Agenda-like app "Pygenda" targeting keyboard-equipped PDAs running Linux (#GeminiPDA, #CosmoCommunicator, #PinePhone + keyboard, #PocketReform, F(x)tec #Pro1X).
The last two releases have been bug-fix releases (two releases because minutes after 0.3.6, I noticed an API change in a dependency was causing a crash & rushed out a fix). Hopefully it's in a good state for testing now.
Docs & source: https://github.com/semiprime/pygenda
GitHubGitHub - semiprime/pygenda: An agenda application inspired by Agenda programs on Psion PDAs, written in Python/GTK. Targeting Planet Computers' Gemini PDA and Cosmo Communicator (running Linux) in particular, but should work on similar devices (after providing a user CSS file to set font sizes etc.).An agenda application inspired by Agenda programs on Psion PDAs, written in Python/GTK. Targeting Planet Computers' Gemini PDA and Cosmo Communicator (running Linux) in particular, but should w...
Someone asked me some questions on the #Psion Series 3, so I thought I'd post my response here in case anyone else is interested. #LongRead
Emulator
You've got two options. The first is the original "emulators" written by Psion, S3AEMUL.EXE and S3CEMUL.EXE. They both run in DOS and emulate the 3a and 3c. But they're less of an emulator than a runtime environment for #EPOC16 (the OS). There's good and bad to this. You can run S3AEMUL and S3CEMUL straight in #DOSBox and it will talk to your host OS's filesystem (Windows, Linux, macOS, whatever). You need to map an M: drive in DOSBox for the internal storage, but once that's done you can copy files straight into that folder on your host OS. The downside is that it's not true hardware emulation. You won't get a good judge of the speed of a real device, and some syscalls aren't implements so will fail or crash the #emulator. They're bundled with the SDK (see below).
The alternative is #MAME. This is the closest to proper hardware emulation you're going to find. You can either dump your own ROMs using a tool called #EDisAsm, or you can find them in the usual MAME ROM repos. The one thing that is notably missing is RS232 emulation from the later models, because we haven't been able to find any documentation on the silicon, but it's working fine with the 3a.
Toolchain
At the moment you have only one option - the Psion SIBO C SDK with the #TopSpeed C Compiler. You're going to need DOSBox (I personally prefer DOSBox Staging). It's all available on the Internet Archive in one easy download, including all the documentation you will need.
https://archive.org/details/psion-sibo-c-sdk
From there, you have a few libraries you can use. There CLIB, which is a pure ANSI C implementation, designed to easily port apps - don't use it, it's slow and you'll be missing a lot of features. Then there's PLIB, which is Psion's C dialect - very nice to use, and you can put together a C app pretty quickly. Finally, there's OLIB, which is Psion's proprietary OO C - it feels very clunky, but once you get over that it can be very powerful.
EPOC16 apps are restricted to a very pure version of the small memory model, but you can split code up into libraries known as DYLs.
In the past I've written code using VS Code, which can be made to play nicely with the SDK's header files. I've not got it working with NeoVim and clangd yet, but it should be possible with cmake.
The SDK comes with a debugger (SDBG.EXE), a DOS GUI app. If you run SDBG.EXE in DOSBox Staging, run the Psion3a MAME emulation, and enable RS232 over TCP on both, you can use SDBG to send apps to MAME. If you enable symbols, you can step through the code. It's rudimentary by modern standards, but it works pretty well.
I say "at the moment" because I'm slowly rewriting the tools in the SDK. I already have a new working version of #CTRAN, the preprocessor for Psion OO C, but I'm a long way from a compiler. There have been efforts to coax gcc into compiling for SIBO/EPOC16, but I think they have stalled for now.
If you want some examples of EPOC16 C and OO C code, take a look at these:
https://github.com/thelastpsion/edisasm
https://github.com/thelastpsion/pyramid
https://github.com/thelastpsion/nfsc
https://github.com/nickmat/Psion3-Wari
https://github.com/nickmat/Psion3-Vector
Device
The 3mx is the best choice. It's significantly faster than the earlier models (27.6 MHz vs 7.6 MHz), has a switchable backlight, the fastest RS232 and the best version of EPOC16. I "daily drive" one for journalling, adventure games, and a few other small tasks. After that I'd say the 3c (beware - they were covered in soft-touch rubber, so will need cleaning) and the 2MB 3a. The latter is the most common. Most 3c units came with a backlight, except for the early UK ones. The 3a doesn't. Arguably the non-backlit screens have better contrast so you don't need the backlight so much in lower light, but the backlight has obvious benefits.
Internet ArchivePsion SIBO C SDK and HDK for EPOC16 : Psion : Free Download, Borrow, and Streaming : Internet ArchiveThis is all you need to get started with developing software (and hardware!) for Psion's SIBO range of portable and handheld computers.It includes:A pre-built...
A page on recreating the monitor flex cable for the Psion 5mx http://bs0dd.net/index.php?lang=eng&page=news/main&npage=11 #psion, #handheld #retrocomputing
Replied in thread
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.
Got a new toy! A #Psion HC120 corporate/industrial handheld. The HC range was the precursor to the Workabout range.
