Re: [Rpcemu] RPCEmu licence and other topics
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 wrote: > > On Wed, Aug 25, 2021 at 08:06:05AM +, Sarah wrote: >>> On Wednesday, 25 August 2021, 08:56:07 BST, David Feugey >>> 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
Re: [Rpcemu] RPCEmu licence and other topics
On Wed, Aug 25, 2021 at 08:06:05AM +, Sarah wrote: > On Wednesday, 25 August 2021, 08:56:07 BST, David Feugey > 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
Re: [Rpcemu] RPCEmu licence and other topics
>On Wednesday, 25 August 2021, 11:26:34 BST, David Feugey >wrote: >In message <420245557.616812.1629881383...@mail.yahoo.com> > Sarah wrote: > >> On Wednesday, 25 August 2021, 09:35:54 BST, David Feugey >> wrote: > >>>Do you feel better? > >> And you were calling me rude! > >What should I say: thanks to insult me? You could have tried to engage with my points. Sad thing is, I was actually trying to help you, to move away from the idea of ruining RPCemu by trying to bolt the last 30 years of computer development onto it (against the will of the developers I might add), and towards the vastly more practical idea of using QEMU to emulate something that doesn't date back to the Major years. I might even have been willing to do some of the work to aid this. Instead you're intent of clinging to the past and driving away anyone who might want to help. For shame. Sarah ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
In message <1935553908.591453.1629878765...@mail.yahoo.com> Sarah wrote: > On Wednesday, 25 August 2021, 08:56:07 BST, David Feugey > 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. Absolutely. ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
In message <420245557.616812.1629881383...@mail.yahoo.com> Sarah wrote: > On Wednesday, 25 August 2021, 09:35:54 BST, David Feugey > wrote: >>Do you feel better? > And you were calling me rude! What should I say: thanks to insult me? Let's stop here. It's really off topic. David ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Wednesday, 25 August 2021, 09:35:54 BST, David Feugey wrote: >Do you feel better? And you were calling me rude! Sarah ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Wednesday, 25 August 2021, 08:56:07 BST, David Feugey 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. Sarah ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Wednesday, 25 August 2021, 08:52:11 BST, David Feugey wrote: >In message <1304416007.566615.1629876855...@mail.yahoo.com> you wrote: >> "Mainly" has no meaning in this context. So your original statement is >> basically nonsense. Unless you think that anything that originated on a >> Linux or Linux-like system is problematic for some reason? > >https://www.merriam-webster.com/dictionary/mainly You still haven't answered why this would be a problem. >> "RISC OS community" don't have the resources to write something from >> scratch, that using QEMU might not be a better idea? > >Pfff... >How can you be so rude and intelorant? ??? This is not rude or intolerant. The RO community as of 2021 is not very large, it does not have a lot of developer resources, and writing such an emulator is a _lot_ of work. So you have to adjust for that, and using QEMU for what you want is a far more realistic option than attempting something from scratch. What part of that do you find rude or intolerant? I should remind people that RPCemu itself originated outside the RO community, and there has not been a similar development since it first released over 15 years ago. >>>I use RISC OS for my work, and make all my business (and a lot of money) >>>with it. > >> If you were making "a lot of money" with it then you wouldn't be proposing >> hijacking a free volunteer-written emulator would you? > >Hijacking what? A free volunteer-written emulator, as I said. >I remind you there is already a Phoebe model in RPCEmu. Is it a RISC PC? It is 95% a RiscPC - I should know, as I wrote the code for it. >Another one think it's a good idea: That interests me, and I can provide some >money to help him/her. You can't just encourage this purely with money! As much as the RO community thinks this is the sole required motivator. That's the point. If you want this done, and you can't pay for the work for someone to work full time (which you can't), you need to find someone who wants to do this in their spare time. And those people will most likely be driven by _interest_ and not _money_. And indeed, offering money will quite likely just put them off. Sarah ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
In message David Glover wrote: > On the understanding that I ask this question from the perspective of > ignorance... > RISC OS runs on the Raspberry Pi. Can qemu emulate a Raspberry Pi? Yes, but not exactly a way RISC OS like. That's why some suggest RISC OS 5 could be adapted to support Qemu. IMHO, that's an excellent idea. The other way would be also to correct Qemu to provide a better Raspberry Pi emulation. Both options are valid :) As RISC OS on Linux uses an unmodified QEMU for hardware emulation, I suspect the RISC OS 5 problem is in fact already solved there. David. ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
Hi Sarah, Could you please be a little less agressive; it seems out of place on this list. -- Thanks, Ralph. ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Wednesday, 25 August 2021, 08:11:11 BST, David Feugey wrote: >In message <378229865.417560.1629829850...@mail.yahoo.com> you wrote: > >> On Tuesday, 24 August 2021, 18:53:48 BST, David Feugey >> wrote: > >> In message <747934817.371552.1629823670...@mail.yahoo.com> you wrote: > > 1/ Adapt RISC OS to QEMU. Problem: since QEMU is mainly a Linux beast QEMU is cross-platform and has been for a very long time. >>> >>>I never say it's not. > >> You claimed it "is mainly a Linux beast". Which suggested that you didn't >> think it was. > >Mainly <> only "Mainly" has no meaning in this context. So your original statement is basically nonsense. Unless you think that anything that originated on a Linux or Linux-like system is problematic for some reason? >>> That's not my idea. I was more on simpler changes: a machine type with >>> some enhancements and a RISC OS 5 version to exploit them. > >> What enhancements would you be thinking of then? Updated instruction set >> is the main enhancement, RiscPC is stuck at best on a 25-year old version >> of the ARM architecture that the rest of the world moved on from a very >> very long time ago. > >Enhancements: better graphic support (more than 8 MB framebuffer). >Viewfinder like graphic acceleration. Extended memory map. Virtual USB >support, etc. > >Major enhancements: some paravirtualisation drivers, tweaked for >RPCEmu+RISCOS 5. Did you not, maybe, think that the 27 year old RiscPC architecture may be quite a poor place for these additions? That hijacking a free RiscPC emulator to bolt vast amounts of unrelated Stuff onto it in this way might be poor practice, and something that no developer would actually want to do? That a better approach would be to emulate something a _tad_ more modern, and that since you and the "RISC OS community" don't have the resources to write something from scratch, that using QEMU might not be a better idea? >>>Since I have only a 44 year old UK OS on my desk, it's important for me. >>>But I'm probably wrong :) >> >> You're not just wrong, you're absolutely barking. >I use RISC OS for my work, and make all my business (and a lot of money) with >it. If you were making "a lot of money" with it then you wouldn't be proposing hijacking a free volunteer-written emulator would you? Sarah ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Wednesday, 25 August 2021, 04:46:28 BST, David Glover wrote: > On the understanding that I ask this question from the perspective of > ignorance... > > RISC OS runs on the Raspberry Pi. Can qemu emulate a Raspberry Pi? Googling "qemu raspberry pi" seems to provide answers to your question. Did you try it? Sarah ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On the understanding that I ask this question from the perspective of ignorance... RISC OS runs on the Raspberry Pi. Can qemu emulate a Raspberry Pi? David. ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
In message <747934817.371552.1629823670...@mail.yahoo.com> you wrote: >> 1/ Adapt RISC OS to QEMU. Problem: since QEMU is mainly a Linux beast > QEMU is cross-platform and has been for a very long time. I never say it's not. >> 2/ Make RPCEMu and RISC OS 5 going closer. Would it possible to have a new >> hardware type (Pheobe II?) with more possibilities, virtual hardware more >> easy to emulate and a RISC OS version for it? > Peter did mention this in his original email. In short, the main purpose > of such a "new hardware type" would be ARMv7, which would be a vast amount > of work for what would have to be a custom RISC OS build, for "hardware" > which would not resemble any actual target hardware platforms in the > slightest. That's not my idea. I was more on simpler changes: a machine type with some enhancements and a RISC OS 5 version to exploit them. But perhaps it can be done another way (virtual podules that would propose new hardware accelerated functionalities?). Is there any documentation on how to make podules as the hostfs one and compile them for RPCEmu (without compiling the whole beast)? > Using QEMU to emulate something Pi-esque (and fixing the issues on QEMU > preventing this from working) would be a _much_ better use of everyone's > time. Perhaps, but not a _much_ better use of my money. If I propose to fund this kind of project, it's because RPCEmu can be compiled for RISC OS... I'm not so sure about QEMU. Since I have only a 44 year old UK OS on my desk, it's important for me. But I'm probably wrong :) > RPCemu is a RiscPC emulator, not an emulator of anything else - the clue's > in the name! I can see a Phoebe machine type too. > And if anyone wants to develop RISC OS in the 21st century, there is no > reason whatsoever it should be dependent on a single emulator of a 27 year > old platform. I have not a lot of problems distributing my software on this emulator of a 27 year old computer (except the famous bug my clients and I seem to be the only ones to have, but that's another story). David ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Tuesday, 24 August 2021, 18:53:48 BST, David Feugey wrote: In message <747934817.371552.1629823670...@mail.yahoo.com> you wrote: >>> 1/ Adapt RISC OS to QEMU. Problem: since QEMU is mainly a Linux beast >> QEMU is cross-platform and has been for a very long time. > >I never say it's not. You claimed it "is mainly a Linux beast". Which suggested that you didn't think it was. >>> 2/ Make RPCEMu and RISC OS 5 going closer. Would it possible to have a new >>> hardware type (Pheobe II?) with more possibilities, virtual hardware more >>> easy to emulate and a RISC OS version for it? >> Peter did mention this in his original email. In short, the main purpose >> of such a "new hardware type" would be ARMv7, which would be a vast amount >> of work for what would have to be a custom RISC OS build, for "hardware" >> which would not resemble any actual target hardware platforms in the >> slightest. > > That's not my idea. I was more on simpler changes: a machine type with > some enhancements and a RISC OS 5 version to exploit them. What enhancements would you be thinking of then? Updated instruction set is the main enhancement, RiscPC is stuck at best on a 25-year old version of the ARM architecture that the rest of the world moved on from a very very long time ago. >> Using QEMU to emulate something Pi-esque (and fixing the issues on QEMU >> preventing this from working) would be a _much_ better use of everyone's >> time. > >Perhaps, but not a _much_ better use of my money. If I propose to fund >this kind of project, it's because RPCEmu can be compiled for RISC OS... Why would you want such a thing? I also seriously doubt anyone with the interest or ability to do this would want your money. >Since I have only a 44 year old UK OS on my desk, it's important for me. >But I'm probably wrong :) You're not just wrong, you're absolutely barking. Sarah ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
In article <20210820224126.gb31...@chiark.greenend.org.uk>, Theo Markettos wrote: > FWIW I agree with most of what Peter says here. The moment you change > RPCEmu to not model the Risc PC hardware you now need a fork of the OS. > The more you graft in, the less it's a Risc PC - essentially all you are > sharing is the GUI. Just the thoughts of a vaguely interested bystander with no technical knowledge. I can understand the usefulness of being able to emulate the RPC for compatibility with old software but with Rapis so cheap I can see little point of trying to model it. I, for example, recently purchased an over-clocked Pi in a nice case with RO5 and a software bundle included, for under 100 quid. Incidentally, I find Iris, despite only being Beta, works quite well. -- Stuart Winsor Tools With A Mission sending tools across the world http://www.twam.co.uk/ ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
In message <20210823203000.ge31...@chiark.greenend.org.uk> you wrote: > On Mon, Aug 23, 2021 at 02:07:29PM +0100, A Rawnsley wrote: >> >> I just wanted to post a "thankyou" to Theo for such an excellent and >> researched email. Really appreciated. > Hi Andrew, > Some further thoughts below... >> Personally I always felt that the evolution of a virtual system (be it >> VRPC, RPCemu or something else) into a system where you could control both >> sides of the emulation equation (the virtual hardware presented *and* the >> open source OS/HAL) offered perhaps the most interesting future direction >> for such products, but perhaps independent of their current incarnations. > I agree, there are plenty of interesting things involving putting layers > underneath RISC OS. There is even a name for this: paravirtualisation. >> Incidentally, if anyone wanted to propose a bill-of-work for any of the >> challenges Theo raises, ROD would give serious consideration to funding >> them. I do not see why complex work needs to be necessarily done for >> free. No promises, though - I am answerable to the rest of the board on >> financial commitments, and we're a democracy. > This is hard to judge because you don't know what the next issue is going to > be until you fix the previous one. But addressing the timer issue is > a step that's useful across the many platforms on which RISC OS runs. > This is Jeffrey's current state of play, where he's asking for help: > https://www.riscosopen.org/forum/forums/3/topics/11109?page=3#posts-123553 > It could be worth looking for someone to pick up that work. > Alternatively QEMU could be hacked up to bypass the issue in the short > term, at least to see what other problems lie beyond. How much it's worth > maintaining a fork of QEMU, or trying to merge changes into mainline, is up > for discussion. I think there are two ways to do this: 1/ Adapt RISC OS to QEMU. Problem: since QEMU is mainly a Linux beast and that we already have RISC OS on Linux, it could be see as some duplicate effort (at least on the ARM side). IMHO, it would be better to put the effort on RISC OS on Linux, as it's a very good way to support any ARM board. 2/ Make RPCEMu and RISC OS 5 going closer. Would it possible to have a new hardware type (Pheobe II?) with more possibilities, virtual hardware more easy to emulate and a RISC OS version for it? I would certainly invest some money on this specific project as it would give me an alternative way to distribute some of my software. It would be nice too to finish the RISC OS port of RPCEmu. For now, the keyboard does not work... but I suspect the patches made for macOS could give some clues. a JIT would be needed too (and could be useful for the Raspberry Pi OS version). I've already said I could fund part (if not all) of this project. David ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Mon, Aug 23, 2021 at 02:07:29PM +0100, A Rawnsley wrote: > > I just wanted to post a "thankyou" to Theo for such an excellent and > researched email. Really appreciated. Hi Andrew, Some further thoughts below... > Personally I always felt that the evolution of a virtual system (be it > VRPC, RPCemu or something else) into a system where you could control both > sides of the emulation equation (the virtual hardware presented *and* the > open source OS/HAL) offered perhaps the most interesting future direction > for such products, but perhaps independent of their current incarnations. I agree, there are plenty of interesting things involving putting layers underneath RISC OS. However there is an advantage being able to run things 'stock' - ie boot an image in a hypervisor/emulator/whatever without modifying the emulation environment. That means you don't have to worry about maintaining and distributing that platform, you just tell people 'download ', and it's probably already in their store/package manager. There is no reason why RISC OS can't boot in a mainstream ARM emulation environment, it's just that RISC OS has a habit of doing things its own way that have historically been tailored to the specific platforms it runs on. Which is why RPCEmu has to emulate a Risc PC, including all the limitations of that platform, and not a generic ARM system with parts taken from a standard bin. It's why we can't just swap out the CPU emulation in RPCEmu to ARMv7 and expect RISC OS to work. Other ARM platforms have largely coalesced around Device Tree, which is a way to specify what hardware a system has and so the OS can configure itself appropriately, which means you don't need to compile the OS for every single variation of the hardware. This is not something RISC OS supports - many decisions are baked in at compile time. > In thinking about this, my intention is not to belittle VRPC or RPCemu > (which both excellently fulfill the role of emulation of my favourite > Acorn machines) but rather to see how emulation could take us forwards in > interesting directions with suitable HALs etc, perhaps exposing new > technologies without the need to fully implement hardware drivers on the > RISC OS end. Particularly in light of ARM's move to 64bit exclusivity, > and RISC OS' lack of readiness for such a move. I think this could be a two-stage process: put an emulation/hypervisor layer underneath so RISC OS isn't so wedded to the physical hardware any more, and then think about what RISC OS could run on top of inside the emulator - for example that could be some kind of microkernel. This is easier to do when the microkernel doesn't need drivers for umpteen hardware platforms out there, and it avoids such a tight tie to the underlying architecture. > I must admit, I've never spent much time with qemu (beyond knowing of its > existance and purpose) because I didn't think it offered enough of a > system emulation to allow RISC OS to run, but this is probably my > ignorance, and I think perhaps the "RISC OS for Linux" guys offer > interesting approaches there. > > I was also under the impression that Qemu was a less efficient form of ARM > emulation compared to the JIT approach of RPCemu/VRPC. Is this an > incorrect assumption? (From Theo's email, it does sound like it). QEMU is a full system emulator - it emulates the CPU, memory and a huge range of peripherals across many architectures. We are using it as a system emulator to bring up OSes on new ARM silicon before it comes out of the fab, for example. The main difference in instruction emulation is that RPCEmu has a hand-coded JIT for 32- and 64-bit Intel CPUs. QEMU uses the compiler to generate fragments of code for whatever CPU it's compiled for (which is many platforms), and then stitches them together. It's difficult to compare them (would need to boot Linux on RPCEmu and run some benchmarks[1]), but elsewhere I've run QEMU emulating a 64-bit MIPS CPU and got ~500 MIPS on a ~2013 server. So I would expect emulation performance to be broadly comparable. A useful feature of QEMU is that it hooks into native KVM hypervisor support on 64-bit ARM on Linux which, assuming your CPU supports 32-bit instructions, gets you native performance. If you don't have 32-bit instructions, or are on a non-ARM platform, it has to emulate them (sadly Apple's ARM cores don't support 32 bit). ([1] If anyone has a recent-ish Linux distro available on RPCEmu I could probably run some benchmarks on various hardware to compare RPCEmu and QEMU. Russell King, the Linux/arm maintainer and original porter of Linux to the A5000, still maintains the RPC support in mainline Linux so in theory it still works, but distros supporting ARMv4 (not ARMv4T) are trickier.) The main thing you don't get with QEMU is the RISC OS integration with things like HostFS, networking and shared clipboards. Or rather, QEMU has its own implementations of those, so no work
Re: [Rpcemu] RPCEmu licence and other topics
On 20/08/2021 23:51, David Glover wrote: On Aug 20, 2021, at 8:57 AM, Peter Howkins wrote: For the avoidance of any doubt RPCEmu (and any program that uses any code from RPCEmu) will remain under the GNU General Public Licence Version 2 (or later version of the GNU General Public licence). I have nothing significant to add but I would like to say that I fully approve > of RPCEmu remaining under the GPL, I also completely agree with Peter's reply and that RPCEmu (and any derivatives) should remain under the GPL. The suggested renaming is also a bit silly. I'd imagine most of them will also fall foul of trademarks, whether for RISC OS (I'm not certain on the trademark status of RISC OS itself) or Windows/Mac trademarks. "RPCEmu+" also seems like a thinly veiled attempt to make it look like their version is in some way better than the original project, which (as Peter rightly points out) would just serve to confuse users. and that I an extremely suspicious of the > "Cloverleaf" project, which hosted a borderline scam Kickstarter promising> things that were impractical or impossible.> This now deleted Twitter thread from a few months ago was very concerning: https://david.gloveraoki.net/f/cloverleaf.png For what it's worth, there's a screenshot of the deleted tweet that's missing in that screenshot here, in which I was wished a happy troll day by Cloverleaf (and yes, I'm still blocked): https://twitter.com/acp/status/1390043478109917189 Cheers, Andy. -- Andrew Poole Email: and...@andrewpoole.org.uk Web: https://www.andrewpoole.org.uk/ ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Aug 20, 2021, at 8:57 AM, Peter Howkins wrote: > > For the avoidance of any doubt RPCEmu (and any program that uses any code > from RPCEmu) will remain under the GNU General Public Licence Version 2 (or > later version of the GNU General Public licence). I have nothing significant to add but I would like to say that I fully approve of RPCEmu remaining under the GPL, and that I an extremely suspicious of the "Cloverleaf" project, which hosted a borderline scam Kickstarter promising things that were impractical or impossible. This now deleted Twitter thread from a few months ago was very concerning: https://david.gloveraoki.net/f/cloverleaf.png David. ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Fri, Aug 20, 2021 at 04:57:22PM +0100, Peter Howkins wrote: > RPCEmu doesn't support ARMv7 and is not likely to in the future for several > technical and practical reasons. > > 1) Going from ARMv4 to ARMv7 does not offer any speed benefits when being >emulated. The more complex instructions in v7 would need roughly the same >number of host-cpu cycles to emulate as multiple simpler ARMv4 > instructions > > 2) The number of new instructions in ARMv7 vs ARMv4 is more than 500. >It is roughly 6 times the number we currently emulate (This number >includes Thumb instructions, but does not include NEON or VFP). >This is a massive job to complete. > > 3) There is no Operating System for this. There is no RISC OS available that >targets an ARMv7 CPU on top of IOMD (Risc PC) hardware. As such you'd > have >to compile up custom OSes for this hardware *or* emulate the rest of the >system of an existing platform such as the Beagleboard or the Raspberry > Pi >(this is an even larger job than updating the CPU emulation). > > 4) There is hardly any RISC OS software that actually uses ARMv7, the most >important of which is a web Browser. On an emulated system people will >use the browser on windows/linux/mac as it will run considerably faster. > > The balance of 'work' versus 'benefit' will not be reached for me. However > as > this is an open project, anyone is welcome to work on any feature that they > want to. FWIW I agree with most of what Peter says here. The moment you change RPCEmu to not model the Risc PC hardware you now need a fork of the OS. The more you graft in, the less it's a Risc PC - essentially all you are sharing is the GUI. No.4 is a bit of chicken and egg: VFP hardware floating point is worth having and supported in GCC 10, but it's not available because of the need to support ARMv3/4 (RPCEmu), v5 (Iyonix) and v6 (RPi 1 and Zero - only older VFP). It would not be infeasible to build ARMv3 and ARMv7 packages to satisfy both audiences. > RPCEmu is an emulation of a 27 year old computer, its main purpose is to > allow users to run obsolete software. Whether you consider RISC OS 3, 4, 5 > or 6 is obsolete, is left as a personal choice. +1 I did have a go at running RISC OS 5 on QEMU's raspi2 emulation and I immediately ran into some problems. QEMU provides a gdb interface which makes it relatively rapid to drill down into where things are going wrong (the main annoyance is that it can't understand RISC OS' debug symbols) A trivial problem was this one: https://www.riscosopen.org/forum/forums/3/topics/16552 - the Pi uses an undocumented power control interface that isn't implemented in QEMU and causes RISC OS to hang waiting for an answer that never comes - it's straightforward to switch to the documented interface. but more troubling is this one: https://www.riscosopen.org/forum/forums/3/topics/11109 - the RISC OS timer code uses a Pi-specific timer, which is not supported in QEMU. The Cortex cores have their own timer internally, that it would be better for RISC OS to use across all its platforms, but that requires substantial refactoring of the timer subsystem. That's a task that will have to be done sooner or later and would benefit RISC OS as a whole. It would be less work to modify QEMU, but that makes host side things much more painful (need a custom build, can't use a stock download, needs to be signed on Mac, etc etc). I think a more fruitful avenue for someone with more time than me would be to sort out some of these issues in porting RISC OS to ARMv7 QEMU, which would then make use of all the good stuff QEMU has (fast recompilers, native hypervisor support, GUIs, etc). I respect Peter et al's opinions on the direction of RPCEmu, so perhaps Stefan might think about this as an alternative direction. Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Thu, 19 Aug 2021 at 09:44, Stefan Fröhling wrote: > Hello Peter, > > I hope everything is good with you. I wanted to follow up your offer on > Twitter to provide us with an extended licence. What exactly did you have > in mind, and how can I help to make that happen? > Hello Stefan and Andrew, I do not remember offering to change the licence of RPCEmu for you, it is not possible for me to do that; 1) Changing the licence would need the agreement of every person who has contributed to RPCEmu. That is over 20 people. 2) Even if every other person agreed, I do not, so it will not be changed. For the avoidance of any doubt RPCEmu (and any program that uses any code from RPCEmu) will remain under the GNU General Public Licence Version 2 (or later version of the GNU General Public licence). > What I'd like to do is the following: > > I'd like to bundle RPCEmu with the Cloverleaf RISC OS distro for > convenience for people who want to use it for the first time, > but don't have ARM hardware available. > > With my campaign I want to find new RISC OS users so some might be > inetrested but not ready > to buy new hardware to test RISC OS. So the RPCEmu is a door-opener > for new users. > I am failing to see any advantage of this new product over the 'RPCEmu and RISC OS Direct bundle' that's already available. Could you explain why you do not support that effort? > If we're charging, we *will* be including unique/commercial software > to ensure people > get good value for money. And all the money will make with it will be > put into > promoting RISC OS and speed up it's development and provide more > applications. > > I'd like to feedback the changes we've made to the master copy > of RPCemu so that nothing gets forked. So if you have also some wishes > or suggestions for RPCEmu then let me know. > I do have some suggestions regarding your recent patch that I will send in a separate email. > I will put a link to your website in the product info, so it is > clear to everyone that RPCemu is free to use. > > Ideally, I'd like to change the name for our product because new > users (esp overseas) will not know what an "RPC" is. Also for > better marketing! > > Possibilities include: > > a) WindowsRISC OS, macRISCOS, LinuxRISCOS > b) RISCOS4Windows, RISCOS4macOS, RISCOS4Linux (4 = for; not RISC OS 4) > b) RPCEmu+ (if you feel we should retain RPCemu brand) > I do not want to change the name of RPCEmu. It has a 16 year history, is easily found via search engines and it has several thousand users that I don't want to confuse. > When you have time, it'd be good to discuss future directions for RPCemu, > and whether my programmers can assist. For example, it would be nice to > go further with RISC OS 5, and implement a virtual ARMv7 (for example) > platform. > RPCEmu doesn't support ARMv7 and is not likely to in the future for several technical and practical reasons. 1) Going from ARMv4 to ARMv7 does not offer any speed benefits when being emulated. The more complex instructions in v7 would need roughly the same number of host-cpu cycles to emulate as multiple simpler ARMv4 instructions 2) The number of new instructions in ARMv7 vs ARMv4 is more than 500. It is roughly 6 times the number we currently emulate (This number includes Thumb instructions, but does not include NEON or VFP). This is a massive job to complete. 3) There is no Operating System for this. There is no RISC OS available that targets an ARMv7 CPU on top of IOMD (Risc PC) hardware. As such you'd have to compile up custom OSes for this hardware *or* emulate the rest of the system of an existing platform such as the Beagleboard or the Raspberry Pi (this is an even larger job than updating the CPU emulation). 4) There is hardly any RISC OS software that actually uses ARMv7, the most important of which is a web Browser. On an emulated system people will use the browser on windows/linux/mac as it will run considerably faster. The balance of 'work' versus 'benefit' will not be reached for me. However as this is an open project, anyone is welcome to work on any feature that they want to. The other question I had regards RAM. My programmer said that this is > implemented as 2 memory block of 128MB. I assume this is limited by the > emulation of RPC hardware? > With regards to RAM, yes there is only a 256MB space in the Risc PC physical memory map for RAM. There is an addon card for the Risc PC (the Kinetic card) that increases this to 512MB (but with some additional limitations). Again the 'work' versus 'benefit' isn't met for me as the only program that will use that memory is a browser, and only a small number of RISC OS versions can use the Kinetic card. > Andrew notes arising: > > In your original email you said two blocks of 128 KB. I *think* > this should be MB, since RiscPC could in theory do 2x
