I'm fairly sure they've got one with Chris Curry too, but I can't spot it just now.
"I saw the first five minutes and had to run away, because I couldn't bear to see myself portrayed by Martin Freeman" -- Chris Curry
I can at least say that in the meantime, RISC OS is still alive and now open, available from https://www.riscosopen.org/, and most people will know the ARM company and its architectures went from strength to strength, even if the RISC PC faded away.
ArcEm is a decent emulator for the Archimedes series, and RPCem is the equivalent for the RiscPC which succeeded it. OS ROM images are available from a variety of places.
For floppy disk emulation, ADFFS is what you are looking for, and some games have been released in this format with the consent of the copyright holders.
They came up with a rather ingenious solution - a compiler from VAX assembly to Alpha. And that was carried forward into the Itanium and now x86-64 ports, so even latest OpenVMS for x86-64 still contains some VAX assembly code, but it is compiled into LLVM IR and then the LLVM backend converts it to x86-64 ELF binaries.
No reason in principle why someone could not do the same thing with the 32-bit ARM assembly code in RISC OS. Likely would be easier than rewriting it all in a high-level language
IIRC as part of their testing they set it up so it would ingest, recompile and output code for the same architecture, and found that it could produce speed improvements due to context awareness.
I've used neither.
VEST wasn’t actually a VM per se, it was a static binary translator - read in an OpenVMS VAX executable, write out an OpenVMS Alpha executable. VEST was only ever available for Alpha, but HP then created AEST which could do the same thing to translate Alpha executables to Itanium-and you could use VEST then AEST in sequence to port a VAX executable to Itanium.
However, VSI have said they have no plans to create an “IEST” to port Itanium executables to x86-64. I believe they face two big difficulties: (a) Itanium is a very complex and non-traditional architecture which makes binary translating it more of a challenge than it would be for a more mainstream architecture (b) legal risk due to aspects of it being covered by Intel patents (and unclear if Intel would license those patents on terms which would make an “IEST” commercially viable)
See Tandem Systems Review, Volume 8 Number 1 - Spring 1992
The RISC OS folks are well aware of the issue.
There are discussions about what to do underway.
One idea that I sort of like is a tiny sort of hypervisor in Arm64 code, that runs an Arm32 "VM". Then RISC OS executes in the VM.
It's not fully native, no, but with the speeds involved, it would be usable.
There is a lot of prior art for this approach:
1. RISC OS already faced a 24-bit to 32-bit migration, and one bit of the legacy of that is an emulator for running 24-bit RISC OS apps on 32-bit RISC OS, called Aemulor.
https://en.wikipedia.org/wiki/Aemulor
2. There is of course a whole industry running x86 PC emulators on x86 PCs. The one that started it is called VMware and it did quite well.
But others copied it: e.g. Connectix ported VirtualPC from Classic PowerPC MacOS to Windows. I interviewed the company's founder and chief scientist Jonathan Garber.
https://en.wikipedia.org/wiki/Webcam#Early_development_(earl...
At that time, x86 didn't do hardware virtualisation. So, VMware just used a software emulation for ring 0 code. Garber told me that once he saw how VMware did it, he realised Connectix could do that, too. He then told that it was much easier than running x86 code on PowerPC. With a grin he said that it was not only easier, the performance was excellent: the instruction sets were a _really_ close match. ;-) So the emulator was very nearly achieving 1:1 code density: one instruction for one emulated operation.
3. When Apple moved Classic MacOS from 680x0 to PowerPC, it did it using a tiny "nanokernel" containing a 68K-to-POWER ISA emulator.
1k of RAM, 512 bytes of ROM, a seven segment calculator display and hex keyboard.
I spent hours hand assembling 6502 code for it. I even created a stack based language for it in an attempt to teach my younger brother how to program.
https://theoddys.com/acorn/replica_boards/replica_boards.htm...
"to rch" reminds me of the "x goes to 0" meme: https://stackoverflow.com/questions/1642028/what-is-the-oper...
The marginalia search engine is very good at finding this kind of site, btw.
When you entered a line of their BASIC, it would check the line for errors. At one point, I kept getting error XX (I don't recall the actual number) and couldn't see the error in my code. Eventually figured out it meant I was out of RAM. There was only 2K and I think the 6502 took some and the screen too so there was only about 500 bytes left over. What a joy it was after I saved up for the 6K upgrade.
And then there was the local computer club presentation that ruined any chance of a public speaking career.... :)
The Atom also brought together a community of hardware and software enthusiasts through Atom Computer Clubs. These clubs were doing amazing things, including the development of Z80 co-processors and even running CP/M. While Acorn moved on from the Atom to the BBC Microcomputer, the clubs kept the Atom alive well beyond its prime.
It’s fascinating to look back and realize that the same team behind the Atom went on to create the ARM processor, which, interestingly, shares a striking similarity in its instruction set with the 6502.
All the wiki mentions is optimized memory usage.
Sophie Wilson, chief architect of ARM and more recently of the Broadcom FirePath October, 2001
Primarily the 6502. I learned about pipelines from it (by comparison with the 6800) and its designers were clear believers in the KISS principle. Plus the syntax of its assembler and general accessibility of it from the machine code perspective. I can still write in hex for it - things like A9 (LDA #) are tattoed on the inside of my skull. The assembly language syntax (but obviously not the mnemonics or the way you write code) and general feel of things are inspirations for ARM's assembly language and also for FirePath's. I'd hesitate to say that the actual design of the 6502 inspired anything in particular - both ARM and FirePath come from that mysterious ideas pool which we can't really define (its hard to believe that ARM was designed just from using the 6502, 16032 and reading the original Berkeley RISC I paper - ARM seems to have not much in common with any of them!). And clearly the 6502's follow-up, the 65816, wasn't "clean" any more, so whichever of Mensch and Moore contributed what to the 6502, Mensch by himself was a bit at sea.
Biggest object lesson was, however, National Semiconductor's 32016 (aka 16032): this showed how to completely make a mess of things. The 32016 first exposed the value of memory bandwidth to Steve Furber and I, showed how making things over-complex led to exceedingly long implementation times with loads of bugs in the implementation, and showed that however hard you tried to approach what compiler writers claimed they wanted, you couldn't satisfy them (no, I never did use a VAX). And an 8MHz 32016 was completely trounced in performance terms by a 4MHz 6502...
https://people.computing.clemson.edu/~mark/admired_designs.h...
details of the thinking process of evolving from 6502 to ARM in this interview.
And, yes, striking similarity is not the best way to say it.
https://www.quora.com/Is-ARM-RISC-derived-or-inspired-by-the...
A lot of the instruction names are the same, but the apparent similarity becomes less once your start using them. Using the same names was probably very convenient given that Acorn's previous computers used the 6502, and it would have helped the programmers who need to transition.
But the machine was quite different to program, and the Arm made more innovations than just being a 6502 with more registers. Every instruction being potentially conditional, and every instruction being able to make use of the barrel shifter, were both quite radical at the time and contributed a lot to the density of code in those machines (although they are inconvenient to out-of-order microarchitectures, so have been dropped from V8)
Later on in life, end of 90s, I was re-wiring the building of my students union, with a friend. Many amps main board, 380 volts, 40 circuits or so, kind of big install. We had to create plans and supply them to get approval from the city or the utility company or the architect or such. For this we used the Archimedes of some guy that helped us. At this point the Archimedes definitely was dead as a platform, Windows 98 was just out. But it was still possible to use it to create drawings and schematics and quite capable.
I could never afford a BBC Micro when that came out and certainly not the Archimedes but I always admired from afar.
It was great, but I soon got hold of a second hand BBC B a couple of years later, and then I was sold.
I eventually got an Archimedes 440 that I used for many years.
I like that all the sites linked in the banner, no longer exist! https://www.mcmordie.co.uk/public/apeople.shtml
The all-in-one Archimedes were the 3xxx series: A3000, 3010, 3020.
https://chrisacorns.computinghistory.org.uk/Computers/A3000....
https://chrisacorns.computinghistory.org.uk/Computers/A3010....
https://chrisacorns.computinghistory.org.uk/Computers/A3020....
That would have been a far more obvious and better fit.
The Pi 400 is based on the Pi 4, so 4000 would have fit, but the A4000 was a classic 3-box design with a SoC:
https://chrisacorns.computinghistory.org.uk/Computers/A4000....
One landmark buried in there was the ARM 250 chip based machines.
I think they were some of the first system on a chip desktop computers.
They lacked the glamour of the Arm 3 based machines launched around the same time but really they were ground breaking.
ARM250 datasheet here: https://home.marutan.net/arcemdocs/ARM250.pdf
For Acorn, this chip really helped to bring costs down for the A30x0/A4000 machines - the Electron of the Archimedes era. The RiscPC equivalent was the A7000/A7000+ with the ARM7500/ARM7500FE, the FE being novel for the inclusion of the FPU which ARMs had traditionally not included.
I always wanted an FPU for my RiscPC, do you know how much difference they made day to day?
StrongARM with an FPU would have been incredible, however no FPU option exists for the RiscPC. There was a commercial software package that would allow the FP capabilities of the 486/586 copro to be used from RISC OS, but I'm not sure how effective it was.
I leave someone with better knowledge to tell that one but it's a pretty sad story.
https://www.youtube.com/watch?v=Hf67JYkUCHQ
Really a neat design.
Somewhere in my parents attic is my RISC PC 600 and 486 Co-Processor card. Not sure if they also have the A3000 we had before that.
Rechargeable AA batteries in a battery holder are a sensible replacement.
If the hard drive has packed in then a SD to IDE/PATA adapter is available.