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
Subscribe to:
Posts (Atom)