My 2ps worth .: Would it not be a more sensible plan to “port” RISC OS to QEmu, rather than trying to emulate things we don’t really need to?
It would probably mean changes to both RO and QEmu but certainly seems to be less effort than trying to develop an emulator for a quarter-century old computer to do something it wasn’t designed to do. My personal feeling is risc os 5 for IOMD platforms needs to retire. It’s only around for the emulators, and versions up to the current one and I suspect a few beyond will still work on it anyway. The RiscPC was a great system, but things have moved on now. Trying to target an OS to run on it seems to make little sense. Cheers Chris Sent from my iPhone > On 25 Aug 2021, at 14:21, Theo Markettos <t...@markettos.org.uk> wrote: > > On Wed, Aug 25, 2021 at 08:06:05AM +0000, Sarah wrote: >>> On Wednesday, 25 August 2021, 08:56:07 BST, David Feugey >>> <dfeu...@ascinfo.fr> wrote: >>> The other way would be also to correct Qemu to provide a better Raspberry >>> Pi emulation. >> >> This is by far the correct option. Apply the fix where the bug is - if RO >> is running correctly on a real Pi, then bugs need fixing in QEMU's Pi >> emulation. I'm sure the QEMU maintainers would be very happy for any >> patches to improve things on their end. > > The raspi2 emulation in QEMU is not a full emulation - it emulates just > about enough to get Linux going. The reason is that the Pi is not just > hardware - a large part of the platform is the GPU firmware providing > services to the ARM-side OS (through mailboxes). These services have > evolved over time - the firmware is part of the SD card image, so you have > to synchronise your OS with the API provided by your firmware. > > While it is possible to extend QEMU to implement more firmware services, > it's a perpetual game of catchup and you risk affecting your ability to boot > older/newer Linux/BSD/etc images. > > RISC OS currently uses some undocumented firmware interfaces - the > particular one I found is easy to change in RISC OS to use a documented > interface which is hopefully more stable. > > Further down the line it is arguable whether RISC OS should be modified to > be less tightly fitted to Pi-specific peculiarities, or QEMU modified to > implement more Pi peculiarities. > > These are not bugs, but more questions about emulation philosophy. They are > also ones of development process - how easy is it to get updates into RISC > OS or QEMU, how long do they take until they trickle through to the places > people install them from, how to test it doesn't cause breakage with other > OSes QEMU might boot. IMHO I view the RISC OS development process as > relatively lightweight, whereas upstreaming patches into QEMU and > distributions potentially less so. > > More generally, better performance can be achieved by the emulation > departing from exactly modelling the hardware - emulating every single > register in a complicated I/O chip is a lot more work than an interface like > HostFS where you slim it down to just what you need. So it may be something > 'good enough' to boot RISC OS is better than a perfect emulation. > > Theo > > _______________________________________________ > RPCEmu mailing list > RPCEmu@riscos.info > http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu _______________________________________________ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
