In article <5963c3af21Spambin@argonet.co.uk>,
Stuart <Spambin@argonet.co.uk> wrote:
> In article <596382b06djcgl@audiomisc.co.uk>,
> Jim Lesurf <jcgl@audiomisc.co.uk> wrote:
> > In article <5963378256Spambin@argonet.co.uk>, Stuart
> > <Spambin@argonet.co.uk> wrote:
> > > I don't think I've seen a "good" flamewar for years, anywhere :-)
> > You don't read usenet? 8-]
> > Jim
> Currently 11 groups including 4 Acorn specific, the old Argonet ones
> haven't seen traffic for a while.
Actually, checking !Pluto's list 25, so 13 are no longer active and there
are a further 8 to which I no longer susbscribe.
--
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
Monday, 30 August 2021
Re: [Rpcemu] Fw: RPCEmu licence and other topics
In article <5963c3af21Spambin@argonet.co.uk>, Stuart
<Spambin@argonet.co.uk> wrote:
> In article <596382b06djcgl@audiomisc.co.uk>, Jim Lesurf
> <jcgl@audiomisc.co.uk> wrote:
> > In article <5963378256Spambin@argonet.co.uk>, Stuart
> > <Spambin@argonet.co.uk> wrote:
> > > I don't think I've seen a "good" flamewar for years, anywhere :-)
> > You don't read usenet? 8-]
> > Jim
> Currently 11 groups including 4 Acorn specific, the old Argonet ones
> haven't seen traffic for a while.
Wel, it's not like the "good" old days, but you can still find some trolls
and the old tricks in places like uk.rec.audio or uk.tech.digital-tv.
JIm
--
Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<Spambin@argonet.co.uk> wrote:
> In article <596382b06djcgl@audiomisc.co.uk>, Jim Lesurf
> <jcgl@audiomisc.co.uk> wrote:
> > In article <5963378256Spambin@argonet.co.uk>, Stuart
> > <Spambin@argonet.co.uk> wrote:
> > > I don't think I've seen a "good" flamewar for years, anywhere :-)
> > You don't read usenet? 8-]
> > Jim
> Currently 11 groups including 4 Acorn specific, the old Argonet ones
> haven't seen traffic for a while.
Wel, it's not like the "good" old days, but you can still find some trolls
and the old tricks in places like uk.rec.audio or uk.tech.digital-tv.
JIm
--
Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sunday, 29 August 2021
Re: [Rpcemu] Fw: RPCEmu licence and other topics
In article <596382b06djcgl@audiomisc.co.uk>,
Jim Lesurf <jcgl@audiomisc.co.uk> wrote:
> In article <5963378256Spambin@argonet.co.uk>, Stuart
> <Spambin@argonet.co.uk> wrote:
> > I don't think I've seen a "good" flamewar for years, anywhere :-)
> You don't read usenet? 8-]
> Jim
Currently 11 groups including 4 Acorn specific, the old Argonet ones
haven't seen traffic for a while.
--
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
Jim Lesurf <jcgl@audiomisc.co.uk> wrote:
> In article <5963378256Spambin@argonet.co.uk>, Stuart
> <Spambin@argonet.co.uk> wrote:
> > I don't think I've seen a "good" flamewar for years, anywhere :-)
> You don't read usenet? 8-]
> Jim
Currently 11 groups including 4 Acorn specific, the old Argonet ones
haven't seen traffic for a while.
--
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] Fw: RPCEmu licence and other topics
In article <5963378256Spambin@argonet.co.uk>, Stuart
<Spambin@argonet.co.uk> wrote:
> I don't think I've seen a "good" flamewar for years, anywhere :-)
You don't read usenet? 8-]
Jim
--
Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<Spambin@argonet.co.uk> wrote:
> I don't think I've seen a "good" flamewar for years, anywhere :-)
You don't read usenet? 8-]
Jim
--
Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Fw: RPCEmu licence and other topics
In article <170035911.222597.1630158202650@mail.yahoo.com>, Sarah
<sarah_walker87@yahoo.co.uk> wrote:
> Theo has very helpfully clarified the situation with RO5 vs QEMU's Pi
> emulation, which had previously been somewhat garbled; if RO5 moves away
> from using undocumented firmware interfaces then it should be feasible
> to use QEMU for virtualisation, emulating what is now the most common
> hardware platform for RO, with numerous benefits over RPCemu.
I've found the discussions in this thread interesting and informative,
despite them mostly way above my 'pay grade' in terms of computer
programming, etc! However one point has drawn my attention. This is that:
If and where there are 'undocumented' interfaces, etc, then I really hope
someone who understands them *is* going to document them if they will
remain unreplaced!
One of the difficulties I faced when trying to assemble the 'ROSS' (RO
Sound System) document some years ago was tracking down details of various
aspects of the system and trying to write an *understandable* explanation
of them for others. And this was just a small part of the OS...
Jim
--
Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<sarah_walker87@yahoo.co.uk> wrote:
> Theo has very helpfully clarified the situation with RO5 vs QEMU's Pi
> emulation, which had previously been somewhat garbled; if RO5 moves away
> from using undocumented firmware interfaces then it should be feasible
> to use QEMU for virtualisation, emulating what is now the most common
> hardware platform for RO, with numerous benefits over RPCemu.
I've found the discussions in this thread interesting and informative,
despite them mostly way above my 'pay grade' in terms of computer
programming, etc! However one point has drawn my attention. This is that:
If and where there are 'undocumented' interfaces, etc, then I really hope
someone who understands them *is* going to document them if they will
remain unreplaced!
One of the difficulties I faced when trying to assemble the 'ROSS' (RO
Sound System) document some years ago was tracking down details of various
aspects of the system and trying to write an *understandable* explanation
of them for others. And this was just a small part of the OS...
Jim
--
Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Saturday, 28 August 2021
Re: [Rpcemu] Fw: RPCEmu licence and other topics
In article <9a8ab06259.ascinfo@dfeugey.riscos.fr>,
David Feugey <dfeugey@ascinfo.fr> wrote:
> Stuart, that's very kind of you to post here a private message.
> FYI, GDPR exists also in UK. See ICO website.
> Thanks!
I am well aware of that fact, I am also aware that the UK was one of the
driving forces behind it, while we were still in the EU. However, as your
message contained no claim to privacy - no "this message is only for the
recipient blah, blah", and it was a reply to a public comment, I felt no
reason not to share it in public, in my annoyance.
> 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).
Thank you for the apology, accepted, now Pax and I will go back into
"lurk" mode.
I don't think I've seen a "good" flamewar for years, anywhere :-)
--
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
David Feugey <dfeugey@ascinfo.fr> wrote:
> Stuart, that's very kind of you to post here a private message.
> FYI, GDPR exists also in UK. See ICO website.
> Thanks!
I am well aware of that fact, I am also aware that the UK was one of the
driving forces behind it, while we were still in the EU. However, as your
message contained no claim to privacy - no "this message is only for the
recipient blah, blah", and it was a reply to a public comment, I felt no
reason not to share it in public, in my annoyance.
> 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).
Thank you for the apology, accepted, now Pax and I will go back into
"lurk" mode.
I don't think I've seen a "good" flamewar for years, anywhere :-)
--
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] Fw: RPCEmu licence and other topics
On Friday, 27 August 2021, 20:54:39 BST, David Feugey <dfeugey@ascinfo.fr> wrote:
>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 think the fundamental problem we've had here, is that your requests don't really make a lot of sense. From my perspective, as a former developer of both RPCemu and RISC OS 5, the most useful change that could be made to aid with RO5 integration is implementing ARMv7; as far as I can tell, lack of ARMv7 support in RPCemu is holding back adoption of more recent architecture features in both the OS and application software, as RPCemu is still the main virtualisation solution for RO5. Dropping older architecture versions in RO would also simplify some areas of the kernel, removing the need for fallback paths only used by obsolete CPUs and easing maintenance.
However, in the very first post in this thread, Peter Howkins detailed why RPCemu would not be adding ARMv7 support, for reasons I fully agree with. Hence to me the far more sensible route to improve RO5 virtualisation is to move to a more suitable emulator; namely QEMU. Theo has very helpfully clarified the situation with RO5 vs QEMU's Pi emulation, which had previously been somewhat garbled; if RO5 moves away from using undocumented firmware interfaces then it should be feasible to use QEMU for virtualisation, emulating what is now the most common hardware platform for RO, with numerous benefits over RPCemu. There is a question over host integration features like HostFS, but in the worst case an RO integrated fork of QEMU could be created for this. If the Pi emulation proves to be inadequate then QEMU's "virt" platform would be more suitable, and provides more options for integration with eg graphics acceleration, though this would require some additional porting work on the RO side.
You seem to have completely ruled this out though, claiming you don't want ARMv7 support, but provide a list of other features. Without ARMv7 support in the primary virtualisation solution both the OS and most of the software will be held back by being forced to keep compatibility with a more than 25 year old platform. This would either split the userbase (which I'm sure most people would agree has happened quite enough already) leaving people running on virtualisation as second class citizens unable to run newer software, or it results in a situation where no-one will use any of the newer instructions, wasting a lot of potential in the modern hardware platforms. This would include rendering VFPSupport irrelevant, a project you were keen to tell me you worked on.
In addition, while I don't want to put words into the Howkins' mouths, the impression I get from them is that little to none of the work you propose would stand much of a chance of being accepted into RPCemu mainline. Therefore you would have to create and maintain a fork of RPCemu, which would (again) split the userbase and create a lot of bad feelings. You would have ended up spending a good deal of money (I did give you an estimate of what I thought this was likely to cost...) and developer time, with the result of damaging both RO5 and RPCemu for little real benefit.
So, again, why do you want this?
Sarah
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>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 think the fundamental problem we've had here, is that your requests don't really make a lot of sense. From my perspective, as a former developer of both RPCemu and RISC OS 5, the most useful change that could be made to aid with RO5 integration is implementing ARMv7; as far as I can tell, lack of ARMv7 support in RPCemu is holding back adoption of more recent architecture features in both the OS and application software, as RPCemu is still the main virtualisation solution for RO5. Dropping older architecture versions in RO would also simplify some areas of the kernel, removing the need for fallback paths only used by obsolete CPUs and easing maintenance.
However, in the very first post in this thread, Peter Howkins detailed why RPCemu would not be adding ARMv7 support, for reasons I fully agree with. Hence to me the far more sensible route to improve RO5 virtualisation is to move to a more suitable emulator; namely QEMU. Theo has very helpfully clarified the situation with RO5 vs QEMU's Pi emulation, which had previously been somewhat garbled; if RO5 moves away from using undocumented firmware interfaces then it should be feasible to use QEMU for virtualisation, emulating what is now the most common hardware platform for RO, with numerous benefits over RPCemu. There is a question over host integration features like HostFS, but in the worst case an RO integrated fork of QEMU could be created for this. If the Pi emulation proves to be inadequate then QEMU's "virt" platform would be more suitable, and provides more options for integration with eg graphics acceleration, though this would require some additional porting work on the RO side.
You seem to have completely ruled this out though, claiming you don't want ARMv7 support, but provide a list of other features. Without ARMv7 support in the primary virtualisation solution both the OS and most of the software will be held back by being forced to keep compatibility with a more than 25 year old platform. This would either split the userbase (which I'm sure most people would agree has happened quite enough already) leaving people running on virtualisation as second class citizens unable to run newer software, or it results in a situation where no-one will use any of the newer instructions, wasting a lot of potential in the modern hardware platforms. This would include rendering VFPSupport irrelevant, a project you were keen to tell me you worked on.
In addition, while I don't want to put words into the Howkins' mouths, the impression I get from them is that little to none of the work you propose would stand much of a chance of being accepted into RPCemu mainline. Therefore you would have to create and maintain a fork of RPCemu, which would (again) split the userbase and create a lot of bad feelings. You would have ended up spending a good deal of money (I did give you an estimate of what I thought this was likely to cost...) and developer time, with the result of damaging both RO5 and RPCemu for little real benefit.
So, again, why do you want this?
Sarah
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Fw: RPCEmu licence and other topics
In message <9a8ab06259.ascinfo@dfeugey.riscos.fr>
David Feugey <dfeugey@ascinfo.fr> wrote:
<snipped>
Thank you for drizzling oil upon the troubled waters of this contentious
thread.
Your English prose needs no apology. It is excellent.
> you (I hope) perfectly know an argument of authority as 0 value.
It is the prepositions that are so hard to get right. Speaking with the
authority of an English graduate I would have said "argument from" rather
than "of".
Your English needs no apology. It is excellent.
John
--
John Rickman
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
David Feugey <dfeugey@ascinfo.fr> wrote:
<snipped>
Thank you for drizzling oil upon the troubled waters of this contentious
thread.
Your English prose needs no apology. It is excellent.
> you (I hope) perfectly know an argument of authority as 0 value.
It is the prepositions that are so hard to get right. Speaking with the
authority of an English graduate I would have said "argument from" rather
than "of".
Your English needs no apology. It is excellent.
John
--
John Rickman
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Friday, 27 August 2021
Re: [Rpcemu] Fw: RPCEmu licence and other topics
In message <5962aaafabSpambin@argonet.co.uk> you wrote:
> In article <59628c2362Spambin@argonet.co.uk>,
> Stuart <Spambin@argonet.co.uk> wrote:
>> In article <20210827110113.GN31179@chiark.greenend.org.uk>,
>> Theo Markettos <theo@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"
> dfeugey@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
> In article <59628c2362Spambin@argonet.co.uk>,
> Stuart <Spambin@argonet.co.uk> wrote:
>> In article <20210827110113.GN31179@chiark.greenend.org.uk>,
>> Theo Markettos <theo@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"
> dfeugey@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
Re: [Rpcemu] Fw: RPCEmu licence and other topics
In article <59628c2362Spambin@argonet.co.uk>,
Stuart <Spambin@argonet.co.uk> wrote:
> In article <20210827110113.GN31179@chiark.greenend.org.uk>,
> Theo Markettos <theo@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"
dfeugey@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 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
Stuart <Spambin@argonet.co.uk> wrote:
> In article <20210827110113.GN31179@chiark.greenend.org.uk>,
> Theo Markettos <theo@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"
dfeugey@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 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] Fw: RPCEmu licence and other topics
In article <20210827110113.GN31179@chiark.greenend.org.uk>,
Theo Markettos <theo@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"
--
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
Theo Markettos <theo@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"
--
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] Fw: RPCEmu licence and other topics
On Thu, Aug 26, 2021 at 06:59:25AM +0000, Sarah wrote:
> On Wednesday, 25 August 2021, 23:36:53 BST, Theo Markettos <theo@markettos.org.uk> wrote:
>
> >Changing RISC OS to use the documented interface for USB power control,
> >which is the one I found, is a small change. The timer issue is a more
> >substantial roadblock, and that's a hard peripheral that QEMU doesn't
> >implement because other OSes use the ARM's own timer instead.
>
> So why is RO different to everyone else?
The timer issue is a more complicated one. Essentially RISC OS assumes
timers work just the same as they did on the Archimedes. There's one timer,
you configure it to give you an interrupt at 100Hz, job done. So what
happens when someone ports RISC OS to a new platform is they scour the
datasheet for a timer that behaves just like the one in the IOC on the
Archimedes (and RiscPC). And that's what happened on the Pi - there's a
timer that's specific to the Pi SoC.
That approach is running out of road. It made sense in a world of an
8MHz/4MIPS CPU, where you got 40,000 instructions between interrupts. Now
CPUs are 2GHz it's less good to have a 100Hz timer with 20 million
instructions between interrupts. Lots of I/O things depend on microsecond
timing, for example. Nowadays you want multiple sources of arbitrary
different time granularity too, and be able to read the timer counter
without consistency risks.
Every Arm core has a timer block as part of the core, which means it doesn't
depend on the hardware the SoC vendor decided to slap around it. So you
don't need to worry about writing a timer implementation for every single
SoC. Unfortunately the timers have changed between generations, so an ARM11
timer is different from a Cortex A53 timer, so you need a handful of drivers
for those. Also, cores are subject to powersaving - you need to adjust if
the core that is clocking the timer gets downclocked from 2GHz to 857MHz to
save power.
Linux, FreeBSD, etc have modern timer subsystems that use the Arm core's
timers, with code to implement generic timers on top of what the hardware
provides, with drivers for the various Arm cores. Therefore QEMU doesn't
implement the Pi-SoC timer because no other OS uses it - if you select the
raspi2 emulation you get a Cortex A7 CPU and its timers, if you select
raspi4 you get a Cortex A72 with timers. You can boot quite happily on a
new SoC with a Cortex A72 without any tailoring the new hardware, because
you're using generic timer (and interrupt controller and UART) drivers.
RISC OS doesn't do any of this, it just clings to the idea that a single
100Hz timer is good enough - and it isn't in this day and age.
So in this space it's not wrong to say QEMU should implement the Pi-specific
timer - it would make QEMU's implementation more complete.
But, all things being equal, instead of investing the effort in distributing
a fork of QEMU, looking at the bigger picture it could make more sense to
invest effort in modernising RISC OS' use of timers, which would make it
easier to port to new platforms and down the line improve the performance
and capability of RISC OS on all platforms. Making it less weird and work
more like other OSes, in an area that doesn't have any benefits to being
different, makes it easier to work with down the line - booting on emulators
or on new silicon.
But all things aren't equal, so it really depends on who has time and skills
and what they want to work on.
> Bending your side to meet the quirks of a current inaccurate
> implementation of something else leaves you screwed if said other side
> becomes more accurate. Which is quite likely to happen; QEMU is aiming to
> emulate a Pi, not "something like a Pi", and they are quite likely to make
> changes to bring their emulation closer to a real Pi. At which point RO
> has _more_ costs having to readjust.
In systems typically there is 'core' behaviour, that is the well trodden
path that every platform uses regularly. And then there are the depths of
the weeds, where they rarely go. RISC OS exercises unusual parts of the
weeds that others don't.
You can fix the emulator's implementation of the weeds, or you can make RISC
OS more mainstream and less surprising. In this instance I see more benefit
to modernising RISC OS to make it more mainstream (in this particular area)
than I do than in improving the weedy parts of the emulation, not that that
is a bad goal of itself.
> If you just want something for virtualisation that doesn't want to look
> like a Pi, QEMU has the 'virt' platform for that, and there's no reason RO
> couldn't port to that. Porting specifically to "the current state of the
> Pi emulation" rather than fixing the problematic elements of said Pi
> emulation is just asking for trouble.
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.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> On Wednesday, 25 August 2021, 23:36:53 BST, Theo Markettos <theo@markettos.org.uk> wrote:
>
> >Changing RISC OS to use the documented interface for USB power control,
> >which is the one I found, is a small change. The timer issue is a more
> >substantial roadblock, and that's a hard peripheral that QEMU doesn't
> >implement because other OSes use the ARM's own timer instead.
>
> So why is RO different to everyone else?
The timer issue is a more complicated one. Essentially RISC OS assumes
timers work just the same as they did on the Archimedes. There's one timer,
you configure it to give you an interrupt at 100Hz, job done. So what
happens when someone ports RISC OS to a new platform is they scour the
datasheet for a timer that behaves just like the one in the IOC on the
Archimedes (and RiscPC). And that's what happened on the Pi - there's a
timer that's specific to the Pi SoC.
That approach is running out of road. It made sense in a world of an
8MHz/4MIPS CPU, where you got 40,000 instructions between interrupts. Now
CPUs are 2GHz it's less good to have a 100Hz timer with 20 million
instructions between interrupts. Lots of I/O things depend on microsecond
timing, for example. Nowadays you want multiple sources of arbitrary
different time granularity too, and be able to read the timer counter
without consistency risks.
Every Arm core has a timer block as part of the core, which means it doesn't
depend on the hardware the SoC vendor decided to slap around it. So you
don't need to worry about writing a timer implementation for every single
SoC. Unfortunately the timers have changed between generations, so an ARM11
timer is different from a Cortex A53 timer, so you need a handful of drivers
for those. Also, cores are subject to powersaving - you need to adjust if
the core that is clocking the timer gets downclocked from 2GHz to 857MHz to
save power.
Linux, FreeBSD, etc have modern timer subsystems that use the Arm core's
timers, with code to implement generic timers on top of what the hardware
provides, with drivers for the various Arm cores. Therefore QEMU doesn't
implement the Pi-SoC timer because no other OS uses it - if you select the
raspi2 emulation you get a Cortex A7 CPU and its timers, if you select
raspi4 you get a Cortex A72 with timers. You can boot quite happily on a
new SoC with a Cortex A72 without any tailoring the new hardware, because
you're using generic timer (and interrupt controller and UART) drivers.
RISC OS doesn't do any of this, it just clings to the idea that a single
100Hz timer is good enough - and it isn't in this day and age.
So in this space it's not wrong to say QEMU should implement the Pi-specific
timer - it would make QEMU's implementation more complete.
But, all things being equal, instead of investing the effort in distributing
a fork of QEMU, looking at the bigger picture it could make more sense to
invest effort in modernising RISC OS' use of timers, which would make it
easier to port to new platforms and down the line improve the performance
and capability of RISC OS on all platforms. Making it less weird and work
more like other OSes, in an area that doesn't have any benefits to being
different, makes it easier to work with down the line - booting on emulators
or on new silicon.
But all things aren't equal, so it really depends on who has time and skills
and what they want to work on.
> Bending your side to meet the quirks of a current inaccurate
> implementation of something else leaves you screwed if said other side
> becomes more accurate. Which is quite likely to happen; QEMU is aiming to
> emulate a Pi, not "something like a Pi", and they are quite likely to make
> changes to bring their emulation closer to a real Pi. At which point RO
> has _more_ costs having to readjust.
In systems typically there is 'core' behaviour, that is the well trodden
path that every platform uses regularly. And then there are the depths of
the weeds, where they rarely go. RISC OS exercises unusual parts of the
weeds that others don't.
You can fix the emulator's implementation of the weeds, or you can make RISC
OS more mainstream and less surprising. In this instance I see more benefit
to modernising RISC OS to make it more mainstream (in this particular area)
than I do than in improving the weedy parts of the emulation, not that that
is a bad goal of itself.
> If you just want something for virtualisation that doesn't want to look
> like a Pi, QEMU has the 'virt' platform for that, and there's no reason RO
> couldn't port to that. Porting specifically to "the current state of the
> Pi emulation" rather than fixing the problematic elements of said Pi
> emulation is just asking for trouble.
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.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Thursday, 26 August 2021
[Rpcemu] Fw: RPCEmu licence and other topics
In article <20210826103430.395272135B@orac.inputplus.co.uk>,
Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> Hi Sarah,
> > Theo wrote:
> > > (This is how a lot of stuff gets developed,
> >
> > I do work in the industry, there's no need to patronise me.
> You could give Theo the benefit of the doubt: if there's no reason to
> think you work in the industry then why wouldn't he explain his
> argument? Plus it's for the benefit of *all* readers.
> He's not being patronising, you're being chippy.
As I'm also just one of the readers here, and I've known of Theo for many
years...
As someone not in the industry, whatever that industry might be? I
appreciate his thoughts on the matters in hand, as it helps me as a non
technical RISC OS enthusiast to understand some of what is being written.
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> Hi Sarah,
> > Theo wrote:
> > > (This is how a lot of stuff gets developed,
> >
> > I do work in the industry, there's no need to patronise me.
> You could give Theo the benefit of the doubt: if there's no reason to
> think you work in the industry then why wouldn't he explain his
> argument? Plus it's for the benefit of *all* readers.
> He's not being patronising, you're being chippy.
As I'm also just one of the readers here, and I've known of Theo for many
years...
As someone not in the industry, whatever that industry might be? I
appreciate his thoughts on the matters in hand, as it helps me as a non
technical RISC OS enthusiast to understand some of what is being written.
Dave
--
Dave Triffid
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Fw: RPCEmu licence and other topics
Hi Sarah,
> Theo wrote:
> > (This is how a lot of stuff gets developed,
>
> I do work in the industry, there's no need to patronise me.
You could give Theo the benefit of the doubt: if there's no reason to
think you work in the industry then why wouldn't he explain his
argument? Plus it's for the benefit of *all* readers.
He's not being patronising, you're being chippy.
--
Cheers, Ralph.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Theo wrote:
> > (This is how a lot of stuff gets developed,
>
> I do work in the industry, there's no need to patronise me.
You could give Theo the benefit of the doubt: if there's no reason to
think you work in the industry then why wouldn't he explain his
argument? Plus it's for the benefit of *all* readers.
He's not being patronising, you're being chippy.
--
Cheers, Ralph.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Fw: RPCEmu licence and other topics
On Thursday, 26 August 2021, 09:47:51 BST, David Feugey <dfeugey@ascinfo.fr> wrote:
> My point - before the drama - was more on more integration features (à la
> hostfs) - perhaps with some only for RISC OS 5 (as we have its source
> code). Things that we will never probably see on QEMU.
This is why you would fork QEMU to add the RO specific integration that wouldn't be accepted in mainline. You would then be able to keep up with QEMU developments by periodically pulling changes from the main tree. It's not difficult.
> IMHO, ARMv7 support in RPCEmu is just irrelevant.
In RPCemu, yes, since it's not a RiscPC-era thing, but for RO virtualisation you _do_ want ARMv7 so you can actually run new user software. Like, for example, anything making use of the VFPSupport module you mentioned yesterday. There is little point in having a solution that runs RO5 only to not be able to run any software that you would want to run on an RO5 solution.
Sarah
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Fw: RPCEmu licence and other topics
In message <20210825223652.GL31179@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:
>> This would give you a reasonable emulation of a more modern platform more
>> suitable for new software, and is a hell of a lot better than the idea of
>> forking RPCemu (since the relevant changes would never be mainlined) to
>> weld in ARMv7 and the like.
> I agree: RPCEmu is designed to be a fixed emulation of a fixed piece of
> hardware from a historical period. If what you want is a way to run modern
> RISC OS on modern hardware, there are other ways to go about it.
I agree completely too.
My point - before the drama - was more on more integration features (à la
hostfs) - perhaps with some only for RISC OS 5 (as we have its source
code). Things that we will never probably see on QEMU.
I have a tool to add some features to RPCEmu, a very crude way. IMHO, it
would be probably better to add a virtual podule + support functions on
the host side, but RPCEmu does not provide a plug-in functionnality. Hint:
we use TCC as side compiler for all our plug-in interfaces at work, so
people have the plug-in feature and the tool to make some very easily.
IMHO, ARMv7 support in RPCEmu is just irrelevant.
On the QEMU side: we have already RISC OS on Linux, that relies (partly)
on unpatched QEMU and permits to uses RISC OS on any Linux or ChromeOS ARM
device... at native speed. Perhaps RISC OS on Linux already solved the
problems that prevent RISC OS to work on QEMU 'the classic way'? (that's
just a question)
I remember some already managed to deploy RISC OS on Linux on AWS ARM
instances. But native RISC OS VM would be cool too :)
David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Theo Markettos <theo@markettos.org.uk> wrote:
>> This would give you a reasonable emulation of a more modern platform more
>> suitable for new software, and is a hell of a lot better than the idea of
>> forking RPCemu (since the relevant changes would never be mainlined) to
>> weld in ARMv7 and the like.
> I agree: RPCEmu is designed to be a fixed emulation of a fixed piece of
> hardware from a historical period. If what you want is a way to run modern
> RISC OS on modern hardware, there are other ways to go about it.
I agree completely too.
My point - before the drama - was more on more integration features (à la
hostfs) - perhaps with some only for RISC OS 5 (as we have its source
code). Things that we will never probably see on QEMU.
I have a tool to add some features to RPCEmu, a very crude way. IMHO, it
would be probably better to add a virtual podule + support functions on
the host side, but RPCEmu does not provide a plug-in functionnality. Hint:
we use TCC as side compiler for all our plug-in interfaces at work, so
people have the plug-in feature and the tool to make some very easily.
IMHO, ARMv7 support in RPCEmu is just irrelevant.
On the QEMU side: we have already RISC OS on Linux, that relies (partly)
on unpatched QEMU and permits to uses RISC OS on any Linux or ChromeOS ARM
device... at native speed. Perhaps RISC OS on Linux already solved the
problems that prevent RISC OS to work on QEMU 'the classic way'? (that's
just a question)
I remember some already managed to deploy RISC OS on Linux on AWS ARM
instances. But native RISC OS VM would be cool too :)
David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 25 August 2021
Re: [Rpcemu] Fw: RPCEmu licence and other topics
On Wednesday, 25 August 2021, 23:36:53 BST, Theo Markettos <theo@markettos.org.uk> wrote:
>On Wed, Aug 25, 2021 at 02:38:16PM +0000, Sarah wrote:
>> On Wednesday, 25 August 2021, 14:20:47 BST, Theo Markettos <theo@markettos.org.uk> wrote:
>>
>> >RISC OS currently uses some undocumented firmware interfaces
>>
>> Please tell me this is a joke. That code needs to come out ASAP, and
>> should never have been checked in.
>
>It's not a joke, it's because the RISC OS port and the firmware have
>co-evolved. Originally there were no documented firmware interfaces,
>because there was no documentation - there were simply emails to the
>firmware developers. Later on some bits got documented, but it turned out
>not the ones RISC OS implemented.
Well once it became clear that some of the interfaces RO was using were not going to be documented, they should have been stripped out of the codebase; that's a pretty obvious sign that there are no guarantees that those interfaces are going to stay in the FW.
>(This is how a lot of stuff gets developed,
I do work in the industry, there's no need to patronise me. I am aware this is practice, however it also happens to be _bad_ practice.
>The firmware is loaded before the OS boots, so you don't get to control what
>firmware you're running on.
Even more reason to remove the undocumented interface usage from RO. Because you have no guarantees that those interfaces aren't going to change or just simply go away.
>Changing RISC OS to use the documented interface for USB power control,
>which is the one I found, is a small change. The timer issue is a more
>substantial roadblock, and that's a hard peripheral that QEMU doesn't
>implement because other OSes use the ARM's own timer instead.
So why is RO different to everyone else?
>But I raise this as more of a philosophical point: modern systems are
>complex and change over time - they are not fixed at a point in the past
>like older hardware was.
They _are_ effectively fixed if you stick to the public documented interfaces. No SoC vendor who wants to stay in business is going to wildly change the public FW interfaces on a whim, so those can be considered reasonably stable. The same can _not_ be said for the undocumented interfaces, which is why RO using them effectively leaves the OS sitting on a timebomb.
>Particularly when you can bend both sides to meet each other, it's then a
>question of which side is easier to bend, and which incurs you the least costs.
Bending your side to meet the quirks of a current inaccurate implementation of something else leaves you screwed if said other side becomes more accurate. Which is quite likely to happen; QEMU is aiming to emulate a Pi, not "something like a Pi", and they are quite likely to make changes to bring their emulation closer to a real Pi. At which point RO has _more_ costs having to readjust.
If you just want something for virtualisation that doesn't want to look like a Pi, QEMU has the 'virt' platform for that, and there's no reason RO couldn't port to that. Porting specifically to "the current state of the Pi emulation" rather than fixing the problematic elements of said Pi emulation is just asking for trouble.
Sarah
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Fw: RPCEmu licence and other topics
On Wed, Aug 25, 2021 at 02:38:16PM +0000, Sarah wrote:
> On Wednesday, 25 August 2021, 14:20:47 BST, Theo Markettos <theo@markettos.org.uk> wrote:
>
> >RISC OS currently uses some undocumented firmware interfaces
>
> Please tell me this is a joke. That code needs to come out ASAP, and
> should never have been checked in.
It's not a joke, it's because the RISC OS port and the firmware have
co-evolved. Originally there were no documented firmware interfaces,
because there was no documentation - there were simply emails to the
firmware developers. Later on some bits got documented, but it turned out
not the ones RISC OS implemented.
(This is how a lot of stuff gets developed, when the software and hardware
teams are working together you can save a lot on documentation when you can
just go and ask, or go look at the chip design source code. Which are
things people outside the company don't have access to, but then don't need
to according to the target market)
> The best approach I can see at this point, is to fork QEMU, fix the
> firmware simulation at the FW version RO5 is using (I'm assuming the
> binary blob for this is loaded by RO; if not you've got some issues in
> general anyway), and add the convenience features like HostFS. Then
> feedback any relevant changes/fixes to mainline and let them go up
> whatever upstreaming process is in use there at their leisure.
The firmware is loaded before the OS boots, so you don't get to control what
firmware you're running on. On Pi 0-3 the GPU firmware boots first and
brings up the ARM later on; Pi 4 has more of a traditional boot process that
involve the firmware being an ARM 'BIOS' to load up the OS.
Changing RISC OS to use the documented interface for USB power control,
which is the one I found, is a small change. The timer issue is a more
substantial roadblock, and that's a hard peripheral that QEMU doesn't
implement because other OSes use the ARM's own timer instead.
But I raise this as more of a philosophical point: modern systems are
complex and change over time - they are not fixed at a point in the past
like older hardware was. Emulating them therefore may need a different
approach. Particularly when you can bend both sides to meet each other,
it's then a question of which side is easier to bend, and which incurs you
the least costs.
> This would give you a reasonable emulation of a more modern platform more
> suitable for new software, and is a hell of a lot better than the idea of
> forking RPCemu (since the relevant changes would never be mainlined) to
> weld in ARMv7 and the like.
I agree: RPCEmu is designed to be a fixed emulation of a fixed piece of
hardware from a historical period. If what you want is a way to run modern
RISC OS on modern hardware, there are other ways to go about it.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> On Wednesday, 25 August 2021, 14:20:47 BST, Theo Markettos <theo@markettos.org.uk> wrote:
>
> >RISC OS currently uses some undocumented firmware interfaces
>
> Please tell me this is a joke. That code needs to come out ASAP, and
> should never have been checked in.
It's not a joke, it's because the RISC OS port and the firmware have
co-evolved. Originally there were no documented firmware interfaces,
because there was no documentation - there were simply emails to the
firmware developers. Later on some bits got documented, but it turned out
not the ones RISC OS implemented.
(This is how a lot of stuff gets developed, when the software and hardware
teams are working together you can save a lot on documentation when you can
just go and ask, or go look at the chip design source code. Which are
things people outside the company don't have access to, but then don't need
to according to the target market)
> The best approach I can see at this point, is to fork QEMU, fix the
> firmware simulation at the FW version RO5 is using (I'm assuming the
> binary blob for this is loaded by RO; if not you've got some issues in
> general anyway), and add the convenience features like HostFS. Then
> feedback any relevant changes/fixes to mainline and let them go up
> whatever upstreaming process is in use there at their leisure.
The firmware is loaded before the OS boots, so you don't get to control what
firmware you're running on. On Pi 0-3 the GPU firmware boots first and
brings up the ARM later on; Pi 4 has more of a traditional boot process that
involve the firmware being an ARM 'BIOS' to load up the OS.
Changing RISC OS to use the documented interface for USB power control,
which is the one I found, is a small change. The timer issue is a more
substantial roadblock, and that's a hard peripheral that QEMU doesn't
implement because other OSes use the ARM's own timer instead.
But I raise this as more of a philosophical point: modern systems are
complex and change over time - they are not fixed at a point in the past
like older hardware was. Emulating them therefore may need a different
approach. Particularly when you can bend both sides to meet each other,
it's then a question of which side is easier to bend, and which incurs you
the least costs.
> This would give you a reasonable emulation of a more modern platform more
> suitable for new software, and is a hell of a lot better than the idea of
> forking RPCemu (since the relevant changes would never be mainlined) to
> weld in ARMv7 and the like.
I agree: RPCEmu is designed to be a fixed emulation of a fixed piece of
hardware from a historical period. If what you want is a way to run modern
RISC OS on modern hardware, there are other ways to go about it.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Fw: RPCEmu licence and other topics
On Wednesday, 25 August 2021, 14:20:47 BST, Theo Markettos <theo@markettos.org.uk> wrote:
>RISC OS currently uses some undocumented firmware interfaces
Please tell me this is a joke. That code needs to come out ASAP, and should never have been checked in.
> 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.
The best approach I can see at this point, is to fork QEMU, fix the firmware simulation at the FW version RO5 is using (I'm assuming the binary blob for this is loaded by RO; if not you've got some issues in general anyway), and add the convenience features like HostFS. Then feedback any relevant changes/fixes to mainline and let them go up whatever upstreaming process is in use there at their leisure.
This would give you a reasonable emulation of a more modern platform more suitable for new software, and is a hell of a lot better than the idea of forking RPCemu (since the relevant changes would never be mainlined) to weld in ARMv7 and the like.
Sarah
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
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 <theo@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 <dfeugey@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
Re: [Rpcemu] RPCEmu licence and other topics
On Wed, Aug 25, 2021 at 08:06:05AM +0000, Sarah wrote:
> On Wednesday, 25 August 2021, 08:56:07 BST, David Feugey <dfeugey@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
> On Wednesday, 25 August 2021, 08:56:07 BST, David Feugey <dfeugey@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
Re: [Rpcemu] RPCEmu licence and other topics
>On Wednesday, 25 August 2021, 11:26:34 BST, David Feugey <dfeugey@ascinfo.fr> wrote:
>In message <420245557.616812.1629881383071@mail.yahoo.com>
> Sarah <sarah_walker87@yahoo.co.uk> wrote:
>
>> On Wednesday, 25 August 2021, 09:35:54 BST, David Feugey
>> <dfeugey@ascinfo.fr> wrote:
>
>>>Do you feel better?
>
>> And you were calling me rude!
>
>What should I say: thanks to insult me?
>In message <420245557.616812.1629881383071@mail.yahoo.com>
> Sarah <sarah_walker87@yahoo.co.uk> wrote:
>
>> On Wednesday, 25 August 2021, 09:35:54 BST, David Feugey
>> <dfeugey@ascinfo.fr> 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 <420245557.616812.1629881383071@mail.yahoo.com>
Sarah <sarah_walker87@yahoo.co.uk> wrote:
> On Wednesday, 25 August 2021, 09:35:54 BST, David Feugey
> <dfeugey@ascinfo.fr> 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
Sarah <sarah_walker87@yahoo.co.uk> wrote:
> On Wednesday, 25 August 2021, 09:35:54 BST, David Feugey
> <dfeugey@ascinfo.fr> 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
In message <1935553908.591453.1629878765923@mail.yahoo.com>
Sarah <sarah_walker87@yahoo.co.uk> wrote:
> On Wednesday, 25 August 2021, 08:56:07 BST, David Feugey
> <dfeugey@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.
Absolutely.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sarah <sarah_walker87@yahoo.co.uk> wrote:
> On Wednesday, 25 August 2021, 08:56:07 BST, David Feugey
> <dfeugey@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.
Absolutely.
_______________________________________________
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 <dfeugey@ascinfo.fr> 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
>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 <dfeugey@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.
Sarah
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>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 <dfeugey@ascinfo.fr> wrote:
>In message <1304416007.566615.1629876855090@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
>In message <1304416007.566615.1629876855090@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 <FEB4943D-EFF0-46E3-A6F7-90ADDB704200@davidglover.org>
David Glover <me@davidglover.org> 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
David Glover <me@davidglover.org> 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
On Wednesday, 25 August 2021, 08:11:11 BST, David Feugey <dfeugey@ascinfo.fr> wrote:
>In message <378229865.417560.1629829850110@mail.yahoo.com> you wrote:
>
>> On Tuesday, 24 August 2021, 18:53:48 BST, David Feugey
>> <dfeugey@ascinfo.fr> wrote:
>
>> In message <747934817.371552.1629823670136@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
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
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
In message <378229865.417560.1629829850110@mail.yahoo.com>
Sarah <sarah_walker87@yahoo.co.uk> wrote:
> I also seriously doubt anyone with the interest or ability to do this
> would want your money.
> You're not just wrong, you're absolutely barking.
Do you feel better?
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Sarah <sarah_walker87@yahoo.co.uk> wrote:
> I also seriously doubt anyone with the interest or ability to do this
> would want your money.
> You're not just wrong, you're absolutely barking.
Do you feel better?
_______________________________________________
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 <me@davidglover.org> 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
> 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
Tuesday, 24 August 2021
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
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
On Tuesday, 24 August 2021, 18:53:48 BST, David Feugey <dfeugey@ascinfo.fr> wrote:
In message <747934817.371552.1629823670136@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
In message <747934817.371552.1629823670136@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 message <747934817.371552.1629823670136@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
>> 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
[Rpcemu] RPCEmu licence and other topics
> 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.
> 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. 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. RPCemu is a RiscPC emulator, not an emulator of anything else - the clue's in the name! 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.
Sarah
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
QEMU is cross-platform and has been for a very long time.
> 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. 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. RPCemu is a RiscPC emulator, not an emulator of anything else - the clue's in the name! 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.
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.GB31179@chiark.greenend.org.uk>,
Theo Markettos <theo@markettos.org.uk> 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
Theo Markettos <theo@markettos.org.uk> 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.GE31179@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
> 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
Monday, 23 August 2021
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 <whatever>', 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 needs to be done host-side, but
the RISC OS modules for HostFS/etc would need adaptation to use them rather
than the RPCEmu way of doing things. For things like networking, QEMU
already provides models of existing ethernet cards and it's possible that
it could be less work to hook up RISC OS' existing drivers to those,
although better performance would be achieved by using emulation-friendly
interfaces like VirtIO.
> 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.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>
> 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 <whatever>', 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 needs to be done host-side, but
the RISC OS modules for HostFS/etc would need adaptation to use them rather
than the RPCEmu way of doing things. For things like networking, QEMU
already provides models of existing ethernet cards and it's possible that
it could be less work to hook up RISC OS' existing drivers to those,
although better performance would be achieved by using emulation-friendly
interfaces like VirtIO.
> 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.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Saturday, 21 August 2021
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 <rpcemu.howkins at marutan.net> 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: andrew@andrewpoole.org.uk
Web: https://www.andrewpoole.org.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> On Aug 20, 2021, at 8:57 AM, Peter Howkins <rpcemu.howkins at marutan.net> 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: andrew@andrewpoole.org.uk
Web: https://www.andrewpoole.org.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Friday, 20 August 2021
Re: [Rpcemu] RPCEmu licence and other topics
On Aug 20, 2021, at 8:57 AM, Peter Howkins <rpcemu.howkins@marutan.net> 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
>
> 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
> 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
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
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).
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 readyto 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?
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 peopleget good value for money. And all the money will make with it will be put intopromoting 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 copyof RPCemu so that nothing gets forked. So if you have also some wishesor 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.
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
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.
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
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 128MB.
Stability could be an issue with that on 26bit OSs because
programs often didn't react well to more than about 140MB.
However, I doubt that's an issue on RISC OS 5.
Comment on names. I tend to prefer the "RISCOS4Windows", BUT
this sounds like RISC OS 4, which is the obsolete 26bit OS. I
suppose we need RISCOS5Windows but that doesn't sound good.
Maybe winRISC, macRISC, linRISC?
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.
Peter Howkins
Co-signed by
Matthew Howkins
Sarah Walker
allow users to run obsolete software. Whether you consider RISC OS 3, 4, 5
or 6 is obsolete, is left as a personal choice.
Peter Howkins
Co-signed by
Matthew Howkins
Sarah Walker
A copy of this email has been sent to the RPCEmu mailing list, so that other
developers and users are aware.
Subscribe to:
Posts (Atom)