In message <5962aaafabspam...@argonet.co.uk> you wrote: > In article <59628c2362spam...@argonet.co.uk>, > Stuart <spam...@argonet.co.uk> wrote: >> In article <20210827110113.gn31...@chiark.greenend.org.uk>, >> Theo Markettos <t...@markettos.org.uk> wrote:
>>> Agreed, but the 'virt' platform would require the timer modernisation >>> above. I'd suggest it's better to invest in that kind of modernisation >>> rather the improving a specific implementation of a specific emulator. >> So perhaps it would be better if David Feugey invested his time and money >> on something useful like this rather than going off at a tangent and >> "doing his own thing" > dfeu...@ascinfo.fr > Wrote: > I have the sensation not to be the owner of my time and my money any more. > Did I force you to adopt my own view? Stuart, that's very kind of you to post here a private message. FYI, GDPR exists also in UK. See ICO website. Thanks! Anyway, I was certainly wrong to feed the anger where it's not really your fault after all. Sorry for that. I'm just a bit fed up repeating myself every time some accuses me of things I did not say (I suspect there is some confusion with someone else messages and/or a PM organized flamewar). Just in case someone did not yet see my previous messages: 1/ Native RISC OS Linux port using QEMU for hardware layer already exists: it's RISC OS on Linux (made by Timothy Baldwin). Nota: perhaps some ideas can be taken here for point 2. But it's off topic on a RPCEmu mailing list. 2/ A way to make RISC OS working under QEMU as a full VM would be cool. As I told earlier, I like the idea. In fact, one in France made a QEMU patch a few years ago for RISC OS support. The patch did not raise any interest on the QEMU side. I think it's normal: the problem would be better be solved on the RISC OS side. Nota: the RPCEmu ARM emulation was much faster than the QEMU one at this time (and is perhaps still). All of this is also off topic on a RPCEmu mailing list. 3/ Back to topic - IMHO, QEMU will never have integration features as hostfs. This project is not made for this, at all. RPCemu does have some (hostfs, mouse integration, transparent networking). So I did suggest we could have more: printer integration, working 'reduced cpu mode', better memory map or graphics... or perhaps simply a way (api, example, tools) to make our own integrations (as in VirtualRPC). And if some integrations proved to be difficult to support under RISC OS 4 guests, I'm not against to see them supporting only RISC OS 5 guests. I said in my first message I like this idea, and if someone wants to make the job, I could even pay some money for this (not all, as it's a personal wish). I will also support work for a better RPCEmu RISC OS port. That's all. I did not force anyone to do this. I did not suggest to put ARMv7 support in RPCEmu. I did not suggest that RPCemu should be suitable to modern uses (even if it is, for me and my clients, but that's another story). And I did not suggest to fork the project or to destroy the spirit of RPCEmu. And I'm from the embedded electronics industry, ex CTO of a company proved to be a leader in the Linux embbeded market a few decades ago. But, all of you (I hope) perfectly know an argument of authority as 0 value. Sorry for my very bad english. I promise I will soon go back to my previous position of silent-reader. With all this drama, I'll remember the lesson: it's better not to talk :) David _______________________________________________ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
