After getting re-acquainted with the Psion MC400 (and making the machine a little more usable in 2021) I came across some online posts discussing the plausibility of creating an “MC400 Emulator” and this got me thinking… The early iteration of the EPOC16/SIBO OS in this machines is truly a marvel of engineering – squeezing a full multi-tasking GUI into 256k of ROM running on a 7.68MHz 80C86 with 256k of RAM is no mean feat. Just let that sink in for a little while… 256k of RAM – k as in kilobytes, as in 1/4 of a megabyte, as in 1/4000th of a gigabyte… a modern laptop in 2021 might have 16GB of RAM – 256k is 1/65536th of the memory! Copious use of assembler, object-oriented design and code-sharing libraries give the MC400 a solid and polished feel despite its age and limited resources. The (monochrome) GUI is simple and pleasing to work with albeit a little slow by today’s standards.
Almost all of the other Psion SIBO machines already have officially-released “emulators” (S3emul.exe, S3aEMUL.EXE etc.) that run under DOS (or dosbox 😉 ).
In much the same way as Ash Wolf’s excellent work WindEmu (that even lets you run “Series 5 in your browser” 😉 ) the first place to start when looking at emulation is often the ROM…
(Note: Thanks to the work that went into creating the Psion Series 5mx emulator above it was apparently only a small-ish (!) step to getting it running under MAME too. And of course although not actual emulation per se the WINS version of EPOC32 will run on Windows and under Wine).
The PANSHLL listing above lists only 170,096 bytes in the ROM files, where’s the other ~86k of space gone…? Obviously the ROM disk is just that – a static image of a disk/file structure, the other space is the bootstrap kernel-like code part of the OS that actually configures base hardware then loads and runs the higher layers (you’ll notice some processes that are displayed as running but their .IMG files are not present in the ROM file list, like SYS$NULL & SYS$MANG for example). To find out exactly we’ll have to look at the binary contents of the ROM chip(s) themselves. Emulators usually require a binary image of the chip contents as they usually contain machine-code instructions that bootstrap the machine before loading any filesystem images where executable programs etc. might be. So the MC400 ROM probably contains some boot code, maybe some low-level drivers (possible decryption or de-obfuscation of the binary contents?) and a separate (maybe DOS/FAT compatible) ~170k disk image of the ROM files listed above.
I have a “spare” MC400: the first one I bought most recently. It’s had a tough life though – the previous owner had left it in storage (in a shed) with a NiCad battery pack in place which has leaked and corroded some of the machine’s internals. I bought another MC400 some months later but kept the 1st one in case I ever needed any spares. I decided to tear down the “spare” and check out the ROM chips.
The MC400 ROM is realised in 2 x Intel 28F010 128k flash chips – not really surprising as these are the same chips used in the early Psion Flash SSDs. I do have the kit to read them but it means de-soldering them and I’m not sure I’m prepared to go there just yet.
Reading the EPOC16 (SIBO) SDK & HDK gives some clues to the partitioning of memory/address space and 80C86 register use: “ASIC2 is always used in 16 bit mode” – the 2 flash chips share the address bus and provide 2 x 8bits (High & Low) of data. The ROM image should contain the classic x86 bootstrap instructions in the top 16 bytes of the ROM address space.
Using the “PANSHLL” shell as an investigative tool on the MC400 lists running processes, segments and devices:
ž Psion PLC 1991 Epoc/Os V2.36F Rom V2.60F Shell V2.07F Mon/20/Sep/2021 14:18:52 Display is 640 by 400 Old psu. Bat NiCd 600 RAM SIZE: 256 Kbytes FREE SIZE: 76 kbytes $ lproc List of processes:* ----------------- SYS$NULL.$01 0200 READY SYS$MANG.$02 0CA0 SEM SYS$FSRV.$03 2780 SEM SYS$WSRV.$04 77D0 SEM SYS$WSRV.@05 77D0 SEM SYS$SHLL.$06 2A00 SEM SYS$NTFY.$07 0E10 SEM TERM.$08 3140 SEM LINK.$09 22F0 SEM SYS$NCP.$10 0EE0 SEM SYS$RFSV.$11 0A10 SEM FLMAN.$12 3590 SEM PANSHLL.$13 3D20 CURRENT SYS$CON.$14 1A50 SEM TP.$15 2980 SEM $ lseg List of segments:* ---------------- SYS$NULL.$01 0228 0020 01 SYS$MANG.$02 0248 00CA 01 SYS$FSRV.$03 0312 0278 01 SYS$WSRV.$04 058A 077D 01 SYS$SHLL.$06 0D07 02A0 01 SYS$NTFY.$07 0FA7 00E1 01 TERM.$SC 1088 0255 01 TERM.$08 12DD 0314 01 LINK.$SC 15F1 0111 01 LINK.$09 1702 022F 01 SYS$NCP.$SC 1931 0222 01 SYS$NCP.$10 1B53 00EE 01 SYS$RFSV.$11 1C41 00A1 01 FLMAN.$SC 1CE2 022A 01 FLMAN.$12 1F0C 0359 01 PANSHLL.$13 2265 03D2 01 SYS$CON.$14 2637 01A5 01 TP.$SC 27DC 0553 01 TP.$15 2D2F 0298 01 PANSHLL.$SC 2FC7 02C1 01 Total free segments = 100F $ ldev List of devices:* --------------- LDD - ALM (units=-1) LDD - PRN (units=-1) LDD - PRD (units=-1) LDD - LAY (units=-1) LDD - DBG (units=1) LDD - CON (units=-1) LDD - NCP (units=-1) LDD - HMD (units=-1) LDD - XMD (units=-1) LDD - LLC (units=-1) LDD - MAS (units=-1) LDD - MCR (units=2) LDD - PAR (units=2) LDD - TTY (units=2) LDD - SND (units=1) LDD - TIM (units=-1) LDD - TXT (units=-1) LDD - FIL (units=-1) PDD - FSY.REM PDD - FSY.LOC PDD - FSY.ROM PDD - LOC.TYM PDD - LOC.TY2 PDD - LOC.TY1 PDD - LOC.TY0 PDD - TTY.HSS PDD - TTY.UAR $
Note the VAX/VMS influence in the “
SYS$...” process naming (and hiding from ordinary users) of system processes.
TTY.HSS – is the “High Speed Serial” port – not sure if any HSS peripherals were ever released that would be supported by the MC400, the MC range brochure shows an external 3.5″ 1.44M floppy drive that looks like it might be plugged into this interface on the MC600 (DOS-version) although the MC600 is different hardware (no touchpad, extra row of Fn keys):
Nope – looks like the MC600 doesn’t have the HSS after all:
Next steps: poking around via _x86 machine code in the MC400’s internals, and/or picking up some of the SIBO-Linux project’s work/tools from Matt Gumbley’s page…