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
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
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.
That sounds like HP's Dynamo.
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.