RISC OS on QEMU

It’s been a long time since QEMU was considered as a target/test platform for RISC OS.
What would happen if we would create a HAL for the QEMU 32bit ARM devices. The virt platform and possibly cortex-a15 (or similar) as a base platform.
On 32 bit ARM capable systems you could use -cpu host or the like.
My main reason for this idea is that the amount of ARM based hardware (SBC/laptop etc.) is expanding and we simply cannot keep up building a HAL for each system.
The QEMU HAL would allow to at least run RISC OS at a decent speed on those platforms. Even under WIN11 for ARM.. On x86 it would ‘automagically’ be run in a JIT.

I’m sure many here have been thinking about this but gave up because of the amount of work involved or simply not having the skills/knowledge..
If anyone here is capable, interested and has the time then please drop a reply here.

I am interested. I think that take the virt target platform and adjust it as needed. I say that bringing up riscos on it wouldn’t be that hard. I prefer the virt target before raspberry pi. My plan is to use qemu on genode to get a as small as possible emulation. I will receive the new QuartzPro from Pine64 soon. Since one of the cpus is 64bit only it would be the perfect platform for 64/32 bit experiments. The little cpu is 32 bit capable if I remember right.

@Michael: indeed. I think that a simple start could be to support serial port first. That way we get the output from the RISC OS startup. Also I think UEFI support could help a lot if we want to have early graphics output. UEFI can cater for a framebuffer and pass on the info.

I don’t think graphics will be a problem. It is after all it is emulated hw so the documentation is good. Getting riscos up to debug terminal is very easy. The virt target uses or can use GIC interrupts that we already handle.

The original 32bit versions of RISC OS Select were all run on QEmu as one of the primary targets, with the interrupt management modules targetting the original integrator machine. At that time the handling of flags was significantly poorer and there needed to be a number of patches to cater for the poor behaviour of QEmu’s emulation.

However that was the primary reason that I knew that RISC OS Pyromaniac would be able to use Unicorn (which is based on QEMu) – its ARM emulation was sufficient to run anything that RISC OS might do. And so, yes, that’s what RISC OS Pyromaniac uses for its ARM emulation.

Far from having given up, after over 3 years of continuous work, RISC OS Pyromaniac runs modules and applications sufficient to run the desktop, on Windows, Linux and macOS. It runs on local machines, and in the cloud. Its I/O facilities cover accelerated video (local, via VNC and physical hardware devices), keyboard, mouse, sound, speech synthesis, IPv4 and IPv6 networking, shared filing system, access to disc and CD images, serial port, parallel port emulation, GPIO, IIC, and RTC. Many of these are shared with the host, but can be isolated or placed into debug modes to enable easier debugging. The ability to trace instructions or blocks of instructions is provided easily through the emulation system, and the entire system can be instrumented to help diagnose problems.

In short, QEmu was considered and used long ago by myself for RISC OS development, and is used every single day in my own development and use of RISC OS Pyromaniac. It is available for all to use through the RISC OS Build service, and as a demo system at shell.riscos.online.

The entire purpose of RISC OS Pyromaniac is to make it easy to debug and to try out new things, for which it has been entirely successful.

I am fully aware of your efforts and the benefits of it. Very impressive! As you may know I have been tinkering with unicorn myself up to running basic and loading modules. I don’t want to reinvent the wheel. I want to be able to run a rom as it is. From my understanding much of RISC OS is done in your python framework, right?

My idea is and has been for a while, is to run riscos on top of a thin micro kernel. Using python for that purpose isn’t doable. But using a emulator that hooks up to IO is possible. Qemu needs some new features , essentially to expand the pass through pci functionality. I want to be able to have drivers inside the RISC OS rom, in addition to the host system.

But this is just my idea, I have no problems discussing it and change my mind. I don’t, as stated above ,want to compete with pyromaniac since I think it is perfect for the functionality you describe.

I will start working on it when my obligation with other projects is done.

Sorry for grammar errors etc , English is not my native language.

I used QEMU back in 2013/14 after Microsoft added enough extensions to emulate a Pi. I was using it during the initial development of the ARM3 JIT on ARMv5 in ADFFS and at that point it was running RO5 with everything except sound if I recall correctly.

Surely they’ve added a full Pi VM by now, so RO won’t require a dedicated HAL? Sadly I’ve not checked on their progress for many years.

Okay, i have been fiddling on Asahi Linux to see if I can trick RISC OS on ARMLinux to use qemu instead of the native 32 bit. (The M1 on Apple doesn’t run32 bit.)
So the simple short story is, yes that works.
I can’t elaborate on the whole strategy right now but it involves 2 lines of changes in a shell script.

the results are weird, to say the least.

Comparison with RiscPC SA 202MHz running RISC OS 4.02 800×600,256
(HD benchmarks are in kilobytes/sec)

MOS Utilities 5.29 (28 Apr 2021)
FileSwitch 2.88 (30 Jan 2021)
C Library 6.09 (06 Feb 2021)
FileCore 3.77 (14 Dec 2020)
SharedUnixLibrary 1.14 (05 Sep 2015) © UnixLib Developers, 2001-2015
HAL-based system (Linux HAL PSR Manipulation) tested at Tue,26 Jul 2022.05:30:17
Filing system: IXFS$.benchmark
Graphics Resoloution: 1856×1494, 16M colours

Test Benchmark
Processor – Looped instructions (cache) 6310 3%
Memory – Multiple register transfer 19372 11958%
Rectangle Copy – Graphics acceleration test 3784 1563%
Icon Plotting – 16 colour sprite with mask 15849 792%
Draw Path – Stroke narrow line 4546 291%
Draw Fill – Plot filled shape 6139 420%
Draw Render – Render draw file 9117 1006%
HD Read – Block load 8MB file 2522487 84590%
HD Write – Block save 8MB file 1273409 41874%
FS Read – Byte stream file in 183 88%
FS Write – Byte stream file out 168 87%

I can run !DOOM in 3840×2160 32bpp smooth.. this requires a bit of thinking..
that 3% is definitely wrong there.

ROMark5 in 4k (almost full screen)

RISCOSmark 2.04 (30-Dec-2015) by Richard Spencer 2003
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800×600,256
(HD benchmarks are in kilobytes/sec)

MOS Utilities 5.29 (28 Apr 2021)
FileSwitch 2.88 (30 Jan 2021)
C Library 6.09 (06 Feb 2021)
FileCore 3.77 (14 Dec 2020)
SharedUnixLibrary 1.14 (05 Sep 2015) © UnixLib Developers, 2001-2015
HAL-based system (Linux HAL PSR Manipulation) tested at Tue,26 Jul 2022.05:35:31
Filing system: IXFS$.benchmark
Graphics Resoloution: 3840×2132, 16M colours

Test Benchmark
Processor – Looped instructions (cache) 6432 3%
Memory – Multiple register transfer 19350 11944%
Rectangle Copy – Graphics acceleration test 3280 1355%
Icon Plotting – 16 colour sprite with mask 15014 750%
Draw Path – Stroke narrow line 4542 291%
Draw Fill – Plot filled shape 6148 421%
Draw Render – Render draw file 9126 1007%
HD Read – Block load 8MB file 2749592 92206%
HD Write – Block save 8MB file 1281520 42141%
FS Read – Byte stream file in 180 86%
FS Write – Byte stream file out 161 83%

not sure what’s going on here but the memory transfer thingy probably gives a better idea of the CPU performance.

Benchmark superscalar test reveals the real performance!

*superscalar
scalar: 1977.5488 MIPS
super2: 4145.152 MIPS
super3: 5804.8512 MIPS
super4: 7582.5152 MIPS
super5: 0 MIPS
order: 4046.848 MIPS
*superscalar
scalar: 1972.6336 MIPS
super2: 4148.4288 MIPS
super3: 5775.36 MIPS
super4: 7595.6224 MIPS
super5: 8847.36 MIPS
order: 4043.5712 MIPS

Compared this to ‘native 32 bit’ on an NVidia AGX:
*superscalar
scalar: 2382.2336 MIPS
super2: 5616.4352 MIPS
super3: 8247.7056 MIPS
super4: 12615.68 MIPS
super5: 14458.88 MIPS
order: 5482.0864 MIPS

and we can see that it performs really well.
The AGX runs at 2.2GHz so we can sort-of say that with qemu it runs at around 1.8GHz which is a RPI4.

Surely they’ve added a full Pi VM by now, so RO won’t require a dedicated HAL? Sadly I’ve not checked on their progress for many years.

The reason why I choose the virt target is that it can grow. The rpi targets are static. But I am open for ideas!

and we can see that it performs really well.

The RISC OS on Linux effort is amazing and if you can live with Linux it is the best choice.

Technically the RISC OS on Linux effort turns RISC OS into a single application. To work properly a small patch is done for qemu by Timothy Baldwin. (for RISC OS itself he did an enormous effort making changes to many parts and add a HAL that supports all that)

The patch is here: https://github.com/TimothyEBaldwin/RISC_OS_Linux_Source/blob/Linux2/Unix/LinuxSupport/qemu_swi.diff

He designed it so you can run RISC OS on any Linux platform. This prompted me to think that I just needed the build scripts to understand that the M1 requires qemu.
To be honest, I already had a full build on my NVidia AGX so i didn’t bother to rebuild everything, just the qemu-arm executable.
The start scripts use bwrap to start RISC OS and now i changed that to start qemu-arm instead. That’s all.

In priciple the qemu-arm binary can be compiled for just about any platform (probably including Android) and requires the front-end application to have a graphics screen, mouse keyboard etc.

Don’t mix up the system emulator with the user mode one.

It uses the user mode version, not the system emulator.

I think it should be possible to create some micro linux distribution that will run everything inside a qemu-system-arm. i.i.r.c. SDL has the capability to run on the framebuffer device and thus not require X at all.

I would say using X11/Wayland is better since it usually hw accelerated.

X11/Wayland inside a qemu-system-arm probably will not be hardware accellerated.
On top of that the front-end app will ony be doing block transfers and cpu based color conversions. So no major benefit from hardware acceleration until RISC OS is going to have OpenGL or other desktop..
(typing this from !NetSurf on RISC OS inside a window on the M1 machine ;-) )
X3840 Y2132 C16M EX0 EY0 F50 looks really great! like 1920×1080 but with such crisp fonts!

It depends. X11/Wayland is not inside the emulator it is the base for emulator display. If used clever you can have accelerated rects drawing etc. I don’t know how sdl does draw. Best bet is to write a display driver without sdl.

For what it’s worth I tried to boot on the Pi QEMU emulation about a year ago. After spending some quality time in QEMU’s gdb, I ran into a couple of issues:

1. RISC OS’ HAL uses an undocumented firmware USB power control interface the QEMU Pi implementation doesn’t support. Straightforward to work around since we don’t care about power control on QEMU
2. The HAL uses a firmware timer interface that’s similar to the original IOMD timers, which QEMU doesn’t implement. A better way to do this is via the ARM generic timers but that needs substantial work on the core RISC OS timers – not sure if any progress has happened there.

They wouldn’t be hard to work around by patching QEMU, but then everyone would have to build your patched version rather than just get it from their package manager.

Better would be a HAL that uses VirtIO and a generic platform model, so will boot without having to pretend to be specific hardware. Although there might still be some unexpected snags there. It would also help if RISC OS supported device tree, so it could discover the hardware it had available, which might change from one boot to another of an emulator.

@Theo: did you manage to run RISC OS on QEMU with patches for QEMU?

I would not mind using a patched QEMU if that is the way to test for now.
RISC OS on ARM64 Linux runs on a patched QEMU already so not much of a difference there.

I didn’t try patching QEMU: the general philosophy being it’s easier to upstream patches in RISC OS than it is in QEMU, particularly for things which are really deficiencies in RISC OS rather than omissions from the QEMU emulation. I’m thinking of platforms like MacOS and iOS, where there’s already a packaged QEMU (an app called UTM), and it would be a nicer UX to have people just download the app and boot a RISC OS image than have them compile their own patched QEMU. In particular you don’t have to jump through the ‘developer’ notarisation hoops, you can just download and install UTM.

While #2 above is perhaps something QEMU should implement and could perhaps be upstreamed, #1 is just RISC OS being peculiar, so arguably both should be patched. (I have a patch for #1 somewhere, but it needs thoroughly testing to ensure it doesn’t break real Pis, and I ran out of time to do that).

Without a working timer implementation RISC OS got no further, so I couldn’t say if these were the only blockers. Probably not, I would guess.

Was a nice idea. Probably not feasible in any way but hey, a man can dream..

Fixing timers should be quite easy. The way it is done in recent roms is the soc timers.

There are good docs on the generic timers so I can’t see why we couldn’t use it.

Fixing timers should be quite easy. The way it is done in recent roms is the soc timers.
There are good docs on the generic timers so I can’t see why we couldn’t use it.

The way Jeffrey proposed was to rework RISC OS to have a better timer interface. That work seems to have stalled, and SoC timers are something QEMU doesn’t seem to implement because it supports lots of different SoC and doesn’t want to have a different timer implementation for each. So the backup plan would be to use the ARM generic timers in a HAL module – I think you could make something that presents the kind of ‘countdown and interrupt when zero’ timer that RISC OS is expecting (I’m not sure if the timebase changes with CPU frequency – would need to workaround if so). I don’t think it’s hard, just that nobody has done it and tested it (and I ran out of time to work on anything here).