In article <5878ae9aedj.mccartney@blueyonder.co.uk>, John McCartney
<j.mccartney@blueyonder.co.uk> wrote:
> In article <da7dec82-5ea5-f619-d8ea-f9482f0a621c@skynet.be>, Peter
> Veltmans <peter.veltmans@skynet.be> wrote:
> > This is a reply to John McCartney's question about starting RPCEmu
> > from the desktop (actually: from the menu-system of a Linux-desktop).
> Just a quickie to acknowledge all those who've offered advice on this
> thread. I'm going to have to park it for a few days because I have other
> calls on my limited time at the moment.
> I'll have to give my brain time to assimilate it all. Perhaps I'll give
> it a defrag because it's definitely running slowly. :-(
> John
FWIW Here I just use a simple ROX app that launches RPCEmu by running an
executable file containing
#! /bin/sh
cd /home/jim/RPCemu/rpcemu-0.8.11
exec ./rpcemu
Thus one click on the 'icon bar' on my Linux setup pops up RPCEmu!
(Yes, I'm still using an ancient version. 8-] Not yet got the round tuits
to get a newer one! In the main I use an ARMX6, and only need RPCEmu
occasionally for ancient software/files purposes. )
HTH
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, 30 May 2020
Re: [Rpcemu] Installing to Linux (John McCartney)
In article
<da7dec82-5ea5-f619-d8ea-f9482f0a621c@skynet.be>, Peter
Veltmans <peter.veltmans@skynet.be> wrote:
> This is a reply to John McCartney's question about
> starting RPCEmu from the desktop (actually: from the
> menu-system of a Linux-desktop).
Just a quickie to acknowledge all those who've offered
advice on this thread. I'm going to have to park it for a
few days because I have other calls on my limited time at
the moment.
I'll have to give my brain time to assimilate it all.
Perhaps I'll give it a defrag because it's definitely
running slowly. :-(
John
--
John McCartney
j.mccartney@blueyonder.co.uk
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<da7dec82-5ea5-f619-d8ea-f9482f0a621c@skynet.be>, Peter
Veltmans <peter.veltmans@skynet.be> wrote:
> This is a reply to John McCartney's question about
> starting RPCEmu from the desktop (actually: from the
> menu-system of a Linux-desktop).
Just a quickie to acknowledge all those who've offered
advice on this thread. I'm going to have to park it for a
few days because I have other calls on my limited time at
the moment.
I'll have to give my brain time to assimilate it all.
Perhaps I'll give it a defrag because it's definitely
running slowly. :-(
John
--
John McCartney
j.mccartney@blueyonder.co.uk
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Installing to Linux (John McCartney)
On 28/05/2020 17:55, Peter Veltmans wrote:
> Hi all!
>
> This is a reply to John McCartney's question about starting RPCEmu from
> the desktop (actually: from the menu-system of a Linux-desktop).
>
> As I wrote before (on 15/05/2020):
>
> starting rpcemu from the command line (after compiling, of course) was straightforward. Starting it from the menusystem of the desktop however, was not. It gave an error, complaining about some files not being present (./roms, for example). I checked and lo and behold, the roms were present.
>
> So I surmised that the menusystem just didn't change directory in a
> clear way. So I made up a little script (called RISCOS5.sh), with the
>
I very much doubt it is a 'changing directory' issue perse, far more
likely associated permissions somewhere along the line.
Running from the desktop menus or desktop panel or even a desktop
shortcut works here without any scripting.
--
Michael Howard
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Hi all!
>
> This is a reply to John McCartney's question about starting RPCEmu from
> the desktop (actually: from the menu-system of a Linux-desktop).
>
> As I wrote before (on 15/05/2020):
>
> starting rpcemu from the command line (after compiling, of course) was straightforward. Starting it from the menusystem of the desktop however, was not. It gave an error, complaining about some files not being present (./roms, for example). I checked and lo and behold, the roms were present.
>
> So I surmised that the menusystem just didn't change directory in a
> clear way. So I made up a little script (called RISCOS5.sh), with the
>
I very much doubt it is a 'changing directory' issue perse, far more
likely associated permissions somewhere along the line.
Running from the desktop menus or desktop panel or even a desktop
shortcut works here without any scripting.
--
Michael Howard
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Friday, 29 May 2020
Re: [Rpcemu] Installing to Linux (John McCartney)
In message <da7dec82-5ea5-f619-d8ea-f9482f0a621c@skynet.be>
Peter Veltmans <peter.veltmans@skynet.be> wrote:
> #!/bin/bash
> #
> # A script to start RPCemu with RISCOS 5!
> #
> cd /home/USER/PROGRAMS/RPCEmu/rpcemu-0.9.3-recompiler-RISCOS5
> ./rpcemu-recompiler
You could make the script more generic by doing:
#!/bin/bash
cd $(dirname $0)
./rpcemu-recompiler
That way it will change directory to its own location, so it can be
dropped straight into all the versions of RPCEmu you have.
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Peter Veltmans <peter.veltmans@skynet.be> wrote:
> #!/bin/bash
> #
> # A script to start RPCemu with RISCOS 5!
> #
> cd /home/USER/PROGRAMS/RPCEmu/rpcemu-0.9.3-recompiler-RISCOS5
> ./rpcemu-recompiler
You could make the script more generic by doing:
#!/bin/bash
cd $(dirname $0)
./rpcemu-recompiler
That way it will change directory to its own location, so it can be
dropped straight into all the versions of RPCEmu you have.
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Thursday, 28 May 2020
Re: [Rpcemu] Installing to Linux
On 29 May 2020, at 3:18, John McCartney wrote:
> Despite looking like a text file
Every version of Linux is a little different so I may be wrong about
this, but perhaps all you need to do is set the "executable" flag on the
rpcemu-recompiler file:
chmod u+x rpcemu-recompiler
I would normally expect this to have been done by the process of
creating a compiled binary in the first place, but maybe that didn't
happen for some reason (or I'm just wrong about the problem you're
having).
--
Andrew Hodgkinson
RISC OS Open Limited
http://www.riscosopen.org/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> Despite looking like a text file
Every version of Linux is a little different so I may be wrong about
this, but perhaps all you need to do is set the "executable" flag on the
rpcemu-recompiler file:
chmod u+x rpcemu-recompiler
I would normally expect this to have been done by the process of
creating a compiled binary in the first place, but maybe that didn't
happen for some reason (or I'm just wrong about the problem you're
having).
--
Andrew Hodgkinson
RISC OS Open Limited
http://www.riscosopen.org/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Installing to Linux (John McCartney)
Hi all!
This is a reply to John McCartney's question about starting RPCEmu from
the desktop (actually: from the menu-system of a Linux-desktop).
As I wrote before (on 15/05/2020):
starting rpcemu from the command line (after compiling, of course) was straightforward. Starting it from the menusystem of the desktop however, was not. It gave an error, complaining about some files not being present (./roms, for example). I checked and lo and behold, the roms were present.
So I surmised that the menusystem just didn't change directory in a
clear way. So I made up a little script (called RISCOS5.sh), with the
following content:
#!/bin/bash
#
# A script to start RPCemu with RISCOS 5!
#
cd /home/USER/PROGRAMS/RPCEmu/rpcemu-0.9.3-recompiler-RISCOS5
./rpcemu-recompiler
NOTE: the last command (i.e.: './rpcemu-recompiler') should be on a new line after the cd-command!!!
I made another script (called RISCOS371.sh) for the Easy-Start-Bundle
with RISC OS 3.71, in the same fashion.
Both scripts were saved in a directory called RPCEmu (in my case under
another directory, called PROGRAMS) in my home-folder. Of course these
scripts could be placed anywhere where one has read-and-write access.
After that I just edited the menu-system of Ubuntu MATE, created two new
items in the menu-system and pointed each towards their respective script.
That did it!
Both instances of RISC OS emulated through RPCEmu now start from their
own menu-item.
Sincerely,
Peter Veltmans
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
This is a reply to John McCartney's question about starting RPCEmu from
the desktop (actually: from the menu-system of a Linux-desktop).
As I wrote before (on 15/05/2020):
starting rpcemu from the command line (after compiling, of course) was straightforward. Starting it from the menusystem of the desktop however, was not. It gave an error, complaining about some files not being present (./roms, for example). I checked and lo and behold, the roms were present.
So I surmised that the menusystem just didn't change directory in a
clear way. So I made up a little script (called RISCOS5.sh), with the
following content:
#!/bin/bash
#
# A script to start RPCemu with RISCOS 5!
#
cd /home/USER/PROGRAMS/RPCEmu/rpcemu-0.9.3-recompiler-RISCOS5
./rpcemu-recompiler
NOTE: the last command (i.e.: './rpcemu-recompiler') should be on a new line after the cd-command!!!
I made another script (called RISCOS371.sh) for the Easy-Start-Bundle
with RISC OS 3.71, in the same fashion.
Both scripts were saved in a directory called RPCEmu (in my case under
another directory, called PROGRAMS) in my home-folder. Of course these
scripts could be placed anywhere where one has read-and-write access.
After that I just edited the menu-system of Ubuntu MATE, created two new
items in the menu-system and pointed each towards their respective script.
That did it!
Both instances of RISC OS emulated through RPCEmu now start from their
own menu-item.
Sincerely,
Peter Veltmans
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Installing to Linux
McCartney <j.mccartney@blueyonder.co.uk> wrote:
> In article
> <E539569F-EAD9-4DC9-A65C-E090972FEAF8@riscosopen.org>,
> Andrew Hodgkinson <ahodgkin@riscosopen.org> wrote:
> > On 11 May 2020, at 2:25, John McCartney wrote:
> > I recommend you build both. Use the recompiler version
> > normally, but if you encounter crashes you wouldn't
> > expect from a normal RISC OS machine, switch to the
> > interpreter version.
> Thanks Andrew. I'll build the interpreter version first
> and see how I get on with it. I might well be back to ask
> more questions.
I knew I'd be back.
I decided to go for the recompiler version first and, after
much confusion (self-induced), I finally managed to get it
to compile and ended up with the contents of my folder
(rpcemu-0.9.3) appearing as in the attached image.
The appearance of files for 0.9.3 is different to how they
appeared for 0.8.15 which I tried a couple of years ago. I
abandoned that version because of networking difficulties.
Despite looking like a text file (which I know it isn't) it
runs just fine when invoked with ./rpcemu-recompiler.
However, I don't want to have to go into the terminal every
time I want to run RISC OS. I made a link to the executable
(is that the right description in Linux?) and dragged it to
the desktop but it just asked me to choose a program to
start it. I couldn't see a likely candidate in the program
list so I backed out. Is there a way to run the program
from the desktop?
John
--
John McCartney
j.mccartney@blueyonder.co.uk
Wednesday, 27 May 2020
Healthcare courses to make you health-force Warriors!
The world today needs at least a billion paramedics staff to handle a pandemic of this magnitude- be a real-life hero by saving humankind from this vicious Corona join Acharya Health Sciences (AIHS) Bsc MLT Course. A battle of the century is yet to be won! <a href="https://www.aihs.ac.in/bsc-medical-lab-technology.html"> Bachelor of Medical Lab Technolgy </a>
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Re: [Rpcemu] New 0.9.3 Mac binary release
Hi,
I've at last completed all my Mac machine upgrades to this version. No problems at all (apart from finger trouble right here). It works on machines as far back as 2010, but not on one from 2008 due to the stipulated MacOS level not being available for the 2008 machine.
I've even tried the 2.27 RISC OS as it was declared stable for the 2.28 release. Again all works well.
Many thanks indeed for piling out this update, it gives RISC OS a whole different dimension to know that RPCemu is not only being updated but also built for the latest Macs and does the internet. I can now take RISC OS with me wherever I go!
And the NAT-based networking just works, no fuss, no bother, brilliant.
Tim
--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/
> On 8 May 2020, at 2:51 pm, Timothy Coltman <lists@maemagel.com> wrote:
>
> Hello all
>
> Following yesterday's release of 0.9.3, I have built a Mac binary, which is now available for download from its new home:
>
> https://github.com/Septercius/rpcemu-dev/releases
>
> The 0.9.3a release includes all the patches from the previous version, and fixes two issues:
>
> * The missing "hostfs" folder is now included in the "Data" directory inside the DMGs.
> * The key you can hold down at startup to bring up the dialogue that prompts you to choose where the emulator data (ROMs, CMOS, hard drive images, etc) resides has been changed from CTRL to SHIFT. This is to make it easier to trigger the dialogue as the application starts (the Mac interprets CTRL+click as a right click).
>
> As ever, bugs/comments/suggestions are welcome.
>
> Tim
>
>
> _______________________________________________
> 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
Monday, 25 May 2020
Re: NetSurf 3.10 released
On 25/05/2020, Michael Drake <tlsa@netsurf-browser.org> wrote:
> NetSurf 3.10 has been released.
>
> It is available from:
>
> https://www.netsurf-browser.org/
>
> NetSurf 3.10 features many fixes, better performance
> and improved functionality. In particular, handling
> of authentication, certificates and fetch errors have
> been updated and unified. The GTK front end has had a
> major overhaul too.
>
> --
> NetSurf Developers
> _______________________________________________
> netsurf-users mailing list -- netsurf-users@netsurf-browser.org
> To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
>
Hello.
I wonder when (if an appropriate package developer is watching) a
package of this version will become available in the Ubuntu Linux
20.04 (and hopefully also for 16.04) repository.
I am currently running UbuntuMATE 20.04 (which has NetSurf 3.6), and
16.04 (which has NetSurf 3.2).
--
Bret Busby
Armadale
West Australia
..............
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
> NetSurf 3.10 has been released.
>
> It is available from:
>
> https://www.netsurf-browser.org/
>
> NetSurf 3.10 features many fixes, better performance
> and improved functionality. In particular, handling
> of authentication, certificates and fetch errors have
> been updated and unified. The GTK front end has had a
> major overhaul too.
>
> --
> NetSurf Developers
> _______________________________________________
> netsurf-users mailing list -- netsurf-users@netsurf-browser.org
> To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
>
Hello.
I wonder when (if an appropriate package developer is watching) a
package of this version will become available in the Ubuntu Linux
20.04 (and hopefully also for 16.04) repository.
I am currently running UbuntuMATE 20.04 (which has NetSurf 3.6), and
16.04 (which has NetSurf 3.2).
--
Bret Busby
Armadale
West Australia
..............
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
NetSurf 3.10 released
NetSurf 3.10 has been released.
It is available from:
https://www.netsurf-browser.org/
NetSurf 3.10 features many fixes, better performance
and improved functionality. In particular, handling
of authentication, certificates and fetch errors have
been updated and unified. The GTK front end has had a
major overhaul too.
--
NetSurf Developers
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
It is available from:
https://www.netsurf-browser.org/
NetSurf 3.10 features many fixes, better performance
and improved functionality. In particular, handling
of authentication, certificates and fetch errors have
been updated and unified. The GTK front end has had a
major overhaul too.
--
NetSurf Developers
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
Friday, 22 May 2020
Re: Page Info and SSL certificate viewer
On Fri, 22 May 2020 at 11:52, Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:
You will need to implement the page_info corewindow, along with supporting
the browser padlock rendering via browser_window_get_page_info_state()
triggered from the GW_EVENT_PAGE_INFO_CHANGE event sent to the event callback
in the gui_window_table. If you're not implementing this stuff then your users
are missing out on a lot of important state information which informs them
of things like the security status of the page they're on.
This is now fully implemented on the Amiga version, tested and working on OS4, untested but building with no warnings on OS3.
Every website is showing "Cookies: (0 in use)" though which I'm not convinced is correct!
I had to tweak page_info_redraw as it wasn't taking into account non-full window (tiled) rendering unlike the other core windows.
Apologies for breaking the Messages encoding, I was using a different editor and didn't notice.
Chris
Page Info and SSL certificate viewer
Hi devs,
The SSL certificate viewer core window has finally been fully removed.
I have gone through the frontends and removed reference to it, and for the
most part that seems to have built OK, but could everyone please check their
frontends.
You will need to implement the page_info corewindow, along with supporting
the browser padlock rendering via browser_window_get_page_info_state()
triggered from the GW_EVENT_PAGE_INFO_CHANGE event sent to the event callback
in the gui_window_table. If you're not implementing this stuff then your users
are missing out on a lot of important state information which informs them
of things like the security status of the page they're on.
You can use monkey, gtk, or (soon) riscos as guides for how to do this.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
The SSL certificate viewer core window has finally been fully removed.
I have gone through the frontends and removed reference to it, and for the
most part that seems to have built OK, but could everyone please check their
frontends.
You will need to implement the page_info corewindow, along with supporting
the browser padlock rendering via browser_window_get_page_info_state()
triggered from the GW_EVENT_PAGE_INFO_CHANGE event sent to the event callback
in the gui_window_table. If you're not implementing this stuff then your users
are missing out on a lot of important state information which informs them
of things like the security status of the page they're on.
You can use monkey, gtk, or (soon) riscos as guides for how to do this.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
Wednesday, 20 May 2020
Re: [Rpcemu] RPCEmu 0.9.3
On Wed, 20 May 2020 at 14:12, John Rickman <rickman@argonet.co.uk> wrote:
In message <CANc9Z=ynpkX7SZaWU3O+SfD8EkZRf8CwJ1w1hqFWxAo5EMFz0A@mail.gmail
.com>
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> - RISC OS Direct, a version of the RISC OS 5 based distribution with
> many extras, ideal for running recent applications
What is the file size of the ROD bundle?
Written next to the location you download them from
Approx 1GB
Peter
Re: [Rpcemu] RPCEmu 0.9.3
On 20 May in article <090b9b7358.John@rickman.argonet..co.uk>,
John Rickman <rickman@argonet.co.uk> wrote:
> What is the file size of the ROD bundle?
1061 MB
The 3.71 bundle is 119MB
--
Martin Avison using a TiMachine running RISC OS 5
and the Pluto mail and newsreader
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
John Rickman <rickman@argonet.co.uk> wrote:
> What is the file size of the ROD bundle?
1061 MB
The 3.71 bundle is 119MB
--
Martin Avison using a TiMachine running RISC OS 5
and the Pluto mail and newsreader
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.3
In message <20200520132606.GD6433@pepperfish.net>
Rob Kendrick <rjek@rjek.com> wrote:
> On Wed, May 20, 2020 at 01:30:27PM +0100, John Rickman wrote:
>> What is the file size of the ROD bundle?
> Approximately 1GB.
thanks
John
--
John Rickman
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Rob Kendrick <rjek@rjek.com> wrote:
> On Wed, May 20, 2020 at 01:30:27PM +0100, John Rickman wrote:
>> What is the file size of the ROD bundle?
> Approximately 1GB.
thanks
John
--
John Rickman
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.3
On Wed, May 20, 2020 at 01:30:27PM +0100, John Rickman wrote:
> What is the file size of the ROD bundle?
Approximately 1GB.
B.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> What is the file size of the ROD bundle?
Approximately 1GB.
B.
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.3
In message <CANc9Z=ynpkX7SZaWU3O+SfD8EkZRf8CwJ1w1hqFWxAo5EMFz0A@mail.gmail
.com>
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> A new version of RPCEmu is available, 0.9.3
> http://www.marutan.net/rpcemu/
> Changes in this build
> - Easy-Start bundles
> - Two ROM/Disc Image sets are now available to make setting up RPCEmu as
> simple as possible. both are configured with networking by default.
> - RISC OS Direct, a version of the RISC OS 5 based distribution with
> many extras, ideal for running recent applications
What is the file size of the ROD bundle?
John
--
John Rickman
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
.com>
Peter Howkins <rpcemu.howkins@marutan.net> wrote:
> A new version of RPCEmu is available, 0.9.3
> http://www.marutan.net/rpcemu/
> Changes in this build
> - Easy-Start bundles
> - Two ROM/Disc Image sets are now available to make setting up RPCEmu as
> simple as possible. both are configured with networking by default.
> - RISC OS Direct, a version of the RISC OS 5 based distribution with
> many extras, ideal for running recent applications
What is the file size of the ROD bundle?
John
--
John Rickman
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: Non SSE Build
In message <20200519131231.GO6433@pepperfish.net>
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Tue, May 19, 2020 at 11:53:44AM +0000, David Feugey wrote:
>> Yes, I tried and I get some illegal instruction error.
>>
>> I did have the same kind of problem with Fireworkz, and it was a SSE
>> problem.
>> But perhaps it's a MMX issue too. I don't know.
>>
>> That's why I would like to test with some other build options, and check
>> it on some old hardware.
> I believe if you have a Linux box to hand, building any of our ports is
> reasonably straightforward as we provide pre-built toolchains and
> instructions on how to drive it all. (We cross-compile everything from
> Linux because life's too short to build software on RISC OS and Windows
> natively.)
I don't have such a machine. But it should be possible :)
I"ll try later, when time will allow it.
> Modifying the Makefiles to pass something like -march=i586 should target
> CPUs with no MMX oe SSE support.
OKI DOKI
David
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Rob Kendrick <rjek@netsurf-browser.org> wrote:
> On Tue, May 19, 2020 at 11:53:44AM +0000, David Feugey wrote:
>> Yes, I tried and I get some illegal instruction error.
>>
>> I did have the same kind of problem with Fireworkz, and it was a SSE
>> problem.
>> But perhaps it's a MMX issue too. I don't know.
>>
>> That's why I would like to test with some other build options, and check
>> it on some old hardware.
> I believe if you have a Linux box to hand, building any of our ports is
> reasonably straightforward as we provide pre-built toolchains and
> instructions on how to drive it all. (We cross-compile everything from
> Linux because life's too short to build software on RISC OS and Windows
> natively.)
I don't have such a machine. But it should be possible :)
I"ll try later, when time will allow it.
> Modifying the Makefiles to pass something like -march=i586 should target
> CPUs with no MMX oe SSE support.
OKI DOKI
David
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Tuesday, 19 May 2020
Re: Change of List ID
In message <20200519193147.GB5547@somnambulist.local>
Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:
> On Tue, May 19, 2020 at 18:43:34 +0100, Frederick Bambrough wrote:
> > Is the change of the List ID: header intentional and permanent? Has a
> > hyphen replaced by a period.
>
> Yes, it's part of the shift to mailman3 which was done several weeks
> ago.
>
> I am sorry if your filters needed adjusting.
No problem - just checking.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:
> On Tue, May 19, 2020 at 18:43:34 +0100, Frederick Bambrough wrote:
> > Is the change of the List ID: header intentional and permanent? Has a
> > hyphen replaced by a period.
>
> Yes, it's part of the shift to mailman3 which was done several weeks
> ago.
>
> I am sorry if your filters needed adjusting.
No problem - just checking.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Re: Change of List ID
On Tue, May 19, 2020 at 18:43:34 +0100, Frederick Bambrough wrote:
> Is the change of the List ID: header intentional and permanent? Has a
> hyphen replaced by a period.
Yes, it's part of the shift to mailman3 which was done several weeks ago.
I am sorry if your filters needed adjusting.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
> Is the change of the List ID: header intentional and permanent? Has a
> hyphen replaced by a period.
Yes, it's part of the shift to mailman3 which was done several weeks ago.
I am sorry if your filters needed adjusting.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Change of List ID
Is the change of the List ID: header intentional and permanent? Has a
hyphen replaced by a period.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
hyphen replaced by a period.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Re: Non SSE Build
On Tue, May 19, 2020 at 11:53:44AM +0000, David Feugey wrote:
> Yes, I tried and I get some illegal instruction error.
>
> I did have the same kind of problem with Fireworkz, and it was a SSE problem.
> But perhaps it's a MMX issue too. I don't know.
>
> That's why I would like to test with some other build options, and check it on some old hardware.
I believe if you have a Linux box to hand, building any of our ports is
reasonably straightforward as we provide pre-built toolchains and
instructions on how to drive it all. (We cross-compile everything from
Linux because life's too short to build software on RISC OS and Windows
natively.)
Modifying the Makefiles to pass something like -march=i586 should target
CPUs with no MMX oe SSE support.
B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
> Yes, I tried and I get some illegal instruction error.
>
> I did have the same kind of problem with Fireworkz, and it was a SSE problem.
> But perhaps it's a MMX issue too. I don't know.
>
> That's why I would like to test with some other build options, and check it on some old hardware.
I believe if you have a Linux box to hand, building any of our ports is
reasonably straightforward as we provide pre-built toolchains and
instructions on how to drive it all. (We cross-compile everything from
Linux because life's too short to build software on RISC OS and Windows
natively.)
Modifying the Makefiles to pass something like -march=i586 should target
CPUs with no MMX oe SSE support.
B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
RE: Non SSE Build
Yes, I tried and I get some illegal instruction error.
I did have the same kind of problem with Fireworkz, and it was a SSE problem.
But perhaps it's a MMX issue too. I don't know.
That's why I would like to test with some other build options, and check it on some old hardware.
I can test it on VIA processors, Duron/Athlon, Pentium II/III, but also Vortex86.
I have hundreds of old computers 🙂
David
De : Rob Kendrick <rjek@netsurf-browser.org>
Envoyé : mardi 19 mai 2020 13:40
À : netsurf-users@netsurf-browser.org <netsurf-users@netsurf-browser.org>
Objet : Re: Non SSE Build
Envoyé : mardi 19 mai 2020 13:40
À : netsurf-users@netsurf-browser.org <netsurf-users@netsurf-browser.org>
Objet : Re: Non SSE Build
On Tue, May 19, 2020 at 01:32:28PM +0200, David Feugey wrote:
> Hi all.
>
> NetSurf is very cool. And perfect on old computers.
>
> Unfortunately, under Windows, it's (probably) compiled with SSE
> optimisations. So it's not possible to use it with embedded devices, as
> my eBox under XP (it will be probably the same with new dual core eBox
> under 7).
Have you tried it? Guessing from the filename of the toolchain
download, the toolchain targets "686", which is P6/Pentium Pro which
pre-dates the Pentium 3 that introduced SSE.
B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
> Hi all.
>
> NetSurf is very cool. And perfect on old computers.
>
> Unfortunately, under Windows, it's (probably) compiled with SSE
> optimisations. So it's not possible to use it with embedded devices, as
> my eBox under XP (it will be probably the same with new dual core eBox
> under 7).
Have you tried it? Guessing from the filename of the toolchain
download, the toolchain targets "686", which is P6/Pentium Pro which
pre-dates the Pentium 3 that introduced SSE.
B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Re: Non SSE Build
On Tue, May 19, 2020 at 01:32:28PM +0200, David Feugey wrote:
> Hi all.
>
> NetSurf is very cool. And perfect on old computers.
>
> Unfortunately, under Windows, it's (probably) compiled with SSE
> optimisations. So it's not possible to use it with embedded devices, as
> my eBox under XP (it will be probably the same with new dual core eBox
> under 7).
Have you tried it? Guessing from the filename of the toolchain
download, the toolchain targets "686", which is P6/Pentium Pro which
pre-dates the Pentium 3 that introduced SSE.
B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
> Hi all.
>
> NetSurf is very cool. And perfect on old computers.
>
> Unfortunately, under Windows, it's (probably) compiled with SSE
> optimisations. So it's not possible to use it with embedded devices, as
> my eBox under XP (it will be probably the same with new dual core eBox
> under 7).
Have you tried it? Guessing from the filename of the toolchain
download, the toolchain targets "686", which is P6/Pentium Pro which
pre-dates the Pentium 3 that introduced SSE.
B.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Non SSE Build
Hi all.
NetSurf is very cool. And perfect on old computers.
Unfortunately, under Windows, it's (probably) compiled with SSE
optimisations. So it's not possible to use it with embedded devices, as
my eBox under XP (it will be probably the same with new dual core eBox
under 7).
Does someone has a ready to use compilation toolchain, and could provide
me a 586 build without SSE/SSE2 for tests? I'll make some tests to verify
it'll work on various thin clients and embedded boxes.
Thanks, David
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
NetSurf is very cool. And perfect on old computers.
Unfortunately, under Windows, it's (probably) compiled with SSE
optimisations. So it's not possible to use it with embedded devices, as
my eBox under XP (it will be probably the same with new dual core eBox
under 7).
Does someone has a ready to use compilation toolchain, and could provide
me a 586 build without SSE/SSE2 for tests? I'll make some tests to verify
it'll work on various thin clients and embedded boxes.
Thanks, David
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org
Friday, 15 May 2020
Re: [Rpcemu] Chocks Away emulation a little speedy
Ah, nostalgic fun :-)
I've now tried Chocks Away myself (and "wasted" several hours!) and have
found that changing the RPCEmu screen refresh rate down to 25Hz does slow
it down.
In message <7AE766D8-F4B1-4CEE-A9DC-9E1D927102F0@gmx.net> you wrote:
> The second issue I had is that unlike on the original hardware, the mouse
> pointer crawls up the screen when displaying the game menu
Yes I got this too when running in a window, but not in Full Screen mode,
which uses different mouse handling.
Better news is that Chocks Away 2, aka Extra Missions, works fine. No
problem with the mouse handling and it runs at the correct speed :-)
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
I've now tried Chocks Away myself (and "wasted" several hours!) and have
found that changing the RPCEmu screen refresh rate down to 25Hz does slow
it down.
In message <7AE766D8-F4B1-4CEE-A9DC-9E1D927102F0@gmx.net> you wrote:
> The second issue I had is that unlike on the original hardware, the mouse
> pointer crawls up the screen when displaying the game menu
Yes I got this too when running in a window, but not in Full Screen mode,
which uses different mouse handling.
Better news is that Chocks Away 2, aka Extra Missions, works fine. No
problem with the mouse handling and it runs at the correct speed :-)
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Sound Settings - RPCEmu 0.9.3 & RISC OS 3.50
Hello,
On Thu, 14 May 2020 at 22:07, Steffen Huber <steffen@huber-net.de> wrote:
Hi,
> Theo Markettos <theo@markettos.org.uk> wrote:
>
> On Thu, May 14, 2020 at 07:33:33PM +0100, Bryan Hogan wrote:
> > It was a long time ago, but I think I had the 16bit sound upgrade with
> > RISC OS 3.5, but did need to soft load new sound modules to make it work.
> >
> > No idea which modules they were though!
>
> It was probably SoundDMA - so extracting the SoundDMA module from a later
> RISC OS version might be worth a try?
Chris' Acorn has a download for the Acorn 16bit sound upgrade:
http://chrisacorns.computinghistory.org.uk/Software/Acorn_16bitSound.arc
I am fairly sure that I have a floppy for the Mozart upgrade somewhere, but this upgrade had additional features (like 8bit passthrough without the 8-to-16bit conversion overhead which was a big deal when running on a 30MHz ARM610), no idea if this makes the software compatible.
RISC OS 3.6 should automatically support 16bit sound.
I've tried extracting the SoundDMA module from RISC OS 3.71, loading this resulted in no sound at all.
The same thing happened when using that 16BitSound downoad from Chris' Acorn.
I'm tempted to get my Risc PC out, thats running 3.50 (I think!) and see what modules are being used on there.
Rob.
Re: [Rpcemu] Chocks Away emulation a little speedy
Many thanks Bryan, Theo and George!
That's good to know. I had selected a hardware profile in RPCEmu ("Risc PC - ARM610") and had thought perhaps cycle timings would have been taken from this choice, but if emulating cycle timings is not feature, no worries at all.
The second issue I had is that unlike on the original hardware, the mouse pointer crawls up the screen when displaying the game menu, despite the mouse being still (you can see this in the video clip) and that the pointer is restricted to a specific region of the screen (I can make a separate video to demonstrate this, if desired).
I wanted to raise this as it may be due to an inaccuracy in the emulation, rather than because I want to play this particular game. It is nice to play it, of course, but that wasn't really my motivation. :-)
I'm also happy to get involved making a fix, if that helps, although I would need a little bit of mentoring to get started.
Many thanks again!
Pete
On 14. May 2020, at 20:28, Bryan Hogan <rpcemu@helpful.demon.co.uk> wrote:In message <9ECA882A-A98F-4024-8012-D0BF6516002E@gmx.net>
Peter Moore <petemoore@gmx.net> wrote:I recently imported my old RISC PC hard drive and am successfully
emulating it in RPCEmu. Some apps run a little faster that on the original
hardware, one example is Chocks Away:
AIUI RPCEmu isn't intended to be a cycle accurate emulator. After all,
with so many different models of RiscPC cpu, what speed would it use?
However, if Chocks Away uses the video refresh for its timing, then
changing the RPCEmu refresh rate might help. Maybe try 25Hz?
For games, try Arculator instead - http://b-em.bbcmicro.com/arculator/
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Thursday, 14 May 2020
[Rpcemu] PATCH: Provide option to port forward TCP and UDP ports from host to RISC OS in NAT mode
diff -r 00a162d7e6cd src/network-nat.c
--- a/src/network-nat.c Wed May 06 20:17:33 2020 +0100
+++ b/src/network-nat.c Thu May 14 22:15:17 2020 +0100
@@ -146,6 +146,75 @@
network_hwaddr[5] = 0x06;
}
+static void
+network_add_port_forwards(Slirp * restrict slirp, char * restrict portspec, struct in_addr *ros_addr)
+{
+ char *port = portspec;
+
+ rpclog("Networking: Parsing port forward string %s\n", portspec);
+
+#define ERR_POINT(line, pos) do { \
+ char *buf = malloc(pos + 2); \
+ rpclog(" %s\n", line); \
+ if (buf != NULL) { \
+ memset(buf, ' ', pos); \
+ buf[pos] = '^'; \
+ buf[pos + 1] = '\0'; \
+ rpclog(" %s\n", buf); \
+ free(buf); \
+ } \
+} while (0)
+
+ while (port && *port != '\0') {
+ int is_udp = 0;
+ int host_port = 0;
+ int ros_port = 0;
+ int rv = 0;
+ struct in_addr bind;
+
+ bind.s_addr = 0;
+
+ if (strncmp(port, "udp:", 4) == 0) {
+ is_udp = 1;
+ } else if (strncmp(port, "tcp:", 4) != 0) {
+ rpclog("Networking: bailing parsing port forwards, unknown protocol:\n");
+ ERR_POINT(portspec, port - portspec);
+ return;
+ }
+
+ port += 4;
+
+ host_port = strtol(port, &port, 0);
+ if (host_port == 0) {
+ rpclog("Networking: bailing parsing port forwards, invalid host port:\n");
+ ERR_POINT(portspec, port - portspec);
+ return;
+ }
+
+ /* skip colon */
+ port++;
+ ros_port = strtol(port, &port, 0);
+ if (ros_port == 0) {
+ rpclog("Networking: bailing parsing port forwards, invalid RISC OS port:\n");
+ ERR_POINT(portspec, port - portspec);
+ return;
+ }
+
+ while (*port != '\0' && *port == ' ') {
+ port++;
+ }
+
+ rpclog("Networking: forwarding host %s port %d to RISC OS port %d\n",
+ is_udp ? "UDP" : "TCP", host_port, ros_port);
+
+ rv = slirp_add_hostfwd(slirp, is_udp, bind, host_port, *ros_addr, ros_port);
+ if (rv != 0) {
+ rpclog("Networking: unable to forward: %d\n", rv);
+ }
+ }
+#undef ERR_POINT
+}
+
/**
*/
static void
@@ -172,7 +241,8 @@
net_addr, mask, host, vhostname, "", bootfile, dhcp, dns, NULL);
// TODO log NAT details
- }
+ network_add_port_forwards(nat.slirp, config.network_port_forwards, &dhcp);
+ };
}
int
@@ -195,6 +265,8 @@
}
}
+
+
return 1;
}
diff -r 00a162d7e6cd src/network.c
--- a/src/network.c Wed May 06 20:17:33 2020 +0100
+++ b/src/network.c Thu May 14 22:15:17 2020 +0100
@@ -207,11 +207,12 @@
* @param networktype New network type value
* @param bridgename String of new bridgename value (zero terminated), caller owns (copy taken)
* @param ipaddress String of new ipaddress value (zero terminated), caller owns (copy taken)
+ * @param forwards String of new forwards value (zero terminated), caller owns (copy taken)
* @return Non-zero if these config changes require an emulator restart
*/
int
network_config_changed(NetworkType network_type, const char *bridgename,
- const char *ipaddress)
+ const char *ipaddress, const char *forwards)
{
int restart_required = 0;
@@ -272,6 +273,32 @@
}
}
+ if (forwards == NULL && config.network_port_forwards != NULL) {
+ /* Forwarding is being turned off */
+ free(config.network_port_forwards);
+ config.network_port_forwards = NULL;
+ if (config.network_type == NetworkType_NAT) {
+ restart_required = 1;
+ }
+ } else if (forwards != NULL && config.network_port_forwards == NULL) {
+ /* Forwarding is being turned on */
+ config.network_port_forwards = strdup(forwards);
+ if (config.network_type == NetworkType_NAT) {
+ restart_required = 1;
+ }
+ } else {
+ if (forwards != NULL && config.network_port_forwards != NULL &&
+ strcmp(forwards, config.network_port_forwards) != 0)
+ {
+ /* Forwarding changed */
+ free(config.network_port_forwards);
+ config.network_port_forwards = strdup(forwards);
+ if (config.network_type == NetworkType_NAT) {
+ restart_required = 1;
+ }
+ }
+ }
+
// Save the settings to the rpc.cfg file
config_save(&config);
diff -r 00a162d7e6cd src/network.h
--- a/src/network.h Wed May 06 20:17:33 2020 +0100
+++ b/src/network.h Thu May 14 22:15:17 2020 +0100
@@ -46,7 +46,7 @@
void strcpyfromhost(uint32_t dest, const char *source);
int network_config_changed(NetworkType networktype, const char *bridgename,
- const char *ipaddress);
+ const char *ipaddress, const char *forwards);
int network_macaddress_parse(const char *macaddress, uint8_t hwaddr[6]);
/* Functions provided by each host platform's network code */
diff -r 00a162d7e6cd src/qt5/network_dialog.cpp
--- a/src/qt5/network_dialog.cpp Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/network_dialog.cpp Thu May 14 22:15:17 2020 +0100
@@ -57,6 +57,14 @@
tunnelling_hbox->addWidget(tunnelling_label);
tunnelling_hbox->addWidget(tunnelling_name);
+ forwards_label = new QLabel("Port forwards");
+ forwards_name = new QLineEdit(QString("tcp:8080:80"));
+ forwards_name->setMinimumWidth(192);
+ forwards_hbox = new QHBoxLayout();
+ forwards_hbox->insertSpacing(0, 48);
+ forwards_hbox->addWidget(forwards_label);
+ forwards_hbox->addWidget(forwards_name);
+
// Create Buttons
buttons_box = new QDialogButtonBox(QDialogButtonBox::Ok | QDialogButtonBox::Cancel);
@@ -65,6 +73,7 @@
vbox = new QVBoxLayout(this);
vbox->addWidget(net_off);
vbox->addWidget(net_nat);
+ vbox->addLayout(forwards_hbox);
vbox->addWidget(net_bridging);
vbox->addLayout(bridge_hbox);
@@ -117,6 +126,14 @@
tunnelling_label->setEnabled(false);
tunnelling_name->setEnabled(false);
}
+
+ if (net_nat->isChecked()) {
+ forwards_label->setEnabled(true);
+ forwards_name->setEnabled(true);
+ } else {
+ forwards_label->setEnabled(false);
+ forwards_name->setEnabled(false);
+ }
}
/**
@@ -125,8 +142,8 @@
void
NetworkDialog::dialog_accepted()
{
- QByteArray ba_bridgename, ba_ipaddress;
- char *bridgename, *ipaddress;
+ QByteArray ba_bridgename, ba_ipaddress, ba_forwards;
+ char *bridgename, *ipaddress, *forwards;
NetworkType network_type = NetworkType_Off;
// Take a copy of the existing config
@@ -161,7 +178,7 @@
// Update network config in emulator thread
emit this->emulator.network_config_updated_signal(network_type,
- bridge_name->text(), tunnelling_name->text());
+ bridge_name->text(), tunnelling_name->text(), forwards_name->text());
ba_bridgename = bridge_name->text().toUtf8();
bridgename = ba_bridgename.data();
@@ -169,6 +186,9 @@
ba_ipaddress = tunnelling_name->text().toUtf8();
ipaddress = ba_ipaddress.data();
+ ba_forwards = forwards_name->text().toUtf8();
+ forwards = ba_forwards.data();
+
// Apply configuration settings from Dialog to config_copy
config_copy->network_type = network_type;
if (config_copy->bridgename == NULL) {
@@ -183,6 +203,12 @@
free(config_copy->ipaddress);
config_copy->ipaddress = strdup(ipaddress);
}
+ if (config_copy->network_port_forwards == NULL) {
+ config_copy->network_port_forwards = strdup(forwards);
+ } else if (strcmp(config_copy->network_port_forwards, forwards) != 0) {
+ free(config_copy->network_port_forwards);
+ config_copy->network_port_forwards = strdup(forwards);
+ }
}
/**
@@ -235,4 +261,9 @@
if(config_copy->ipaddress && config_copy->ipaddress[0] != '\0') {
tunnelling_name->setText(config_copy->ipaddress);
}
+
+ if(config_copy->network_port_forwards && config_copy->network_port_forwards[0] != '\0') {
+ forwards_name->setText(config_copy->network_port_forwards);
+ }
+
}
diff -r 00a162d7e6cd src/qt5/network_dialog.h
--- a/src/qt5/network_dialog.h Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/network_dialog.h Thu May 14 22:15:17 2020 +0100
@@ -59,6 +59,10 @@
QLineEdit *tunnelling_name;
QHBoxLayout *tunnelling_hbox;
+ QLabel *forwards_label;
+ QLineEdit *forwards_name;
+ QHBoxLayout *forwards_hbox;
+
QDialogButtonBox *buttons_box;
QVBoxLayout *vbox;
diff -r 00a162d7e6cd src/qt5/rpc-qt5.cpp
--- a/src/qt5/rpc-qt5.cpp Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/rpc-qt5.cpp Thu May 14 22:15:17 2020 +0100
@@ -916,7 +916,7 @@
* @param ipaddress
*/
void
-Emulator::network_config_updated(NetworkType network_type, QString bridgename, QString ipaddress)
+Emulator::network_config_updated(NetworkType network_type, QString bridgename, QString ipaddress, QString forwards)
{
QByteArray ba_bridgename = bridgename.toUtf8();
const char *bridge_name = ba_bridgename.constData();
@@ -924,7 +924,10 @@
QByteArray ba_ipaddress = ipaddress.toUtf8();
const char *ip_address = ba_ipaddress.constData();
- if (network_config_changed(network_type, bridge_name, ip_address)) {
+ QByteArray ba_forwards = forwards.toUtf8();
+ const char *port_forwards = ba_forwards.constData();
+
+ if (network_config_changed(network_type, bridge_name, ip_address, port_forwards)) {
this->reset();
}
}
diff -r 00a162d7e6cd src/qt5/rpc-qt5.h
--- a/src/qt5/rpc-qt5.h Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/rpc-qt5.h Thu May 14 22:15:17 2020 +0100
@@ -69,7 +69,7 @@
void mouse_hack_signal();
void mouse_twobutton_signal();
void config_updated_signal(Config *new_config, Model new_model);
- void network_config_updated_signal(NetworkType network_type, QString bridgename, QString ipaddress);
+ void network_config_updated_signal(NetworkType network_type, QString bridgename, QString ipaddress, QString forwards);
void show_fullscreen_message_off_signal();
public slots:
@@ -102,7 +102,7 @@
void mouse_hack();
void mouse_twobutton();
void config_updated(Config *new_config, Model new_model);
- void network_config_updated(NetworkType network_type, QString bridgename, QString ipaddress);
+ void network_config_updated(NetworkType network_type, QString bridgename, QString ipaddress, QString forwards);
void show_fullscreen_message_off();
private:
diff -r 00a162d7e6cd src/qt5/rpcemu.pro
--- a/src/qt5/rpcemu.pro Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/rpcemu.pro Thu May 14 22:15:17 2020 +0100
@@ -1,6 +1,6 @@
# http://doc.qt.io/qt-5/qmake-tutorial.html
-CONFIG += debug_and_release
+CONFIG += debug_and_release dynarec
QT += core widgets gui multimedia
diff -r 00a162d7e6cd src/qt5/settings.cpp
--- a/src/qt5/settings.cpp Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/settings.cpp Thu May 14 22:15:17 2020 +0100
@@ -182,6 +182,8 @@
} else {
config->network_capture = NULL;
}
+
+ config->network_port_forwards = strdup(settings.value("forward_ports", "").toString().toUtf8().data());
}
@@ -259,4 +261,9 @@
if (config->network_capture) {
settings.setValue("network_capture", config->network_capture);
}
+
+ if (config->network_port_forwards) {
+ settings.setValue("forward_ports", config->network_port_forwards);
+ }
+
}
diff -r 00a162d7e6cd src/rpcemu.c
--- a/src/rpcemu.c Wed May 06 20:17:33 2020 +0100
+++ b/src/rpcemu.c Thu May 14 22:15:17 2020 +0100
@@ -91,6 +91,7 @@
0, /* cpu_idle */
1, /* show_fullscreen_message */
NULL, /* network_capture */
+ NULL, /* port fowards */
};
/* Performance measuring variables */
diff -r 00a162d7e6cd src/rpcemu.h
--- a/src/rpcemu.h Wed May 06 20:17:33 2020 +0100
+++ b/src/rpcemu.h Thu May 14 22:15:17 2020 +0100
@@ -138,6 +138,7 @@
int cpu_idle; /**< Attempt to reduce CPU usage */
int show_fullscreen_message; /**< Show explanation of how to leave fullscreen, on entering fullscreen */
char *network_capture; ///< Path to capture network traffic file, or NULL to disable
+ char *network_port_forwards; ///< Space-separated port forwards in the form: <tcp|udp>:hostport:roport
} Config;
extern Config config;
Attached in a small patch that lets you forward ports from your host
machine through to your RISC OS guest when using NAT networking mode.
I have added a new config option in rpc.cfg, called forward_ports with
the following syntax:
<tcp|udp>:host_port:riscos_port[ ...]
So, say you are running a web server listening on HTTP (port 80) and
HTTPS (port 8443), you might say:
forward_ports=tcp:8080:80 tcp:8443:443
This will mean anything connecting to port 8080 on your host machine
will be proxied through to port 80 inside RISC OS. and the same for
8443 to 80. Note that under most UNIX systems you will need extra
permissions (ie, root) to forward host ports <= 1024.
The parser will log with user-friendly messages if you get the syntax
wrong (unknown protocol, unparsable number, etc) and point a little
arrow at where the problem is.
I have added a suitable but primitive text entry box to the Networking
Configuration dialogue. I did not enjoy this bit: GUI programming and
configuration dialogue state machines are terrible things.
B.
--- a/src/network-nat.c Wed May 06 20:17:33 2020 +0100
+++ b/src/network-nat.c Thu May 14 22:15:17 2020 +0100
@@ -146,6 +146,75 @@
network_hwaddr[5] = 0x06;
}
+static void
+network_add_port_forwards(Slirp * restrict slirp, char * restrict portspec, struct in_addr *ros_addr)
+{
+ char *port = portspec;
+
+ rpclog("Networking: Parsing port forward string %s\n", portspec);
+
+#define ERR_POINT(line, pos) do { \
+ char *buf = malloc(pos + 2); \
+ rpclog(" %s\n", line); \
+ if (buf != NULL) { \
+ memset(buf, ' ', pos); \
+ buf[pos] = '^'; \
+ buf[pos + 1] = '\0'; \
+ rpclog(" %s\n", buf); \
+ free(buf); \
+ } \
+} while (0)
+
+ while (port && *port != '\0') {
+ int is_udp = 0;
+ int host_port = 0;
+ int ros_port = 0;
+ int rv = 0;
+ struct in_addr bind;
+
+ bind.s_addr = 0;
+
+ if (strncmp(port, "udp:", 4) == 0) {
+ is_udp = 1;
+ } else if (strncmp(port, "tcp:", 4) != 0) {
+ rpclog("Networking: bailing parsing port forwards, unknown protocol:\n");
+ ERR_POINT(portspec, port - portspec);
+ return;
+ }
+
+ port += 4;
+
+ host_port = strtol(port, &port, 0);
+ if (host_port == 0) {
+ rpclog("Networking: bailing parsing port forwards, invalid host port:\n");
+ ERR_POINT(portspec, port - portspec);
+ return;
+ }
+
+ /* skip colon */
+ port++;
+ ros_port = strtol(port, &port, 0);
+ if (ros_port == 0) {
+ rpclog("Networking: bailing parsing port forwards, invalid RISC OS port:\n");
+ ERR_POINT(portspec, port - portspec);
+ return;
+ }
+
+ while (*port != '\0' && *port == ' ') {
+ port++;
+ }
+
+ rpclog("Networking: forwarding host %s port %d to RISC OS port %d\n",
+ is_udp ? "UDP" : "TCP", host_port, ros_port);
+
+ rv = slirp_add_hostfwd(slirp, is_udp, bind, host_port, *ros_addr, ros_port);
+ if (rv != 0) {
+ rpclog("Networking: unable to forward: %d\n", rv);
+ }
+ }
+#undef ERR_POINT
+}
+
/**
*/
static void
@@ -172,7 +241,8 @@
net_addr, mask, host, vhostname, "", bootfile, dhcp, dns, NULL);
// TODO log NAT details
- }
+ network_add_port_forwards(nat.slirp, config.network_port_forwards, &dhcp);
+ };
}
int
@@ -195,6 +265,8 @@
}
}
+
+
return 1;
}
diff -r 00a162d7e6cd src/network.c
--- a/src/network.c Wed May 06 20:17:33 2020 +0100
+++ b/src/network.c Thu May 14 22:15:17 2020 +0100
@@ -207,11 +207,12 @@
* @param networktype New network type value
* @param bridgename String of new bridgename value (zero terminated), caller owns (copy taken)
* @param ipaddress String of new ipaddress value (zero terminated), caller owns (copy taken)
+ * @param forwards String of new forwards value (zero terminated), caller owns (copy taken)
* @return Non-zero if these config changes require an emulator restart
*/
int
network_config_changed(NetworkType network_type, const char *bridgename,
- const char *ipaddress)
+ const char *ipaddress, const char *forwards)
{
int restart_required = 0;
@@ -272,6 +273,32 @@
}
}
+ if (forwards == NULL && config.network_port_forwards != NULL) {
+ /* Forwarding is being turned off */
+ free(config.network_port_forwards);
+ config.network_port_forwards = NULL;
+ if (config.network_type == NetworkType_NAT) {
+ restart_required = 1;
+ }
+ } else if (forwards != NULL && config.network_port_forwards == NULL) {
+ /* Forwarding is being turned on */
+ config.network_port_forwards = strdup(forwards);
+ if (config.network_type == NetworkType_NAT) {
+ restart_required = 1;
+ }
+ } else {
+ if (forwards != NULL && config.network_port_forwards != NULL &&
+ strcmp(forwards, config.network_port_forwards) != 0)
+ {
+ /* Forwarding changed */
+ free(config.network_port_forwards);
+ config.network_port_forwards = strdup(forwards);
+ if (config.network_type == NetworkType_NAT) {
+ restart_required = 1;
+ }
+ }
+ }
+
// Save the settings to the rpc.cfg file
config_save(&config);
diff -r 00a162d7e6cd src/network.h
--- a/src/network.h Wed May 06 20:17:33 2020 +0100
+++ b/src/network.h Thu May 14 22:15:17 2020 +0100
@@ -46,7 +46,7 @@
void strcpyfromhost(uint32_t dest, const char *source);
int network_config_changed(NetworkType networktype, const char *bridgename,
- const char *ipaddress);
+ const char *ipaddress, const char *forwards);
int network_macaddress_parse(const char *macaddress, uint8_t hwaddr[6]);
/* Functions provided by each host platform's network code */
diff -r 00a162d7e6cd src/qt5/network_dialog.cpp
--- a/src/qt5/network_dialog.cpp Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/network_dialog.cpp Thu May 14 22:15:17 2020 +0100
@@ -57,6 +57,14 @@
tunnelling_hbox->addWidget(tunnelling_label);
tunnelling_hbox->addWidget(tunnelling_name);
+ forwards_label = new QLabel("Port forwards");
+ forwards_name = new QLineEdit(QString("tcp:8080:80"));
+ forwards_name->setMinimumWidth(192);
+ forwards_hbox = new QHBoxLayout();
+ forwards_hbox->insertSpacing(0, 48);
+ forwards_hbox->addWidget(forwards_label);
+ forwards_hbox->addWidget(forwards_name);
+
// Create Buttons
buttons_box = new QDialogButtonBox(QDialogButtonBox::Ok | QDialogButtonBox::Cancel);
@@ -65,6 +73,7 @@
vbox = new QVBoxLayout(this);
vbox->addWidget(net_off);
vbox->addWidget(net_nat);
+ vbox->addLayout(forwards_hbox);
vbox->addWidget(net_bridging);
vbox->addLayout(bridge_hbox);
@@ -117,6 +126,14 @@
tunnelling_label->setEnabled(false);
tunnelling_name->setEnabled(false);
}
+
+ if (net_nat->isChecked()) {
+ forwards_label->setEnabled(true);
+ forwards_name->setEnabled(true);
+ } else {
+ forwards_label->setEnabled(false);
+ forwards_name->setEnabled(false);
+ }
}
/**
@@ -125,8 +142,8 @@
void
NetworkDialog::dialog_accepted()
{
- QByteArray ba_bridgename, ba_ipaddress;
- char *bridgename, *ipaddress;
+ QByteArray ba_bridgename, ba_ipaddress, ba_forwards;
+ char *bridgename, *ipaddress, *forwards;
NetworkType network_type = NetworkType_Off;
// Take a copy of the existing config
@@ -161,7 +178,7 @@
// Update network config in emulator thread
emit this->emulator.network_config_updated_signal(network_type,
- bridge_name->text(), tunnelling_name->text());
+ bridge_name->text(), tunnelling_name->text(), forwards_name->text());
ba_bridgename = bridge_name->text().toUtf8();
bridgename = ba_bridgename.data();
@@ -169,6 +186,9 @@
ba_ipaddress = tunnelling_name->text().toUtf8();
ipaddress = ba_ipaddress.data();
+ ba_forwards = forwards_name->text().toUtf8();
+ forwards = ba_forwards.data();
+
// Apply configuration settings from Dialog to config_copy
config_copy->network_type = network_type;
if (config_copy->bridgename == NULL) {
@@ -183,6 +203,12 @@
free(config_copy->ipaddress);
config_copy->ipaddress = strdup(ipaddress);
}
+ if (config_copy->network_port_forwards == NULL) {
+ config_copy->network_port_forwards = strdup(forwards);
+ } else if (strcmp(config_copy->network_port_forwards, forwards) != 0) {
+ free(config_copy->network_port_forwards);
+ config_copy->network_port_forwards = strdup(forwards);
+ }
}
/**
@@ -235,4 +261,9 @@
if(config_copy->ipaddress && config_copy->ipaddress[0] != '\0') {
tunnelling_name->setText(config_copy->ipaddress);
}
+
+ if(config_copy->network_port_forwards && config_copy->network_port_forwards[0] != '\0') {
+ forwards_name->setText(config_copy->network_port_forwards);
+ }
+
}
diff -r 00a162d7e6cd src/qt5/network_dialog.h
--- a/src/qt5/network_dialog.h Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/network_dialog.h Thu May 14 22:15:17 2020 +0100
@@ -59,6 +59,10 @@
QLineEdit *tunnelling_name;
QHBoxLayout *tunnelling_hbox;
+ QLabel *forwards_label;
+ QLineEdit *forwards_name;
+ QHBoxLayout *forwards_hbox;
+
QDialogButtonBox *buttons_box;
QVBoxLayout *vbox;
diff -r 00a162d7e6cd src/qt5/rpc-qt5.cpp
--- a/src/qt5/rpc-qt5.cpp Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/rpc-qt5.cpp Thu May 14 22:15:17 2020 +0100
@@ -916,7 +916,7 @@
* @param ipaddress
*/
void
-Emulator::network_config_updated(NetworkType network_type, QString bridgename, QString ipaddress)
+Emulator::network_config_updated(NetworkType network_type, QString bridgename, QString ipaddress, QString forwards)
{
QByteArray ba_bridgename = bridgename.toUtf8();
const char *bridge_name = ba_bridgename.constData();
@@ -924,7 +924,10 @@
QByteArray ba_ipaddress = ipaddress.toUtf8();
const char *ip_address = ba_ipaddress.constData();
- if (network_config_changed(network_type, bridge_name, ip_address)) {
+ QByteArray ba_forwards = forwards.toUtf8();
+ const char *port_forwards = ba_forwards.constData();
+
+ if (network_config_changed(network_type, bridge_name, ip_address, port_forwards)) {
this->reset();
}
}
diff -r 00a162d7e6cd src/qt5/rpc-qt5.h
--- a/src/qt5/rpc-qt5.h Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/rpc-qt5.h Thu May 14 22:15:17 2020 +0100
@@ -69,7 +69,7 @@
void mouse_hack_signal();
void mouse_twobutton_signal();
void config_updated_signal(Config *new_config, Model new_model);
- void network_config_updated_signal(NetworkType network_type, QString bridgename, QString ipaddress);
+ void network_config_updated_signal(NetworkType network_type, QString bridgename, QString ipaddress, QString forwards);
void show_fullscreen_message_off_signal();
public slots:
@@ -102,7 +102,7 @@
void mouse_hack();
void mouse_twobutton();
void config_updated(Config *new_config, Model new_model);
- void network_config_updated(NetworkType network_type, QString bridgename, QString ipaddress);
+ void network_config_updated(NetworkType network_type, QString bridgename, QString ipaddress, QString forwards);
void show_fullscreen_message_off();
private:
diff -r 00a162d7e6cd src/qt5/rpcemu.pro
--- a/src/qt5/rpcemu.pro Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/rpcemu.pro Thu May 14 22:15:17 2020 +0100
@@ -1,6 +1,6 @@
# http://doc.qt.io/qt-5/qmake-tutorial.html
-CONFIG += debug_and_release
+CONFIG += debug_and_release dynarec
QT += core widgets gui multimedia
diff -r 00a162d7e6cd src/qt5/settings.cpp
--- a/src/qt5/settings.cpp Wed May 06 20:17:33 2020 +0100
+++ b/src/qt5/settings.cpp Thu May 14 22:15:17 2020 +0100
@@ -182,6 +182,8 @@
} else {
config->network_capture = NULL;
}
+
+ config->network_port_forwards = strdup(settings.value("forward_ports", "").toString().toUtf8().data());
}
@@ -259,4 +261,9 @@
if (config->network_capture) {
settings.setValue("network_capture", config->network_capture);
}
+
+ if (config->network_port_forwards) {
+ settings.setValue("forward_ports", config->network_port_forwards);
+ }
+
}
diff -r 00a162d7e6cd src/rpcemu.c
--- a/src/rpcemu.c Wed May 06 20:17:33 2020 +0100
+++ b/src/rpcemu.c Thu May 14 22:15:17 2020 +0100
@@ -91,6 +91,7 @@
0, /* cpu_idle */
1, /* show_fullscreen_message */
NULL, /* network_capture */
+ NULL, /* port fowards */
};
/* Performance measuring variables */
diff -r 00a162d7e6cd src/rpcemu.h
--- a/src/rpcemu.h Wed May 06 20:17:33 2020 +0100
+++ b/src/rpcemu.h Thu May 14 22:15:17 2020 +0100
@@ -138,6 +138,7 @@
int cpu_idle; /**< Attempt to reduce CPU usage */
int show_fullscreen_message; /**< Show explanation of how to leave fullscreen, on entering fullscreen */
char *network_capture; ///< Path to capture network traffic file, or NULL to disable
+ char *network_port_forwards; ///< Space-separated port forwards in the form: <tcp|udp>:hostport:roport
} Config;
extern Config config;
Attached in a small patch that lets you forward ports from your host
machine through to your RISC OS guest when using NAT networking mode.
I have added a new config option in rpc.cfg, called forward_ports with
the following syntax:
<tcp|udp>:host_port:riscos_port[ ...]
So, say you are running a web server listening on HTTP (port 80) and
HTTPS (port 8443), you might say:
forward_ports=tcp:8080:80 tcp:8443:443
This will mean anything connecting to port 8080 on your host machine
will be proxied through to port 80 inside RISC OS. and the same for
8443 to 80. Note that under most UNIX systems you will need extra
permissions (ie, root) to forward host ports <= 1024.
The parser will log with user-friendly messages if you get the syntax
wrong (unknown protocol, unparsable number, etc) and point a little
arrow at where the problem is.
I have added a suitable but primitive text entry box to the Networking
Configuration dialogue. I did not enjoy this bit: GUI programming and
configuration dialogue state machines are terrible things.
B.
Re: [Rpcemu] Sound Settings - RPCEmu 0.9.3 & RISC OS 3.50
Hi,
> Theo Markettos <theo@markettos.org.uk> wrote:
>
> On Thu, May 14, 2020 at 07:33:33PM +0100, Bryan Hogan wrote:
> > It was a long time ago, but I think I had the 16bit sound upgrade with
> > RISC OS 3.5, but did need to soft load new sound modules to make it work.
> >
> > No idea which modules they were though!
>
> It was probably SoundDMA - so extracting the SoundDMA module from a later
> RISC OS version might be worth a try?
Chris' Acorn has a download for the Acorn 16bit sound upgrade:
http://chrisacorns.computinghistory.org.uk/Software/Acorn_16bitSound.arc
I am fairly sure that I have a floppy for the Mozart upgrade somewhere, but this upgrade had additional features (like 8bit passthrough without the 8-to-16bit conversion overhead which was a big deal when running on a 30MHz ARM610), no idea if this makes the software compatible.
RISC OS 3.6 should automatically support 16bit sound.
Have fun
hubersn
--
Steffen Huber LambdaComm System – Welcome to Trollinger Country
steffen@huber-net.de
Private homepage http://www.huber-net.de/
RISC OS Blog http://riscosblog.huber-net.de/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Sound Settings - RPCEmu 0.9.3 & RISC OS 3.50
On Thu, May 14, 2020 at 07:33:33PM +0100, Bryan Hogan wrote:
> It was a long time ago, but I think I had the 16bit sound upgrade with
> RISC OS 3.5, but did need to soft load new sound modules to make it work.
>
> No idea which modules they were though!
It was probably SoundDMA - so extracting the SoundDMA module from a later
RISC OS version might be worth a try?
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> It was a long time ago, but I think I had the 16bit sound upgrade with
> RISC OS 3.5, but did need to soft load new sound modules to make it work.
>
> No idea which modules they were though!
It was probably SoundDMA - so extracting the SoundDMA module from a later
RISC OS version might be worth a try?
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Fun with easy-start bundles
Hi all !
I liked 'playing' with RISC OS on the Raspberry Pi. Yet it always
remained something of a difficulty, as I always had to manually change
the connection to the screen. And yes, I know there is a possibility to
connect through some sort of remote display. I just never got around to
that.
So, I am VERY pleased with the Easy-Start-Bundles !
Now I can enjoy RISC OS through my main computer setup, which runs
Ubuntu 18.04, with the MATE desktop. And I even get network connection,
out of the box !
Thank you so much for this pleasure !
Just one small remark: starting rpcemu from the command line (after
compiling, of course) was straightforward. Starting it from the
menusystem of the desktop however, was not. It gave an error,
complaining about some files not being present (./roms, for example). I
checked and lo and behold, the roms were present.
So I surmised that the menusystem just didn't change directory in a
clear way. So I made up a little script (called RISCOS5.sh), with the
following content:
#!/bin/bash
#
# A script to start RPCemu with RISCOS 5!
#
cd /home/USER/PROGRAMS/RPCEmu/rpcemu-0.9.3-recompiler-RISCOS5
./rpcemu-recompiler
I made another script (called RISCOS371.sh) for the Easy-Start-Bundle
with RISC OS 3.71, in the same fashion.
Both scripts were saved in a directory called RPCEmu (in my case under
another directory, called PROGRAMS) in my home-folder. Of course these
scripts could be placed anywhere where one has read-and-write access.
After that I just edited the menu-system of Ubuntu MATE, created two new
items in the menu-system and pointed each towards their respective script.
That did it :-)
Both instances of RISC OS emulated through RPCEmu now start from their
own menu-item.
I realize that this is not great programming. Yet, perhaps this might be
helpful for others trying to 'play' with RISC OS on Linux?
Just remember two things about such scripts:
1. adjust the path to where your installation of the compiled rpcemu
resides.
2. make sure the scripts are executable.
Thanks again and keep up the good work !
Sincerely,
Peter Veltmans
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
I liked 'playing' with RISC OS on the Raspberry Pi. Yet it always
remained something of a difficulty, as I always had to manually change
the connection to the screen. And yes, I know there is a possibility to
connect through some sort of remote display. I just never got around to
that.
So, I am VERY pleased with the Easy-Start-Bundles !
Now I can enjoy RISC OS through my main computer setup, which runs
Ubuntu 18.04, with the MATE desktop. And I even get network connection,
out of the box !
Thank you so much for this pleasure !
Just one small remark: starting rpcemu from the command line (after
compiling, of course) was straightforward. Starting it from the
menusystem of the desktop however, was not. It gave an error,
complaining about some files not being present (./roms, for example). I
checked and lo and behold, the roms were present.
So I surmised that the menusystem just didn't change directory in a
clear way. So I made up a little script (called RISCOS5.sh), with the
following content:
#!/bin/bash
#
# A script to start RPCemu with RISCOS 5!
#
cd /home/USER/PROGRAMS/RPCEmu/rpcemu-0.9.3-recompiler-RISCOS5
./rpcemu-recompiler
I made another script (called RISCOS371.sh) for the Easy-Start-Bundle
with RISC OS 3.71, in the same fashion.
Both scripts were saved in a directory called RPCEmu (in my case under
another directory, called PROGRAMS) in my home-folder. Of course these
scripts could be placed anywhere where one has read-and-write access.
After that I just edited the menu-system of Ubuntu MATE, created two new
items in the menu-system and pointed each towards their respective script.
That did it :-)
Both instances of RISC OS emulated through RPCEmu now start from their
own menu-item.
I realize that this is not great programming. Yet, perhaps this might be
helpful for others trying to 'play' with RISC OS on Linux?
Just remember two things about such scripts:
1. adjust the path to where your installation of the compiled rpcemu
resides.
2. make sure the scripts are executable.
Thanks again and keep up the good work !
Sincerely,
Peter Veltmans
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Sound Settings - RPCEmu 0.9.3 & RISC OS 3.50
In message <20200514143430.mnn2ruhtbsbg52q3@chiark.greenend.org.uk>
Theo Markettos <theo@markettos.org.uk> wrote:
> From a glance at the source it looks like RPCEmu only supports 16 bit sound.
> I'm not sure if RISC OS 3.5 supports it. I think originally machines
> shipped with 8 bit sound and upgrading to 16 bit sound required RISC OS 3.6.
It was a long time ago, but I think I had the 16bit sound upgrade with
RISC OS 3.5, but did need to soft load new sound modules to make it work.
No idea which modules they were though!
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Theo Markettos <theo@markettos.org.uk> wrote:
> From a glance at the source it looks like RPCEmu only supports 16 bit sound.
> I'm not sure if RISC OS 3.5 supports it. I think originally machines
> shipped with 8 bit sound and upgrading to 16 bit sound required RISC OS 3.6.
It was a long time ago, but I think I had the 16bit sound upgrade with
RISC OS 3.5, but did need to soft load new sound modules to make it work.
No idea which modules they were though!
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Chocks Away emulation a little speedy
In message <9ECA882A-A98F-4024-8012-D0BF6516002E@gmx.net>
Peter Moore <petemoore@gmx.net> wrote:
> I recently imported my old RISC PC hard drive and am successfully
> emulating it in RPCEmu. Some apps run a little faster that on the original
> hardware, one example is Chocks Away:
AIUI RPCEmu isn't intended to be a cycle accurate emulator. After all,
with so many different models of RiscPC cpu, what speed would it use?
However, if Chocks Away uses the video refresh for its timing, then
changing the RPCEmu refresh rate might help. Maybe try 25Hz?
For games, try Arculator instead - http://b-em.bbcmicro.com/arculator/
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Peter Moore <petemoore@gmx.net> wrote:
> I recently imported my old RISC PC hard drive and am successfully
> emulating it in RPCEmu. Some apps run a little faster that on the original
> hardware, one example is Chocks Away:
AIUI RPCEmu isn't intended to be a cycle accurate emulator. After all,
with so many different models of RiscPC cpu, what speed would it use?
However, if Chocks Away uses the video refresh for its timing, then
changing the RPCEmu refresh rate might help. Maybe try 25Hz?
For games, try Arculator instead - http://b-em.bbcmicro.com/arculator/
Bryan.
--
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Mac patch for 0.9.3
Hello all
Following my recent Mac binary release, please find attached the corresponding patch for 0.9.3.
To apply, unzip the attachment inside the "src" folder and type the following in the Terminal:
patch -p1 -i ./rpcemu-0.9.3-mac-patch-v1.patch
This patch is exactly the same as that for 0.9.2, save that it's been updated to work with the newest source code.
Tim
Following my recent Mac binary release, please find attached the corresponding patch for 0.9.3.
To apply, unzip the attachment inside the "src" folder and type the following in the Terminal:
patch -p1 -i ./rpcemu-0.9.3-mac-patch-v1.patch
This patch is exactly the same as that for 0.9.2, save that it's been updated to work with the newest source code.
Tim
Re: [Rpcemu] Build instructions from RPCEmu
On Thu, 14 May 2020 at 09:24, Peter Moore <petemoore@gmx.net> wrote:
Hi guys,
Are there build instructions for RPCEmu?
On the website
Under the heading 'Documentation'
Peter
Re: [Rpcemu] Sound Settings - RPCEmu 0.9.3 & RISC OS 3.50
On Thu, May 14, 2020 at 10:40:14AM +0100, Rob Heaton wrote:
> I'm using RPCEmu 0.9.3 on Windows 10, with a RISC OS 3.50 ROM.
> I'm having trouble getting sound working, the sound output seems to be
> garbled mess.
>
> Are there some settings that need changing in RISC OS for this?
> I've tried setting the option for 16 bit sound in the RISC OS
> Configuration, but this has made no difference.
> (Using a newer RISC OS ROM, the audio is fine, tested with RISC OS 3.71)
From a glance at the source it looks like RPCEmu only supports 16 bit sound.
I'm not sure if RISC OS 3.5 supports it. I think originally machines
shipped with 8 bit sound and upgrading to 16 bit sound required RISC OS 3.6.
Could you try with RISC OS 3.6?
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> I'm using RPCEmu 0.9.3 on Windows 10, with a RISC OS 3.50 ROM.
> I'm having trouble getting sound working, the sound output seems to be
> garbled mess.
>
> Are there some settings that need changing in RISC OS for this?
> I've tried setting the option for 16 bit sound in the RISC OS
> Configuration, but this has made no difference.
> (Using a newer RISC OS ROM, the audio is fine, tested with RISC OS 3.71)
From a glance at the source it looks like RPCEmu only supports 16 bit sound.
I'm not sure if RISC OS 3.5 supports it. I think originally machines
shipped with 8 bit sound and upgrading to 16 bit sound required RISC OS 3.6.
Could you try with RISC OS 3.6?
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Chocks Away emulation a little speedy
On Thu, May 14, 2020 at 11:22:35AM +0200, Peter Moore wrote:
> Hi guys,
>
> I recently imported my old RISC PC hard drive and am successfully
> emulating it in RPCEmu. Some apps run a little faster that on the
> original hardware, one example is Chocks Away:
>
> https://www.youtube.com/watch?v=9AZIwgOzE1k (note, I made this a private
> video on youtube only available via a direct link)
>
> I'm happy to enable some debug output etc to help diagnose the issue. I'm
> also happy to get involved in making a fix, if anyone can provide some
> guidance/pointers to get me started on how the timings are managed.
> Hi guys,
>
> I recently imported my old RISC PC hard drive and am successfully
> emulating it in RPCEmu. Some apps run a little faster that on the
> original hardware, one example is Chocks Away:
>
> https://www.youtube.com/watch?v=9AZIwgOzE1k (note, I made this a private
> video on youtube only available via a direct link)
>
> I'm happy to enable some debug output etc to help diagnose the issue. I'm
> also happy to get involved in making a fix, if anyone can provide some
> guidance/pointers to get me started on how the timings are managed.
ISTR having a similiar problem with Chocks Away on a SARPC and having to
turn off the cache to make it playable. What version are you using? Mine
was from an Acorn User cover disc.
It may be that either Chocks doesn't support proper timing moderation at
all, or that it needs a later version that does.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] (no subject)
On Thu, May 14, 2020 at 08:01:17AM +0200, dfeugey@ascinfo.fr wrote:
> Le 2020-05-13 22:59, Peter Howkins a écrit :
> It seems as if a large number of these suggestions are "It would be
> better if I could pretend the Host OS wasn't there". RPCEmu is about
> running RISC OS and its applications on the Host, not running Host
> applications under RISC OS, there's such a ludicrous amount of work
> there for so little benefit that I'm not not interested in pursuing
> it.
>
> This subject is going really to far.
> That was just - at first - a suggestion.
>
> CallWin32 did exist and was quite funny. With better security (selected API,
> selected calls, user confirmation, or just a big warning) it could help.
> Le 2020-05-13 22:59, Peter Howkins a écrit :
> It seems as if a large number of these suggestions are "It would be
> better if I could pretend the Host OS wasn't there". RPCEmu is about
> running RISC OS and its applications on the Host, not running Host
> applications under RISC OS, there's such a ludicrous amount of work
> there for so little benefit that I'm not not interested in pursuing
> it.
>
> This subject is going really to far.
> That was just - at first - a suggestion.
>
> CallWin32 did exist and was quite funny. With better security (selected API,
> selected calls, user confirmation, or just a big warning) it could help.
ISTM that these are the kind of things that are traditionally performed by
'integrations' in hypervisors. You install the 'guest additions' in the
guest OS which provides some drivers that hook into the hypervisor and allow
things like seamless mixing of windows between the host and guest desktops.
Such a process has host and a guest components. I don't see a problem if
the interface between host and guest is an API that is clear and
well-defined. For example, HostFS and networking are examples of such an
API. Being bounded, the API would not be able to make arbitrary OS calls
(as CallWin32), and the host side of the API would vet the requests it gets
from the guests to check if they're sensible.
Obviously, opening up any interface offers another attack surface. But a
user could decide whether to open up, say, the 'host printing' interface if
they decide they want to take that risk.
The host side of things would be naturally implemented inside RPCEmu - the
guest side would likely be more of a stub. I assume by Peter not wanting to
define an API he means an API that allow host-side RPCEmu to interface to
other closed-source host-side code. This problem wouldn't arise if the
host-side code was simply integrated into RPCEmu (being open source), and
the patch was rejected if the guest-side code wasn't also open source.
> Now, it's your project. Your choices.
> I did not suggest that to bother you.
> Working around RISC OSs lack of applications in a system emulator of a
> 26 year old piece of hardware is pretty ridiculous.
>
> This time, since RISC OS is used for my business: my choices ;)
> But perhaps I'm ridiculous to use it after all.
I think it depends on your use cases. If your use case is you have some
piece of RISC OS software that you want to run but want to integrate better
with host facilities (eg printing), that's different to if you want to run
(for instance) a game as if the world stopped in 1994. The existence of
such integrations in VRPC suggest that there are people who are interested
in the former.
As ever, this is moot until someone builds such a thing :)
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Chocks Away emulation a little speedy
Your first take off was the best demo of a stall & spin in I've seen for some time 😊
George
George
Sent from my iPhone
> On 14 May 2020, at 10:23, Peter Moore <petemoore@gmx.net> wrote:
>
> Hi guys,
>
> I recently imported my old RISC PC hard drive and am successfully emulating it in RPCEmu. Some apps run a little faster that on the original hardware, one example is Chocks Away:
>
> https://www.youtube.com/watch?v=9AZIwgOzE1k (note, I made this a private video on youtube only available via a direct link)
>
> I'm happy to enable some debug output etc to help diagnose the issue. I'm also happy to get involved in making a fix, if anyone can provide some guidance/pointers to get me started on how the timings are managed.
>
> I had some difficulty building from source, so I posted a separate message about that just now, to keep the two topics separated.
>
> Many thanks in advance!
>
> Pete
> _______________________________________________
> 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
[Rpcemu] Sound Settings - RPCEmu 0.9.3 & RISC OS 3.50
I'm using RPCEmu 0.9.3 on Windows 10, with a RISC OS 3.50 ROM.
I'm having trouble getting sound working, the sound output seems to be garbled mess.
Are there some settings that need changing in RISC OS for this?
I've tried setting the option for 16 bit sound in the RISC OS Configuration, but this has made no difference.
(Using a newer RISC OS ROM, the audio is fine, tested with RISC OS 3.71)
I'm using the RPCEmu-Interpreter version as with RISC OS 3.50 the Recompiler version hangs during bootup.
Other settings are;
Risc PC - ARM610
8MB RAM
2MB VRAM
Sound Enabled
Network Enabled in NAT mode
Any help would be greatly appreciated!
Rob.
[Rpcemu] Chocks Away emulation a little speedy
Hi guys,
I recently imported my old RISC PC hard drive and am successfully emulating it in RPCEmu. Some apps run a little faster that on the original hardware, one example is Chocks Away:
https://www.youtube.com/watch?v=9AZIwgOzE1k (note, I made this a private video on youtube only available via a direct link)
I'm happy to enable some debug output etc to help diagnose the issue. I'm also happy to get involved in making a fix, if anyone can provide some guidance/pointers to get me started on how the timings are managed.
I had some difficulty building from source, so I posted a separate message about that just now, to keep the two topics separated.
Many thanks in advance!
Pete
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Build instructions from RPCEmu
Hi guys,
Are there build instructions for RPCEmu?
I saw this post from 2017 mentioning a configure script, but I couldn't find it in the latest source code:
https://stardot.org.uk/forums/viewtopic.php?t=12751
Many thanks and best wishes,
Pete
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Wednesday, 13 May 2020
Re: [Rpcemu] (no subject)
Le 2020-05-13 22:59, Peter Howkins a écrit :
- Universal print bridge from one only RISC OS PS driver
Are you planning on writing one?
I have one.
Made with a listener on the host side.
It seems as if a large number of these suggestions are "It would be
better if I could pretend the Host OS wasn't there". RPCEmu is about
running RISC OS and its applications on the Host, not running Host
applications under RISC OS, there's such a ludicrous amount of work
there for so little benefit that I'm not not interested in pursuing
it.
This subject is going really to far.
That was just - at first - a suggestion.
CallWin32 did exist and was quite funny. With better security (selected
API, selected calls, user confirmation, or just a big warning) it could
help.
Now, it's your project. Your choices.
I did not suggest that to bother you.
Working around RISC OSs lack of applications in a system emulator of
a
26 year old piece of hardware is pretty ridiculous.
This time, since RISC OS is used for my business: my choices ;)
But perhaps I'm ridiculous to use it after all.
Thanks for all the answers.
Bye, David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] (no subject)
On Wed, 13 May 2020 at 21:02, <dfeugey@ascinfo.fr> wrote:
Le 2020-05-13 20:31, Peter Howkins a écrit :
> For the very same reason a webpage running javascript can't execute
> shell commands or host API calls on your host OS.
>
Not the same. A web browser is a door opened to the outside. Local
applications can do bad things, but inside the limits of the the rights
and ACL you give to them.
I disagree with you. See below for more details.
> Can you explain your use case here, what are you actually trying to
> achieve?
>
- Universal print bridge from one only RISC OS PS driver
Are you planning on writing one?
- USB auto-mounting in new hostfs drives
I'm not yet sure if multiple host mount points is not also a security issue, as such automounters are not on my todo list right now.
- SANE interface in a module
I don't know what you mean by SANE?
If so, use that app on your Host OS
- Local screen definition for dynamic screen resize
This might be interesting, Virtual Box, for example, allows you to resize the Host OS window, and the information is passed onto the emulated OS to resize.
Of course that doesn't require host OS integration, just the rpcemu application to listen on the resize window event.
- x86 (sandboxed) code (for speed)
Or just run the code on your Host OS.
- Launch selected local applications (MP3 playing, etc.)
Just launch them on your Host OS
- Local engines (for example x86 V8 mapped as a module, or BBCBasic x86
as a module)
use a browser or BBCBasic x86 on your Host OS
- Redirection of Qemu's Spice output in RISC OS Windows
... Host OS
- SQL bridge
... Host OS
Etc.
Etc
It seems as if a large number of these suggestions are "It would be better if I could pretend the Host OS wasn't there". RPCEmu is about running RISC OS and its applications on the Host, not running Host applications under RISC OS, there's such a ludicrous amount of work there for so little benefit that I'm not not interested in pursuing it.
Working around RISC OSs lack of applications in a system emulator of a 26 year old piece of hardware is pretty ridiculous.
> It is entirely possible to provide access to host services in a secure
> manner, if they have a defined scope.
>
Of course. I don't ask for some privilege escalation nightmare.
"run any command" or "Call any API" from another machine is the very definition of a privilege escalation nightmare.
At the moment a RISC OS application can access anything in RISC OS at the privilege level of the RISC OS user.
After your suggestion a RISC OS application can access anything in RISC OS at the privilege level of the RISC OS user.and the RISC OS application can also access anything in the Host OS at the privilege level of the Host OS user that has run RPCEmu.
That's an enormous change in scope.
<snip>
If we can extend RPCEmu that way, you won't have to do it yourself. Else
you can plan it too. It'll be even better :)
Note, I also have no interest in creating APIs that will allow closed source extensions to RPCEmu. If you want to contribute to the project, by all means do, but do so in the open.
Peter
Re: [Rpcemu] (no subject)
Le 2020-05-13 20:31, Peter Howkins a écrit :
> For the very same reason a webpage running javascript can't execute
> shell commands or host API calls on your host OS.
>
Not the same. A web browser is a door opened to the outside. Local
applications can do bad things, but inside the limits of the the rights
and ACL you give to them.
> For the very same reason a webpage running javascript can't execute
> shell commands or host API calls on your host OS.
>
Not the same. A web browser is a door opened to the outside. Local
applications can do bad things, but inside the limits of the the rights
and ACL you give to them.
> Can you explain your use case here, what are you actually trying to
> achieve?
>
- Universal print bridge from one only RISC OS PS driver
- USB auto-mounting in new hostfs drives
- SANE interface in a module
- Local screen definition for dynamic screen resize
- x86 (sandboxed) code (for speed)
- Launch selected local applications (MP3 playing, etc.)
- Local engines (for example x86 V8 mapped as a module, or BBCBasic x86
as a module)
- Redirection of Qemu's Spice output in RISC OS Windows
- SQL bridge
Etc.
> It is entirely possible to provide access to host services in a secure
> manner, if they have a defined scope.
>
Of course. I don't ask for some privilege escalation nightmare.
Security can be:
- ACL and strict rights
- confirmation box on the host
- send commands only to a VM, not a host
- predefine the commands you can launch on the host
- IPC with selected / specific x86 apps
If we can extend RPCEmu that way, you won't have to do it yourself. Else
you can plan it too. It'll be even better :)
David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] (no subject)
On Wed, 13 May 2020 at 19:08, <dfeugey@ascinfo.fr> wrote:
Le 2020-05-13 20:01, Peter Howkins a écrit :
> On Wed, 13 May 2020 at 16:36, <dfeugey@ascinfo.fr> wrote:
>
>> Hi.
>>
>> CallWin32 is not very portable, but it would be fun to have QProcess
>>
>> accessible from RISC OS.
>
> No .... just no. Both these things have massive security
> considerations for the host OS.
>
Wich one?
A lot of applications can launch shell commands.
For the very same reason a webpage running javascript can't execute shell commands or host API calls on your host OS.
RPCEmu is a 'sandbox' of executable code. There's a reasonable expectation from users that RISC OS programs shouldn't be able to affect their host code with malware. With host execution privileges, even at 'user' level, RISC OS apps could download malware to host OS and run it there (bittorrent miners, adware, ransom-ware attacks by encrypting the contents of the 'Documents' folder, scanning users files for passwords or financial details).
"But that would never happen!", you are correct, I'm not even going to allow the possibility.
I don't suggest a root access. Just some kind of communication between
RISC OS and the host OS.
If you prefer CallWin32, I prefer too :)
No.
Can you explain your use case here, what are you actually trying to achieve?
It is entirely possible to provide access to host services in a secure manner, if they have a defined scope.
Peter
Re: [Rpcemu] (no subject)
Le 2020-05-13 19:58, Timothy Coltman a écrit :
> https://github.com/Septercius/rpcemu-dev/releases
>
Perfect :)
> https://github.com/Septercius/rpcemu-dev/releases
>
Perfect :)
> Let me know if that works for Jean-Marc.
>
I did ask Jean-Marc to test first the DMG, then the Zip.
Thanks Tim. Great job :)
David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] (no subject)
On Wed, 13 May 2020 at 16:36, <dfeugey@ascinfo.fr> wrote:
Hi.
CallWin32 is not very portable, but it would be fun to have QProcess
accessible from RISC OS.
No .... just no. Both these things have massive security considerations for the host OS.
Peter
Re: [Rpcemu] (no subject)
> For Jean-Marc, all downloads of the current DMG are corrupted (Firefox on macOS). But if zipped, no problem. So I just downloaded the DMG with NetSurf, zipped it with SparkFS and sent it to him for test :)
>
> Could I suggest that you zip the next DMG?
>
> Other problem, Jean-Marc have on old Mac, that can't support Catalina. Your DMG contains an APFS volume image, not a HFS+ one, so it's not possible to open it. Is it possible make some HFS+ DMG for the next update? And also for Jean-Marc, as he would love to test the current version :)
>
> Thanks, David
I've rebuilt the existing DMGs, so they are now in HFS+ format, not APFS (which is what "hdiutil" uses if you don't specify a filing system).
I've also uploaded some ZIPs, which contain the files from the DMGs.
https://github.com/Septercius/rpcemu-dev/releases
Let me know if that works for Jean-Marc.
Tim
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>
> Could I suggest that you zip the next DMG?
>
> Other problem, Jean-Marc have on old Mac, that can't support Catalina. Your DMG contains an APFS volume image, not a HFS+ one, so it's not possible to open it. Is it possible make some HFS+ DMG for the next update? And also for Jean-Marc, as he would love to test the current version :)
>
> Thanks, David
I've rebuilt the existing DMGs, so they are now in HFS+ format, not APFS (which is what "hdiutil" uses if you don't specify a filing system).
I've also uploaded some ZIPs, which contain the files from the DMGs.
https://github.com/Septercius/rpcemu-dev/releases
Let me know if that works for Jean-Marc.
Tim
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] (no subject)
Le 2020-05-13 17:23, Timothy Coltman a écrit :
>> On 13 May 2020, at 16:13, Martin <rinfo@avisoft.f9.co.uk> wrote:
>>
>> On 19 Jan in article
>> <43A04D6E-FF1C-4464-A8BE-D460584F85AD@maemagel.com>,
>> Timothy Coltman <lists@maemagel.com> wrote:
>>>> Because RPCEmu has no mechanism from within it to set up and
>>>> display a Mount.
>>
>>> Perhaps this might be of interest:
>>
>>> https://ibb.co/B3ZYH1D <https://ibb.co/B3ZYH1D>
>>> https://ibb.co/PzNnysk <https://ibb.co/PzNnysk>
>>
>>> (Hopefully the images work - let me know if not.)
>>
>>> It's not ready for public release yet, and it really needs some
>>> people to test it before it gets submitted to the mailing list.
>>
>> That facility would be *very* useful, especially when trying to test
>> something on lots of versions of RISC OS.
>>
>> I only hope it is cross-platform, and not Mac specific?
>>
>
> It will be cross-platform, yes.
>
> Tim
>
Problem(s) found...
>> On 13 May 2020, at 16:13, Martin <rinfo@avisoft.f9.co.uk> wrote:
>>
>> On 19 Jan in article
>> <43A04D6E-FF1C-4464-A8BE-D460584F85AD@maemagel.com>,
>> Timothy Coltman <lists@maemagel.com> wrote:
>>>> Because RPCEmu has no mechanism from within it to set up and
>>>> display a Mount.
>>
>>> Perhaps this might be of interest:
>>
>>> https://ibb.co/B3ZYH1D <https://ibb.co/B3ZYH1D>
>>> https://ibb.co/PzNnysk <https://ibb.co/PzNnysk>
>>
>>> (Hopefully the images work - let me know if not.)
>>
>>> It's not ready for public release yet, and it really needs some
>>> people to test it before it gets submitted to the mailing list.
>>
>> That facility would be *very* useful, especially when trying to test
>> something on lots of versions of RISC OS.
>>
>> I only hope it is cross-platform, and not Mac specific?
>>
>
> It will be cross-platform, yes.
>
> Tim
>
Problem(s) found...
For Jean-Marc, all downloads of the current DMG are corrupted (Firefox
on macOS). But if zipped, no problem. So I just downloaded the DMG with
NetSurf, zipped it with SparkFS and sent it to him for test :)
Could I suggest that you zip the next DMG?
Other problem, Jean-Marc have on old Mac, that can't support Catalina.
Your DMG contains an APFS volume image, not a HFS+ one, so it's not
possible to open it. Is it possible make some HFS+ DMG for the next
update? And also for Jean-Marc, as he would love to test the current
version :)
Thanks, David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] (no subject)
Le 2020-05-13 17:23, Timothy Coltman a écrit :
>
> It will be cross-platform, yes.
>
Hi.
>
> It will be cross-platform, yes.
>
Hi.
CallWin32 is not very portable, but it would be fun to have QProcess
accessible from RISC OS.
David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] (no subject)
> On 13 May 2020, at 16:13, Martin <rinfo@avisoft.f9.co.uk> wrote:
>
> On 19 Jan in article
> <43A04D6E-FF1C-4464-A8BE-D460584F85AD@maemagel.com>,
> Timothy Coltman <lists@maemagel.com> wrote:
>>> Because RPCEmu has no mechanism from within it to set up and
>>> display a Mount.
>
>> Perhaps this might be of interest:
>
>> https://ibb.co/B3ZYH1D <https://ibb.co/B3ZYH1D>
>> https://ibb.co/PzNnysk <https://ibb.co/PzNnysk>
>
>> (Hopefully the images work - let me know if not.)
>
>> It's not ready for public release yet, and it really needs some
>> people to test it before it gets submitted to the mailing list.
>
> That facility would be *very* useful, especially when trying to test
> something on lots of versions of RISC OS.
>
> I only hope it is cross-platform, and not Mac specific?
>
It will be cross-platform, yes.
Tim
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
>
> On 19 Jan in article
> <43A04D6E-FF1C-4464-A8BE-D460584F85AD@maemagel.com>,
> Timothy Coltman <lists@maemagel.com> wrote:
>>> Because RPCEmu has no mechanism from within it to set up and
>>> display a Mount.
>
>> Perhaps this might be of interest:
>
>> https://ibb.co/B3ZYH1D <https://ibb.co/B3ZYH1D>
>> https://ibb.co/PzNnysk <https://ibb.co/PzNnysk>
>
>> (Hopefully the images work - let me know if not.)
>
>> It's not ready for public release yet, and it really needs some
>> people to test it before it gets submitted to the mailing list.
>
> That facility would be *very* useful, especially when trying to test
> something on lots of versions of RISC OS.
>
> I only hope it is cross-platform, and not Mac specific?
>
It will be cross-platform, yes.
Tim
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] (no subject)
On 19 Jan in article
<43A04D6E-FF1C-4464-A8BE-D460584F85AD@maemagel.com>,
Timothy Coltman <lists@maemagel.com> wrote:
> > Because RPCEmu has no mechanism from within it to set up and
> > display a Mount.
> Perhaps this might be of interest:
> https://ibb.co/B3ZYH1D <https://ibb.co/B3ZYH1D>
> https://ibb.co/PzNnysk <https://ibb.co/PzNnysk>
> (Hopefully the images work - let me know if not.)
> It's not ready for public release yet, and it really needs some
> people to test it before it gets submitted to the mailing list.
That facility would be *very* useful, especially when trying to test
something on lots of versions of RISC OS.
I only hope it is cross-platform, and not Mac specific?
Martin
--
Martin Avison using a TiMachine running RISC OS 5
and the Pluto mail and newsreader
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
<43A04D6E-FF1C-4464-A8BE-D460584F85AD@maemagel.com>,
Timothy Coltman <lists@maemagel.com> wrote:
> > Because RPCEmu has no mechanism from within it to set up and
> > display a Mount.
> Perhaps this might be of interest:
> https://ibb.co/B3ZYH1D <https://ibb.co/B3ZYH1D>
> https://ibb.co/PzNnysk <https://ibb.co/PzNnysk>
> (Hopefully the images work - let me know if not.)
> It's not ready for public release yet, and it really needs some
> people to test it before it gets submitted to the mailing list.
That facility would be *very* useful, especially when trying to test
something on lots of versions of RISC OS.
I only hope it is cross-platform, and not Mac specific?
Martin
--
Martin Avison using a TiMachine running RISC OS 5
and the Pluto mail and newsreader
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [gccsdk] DeskLib and GCCSDK
On 13/05/2020 11:00, Steve Fryatt wrote:
> The first, which I would like to sort out before moving on to the rest, is
> that the DeskLib headers installed by the process above contain several
>
> #include "DeskLib:Core.h"
ISTR, that to use DeskLib with the cross compiler, you had to issue the
line:
export DESKLIB_PATH=$GCCSDK_INSTALL_ENV/include/DeskLib
I think this worked due to general support for path variables, where
App:header.h can be accessed by setting
APP_PATH=$GCCSDK_INSTALL_ENV/include/App.
OSLib worked in a similar way until its header includes were changed to
oslib/header.h.
I assume this still works, but I haven't used it in a long time.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> The first, which I would like to sort out before moving on to the rest, is
> that the DeskLib headers installed by the process above contain several
>
> #include "DeskLib:Core.h"
ISTR, that to use DeskLib with the cross compiler, you had to issue the
line:
export DESKLIB_PATH=$GCCSDK_INSTALL_ENV/include/DeskLib
I think this worked due to general support for path variables, where
App:header.h can be accessed by setting
APP_PATH=$GCCSDK_INSTALL_ENV/include/App.
OSLib worked in a similar way until its header includes were changed to
oslib/header.h.
I assume this still works, but I haven't used it in a long time.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] DeskLib and GCCSDK
On Wed, May 13, 2020 at 11:00:48AM +0100, Steve Fryatt wrote:
> The first, which I would like to sort out before moving on to the rest, is
> that the DeskLib headers installed by the process above contain several
>
> #include "DeskLib:Core.h"
>
> lines and similar, which GCCSDK can't sensibly resolve. I can make things
> build to a point where I'm looking at a handful of genuine-looking missing
> or conflicting source files in WinEd by doing a search and replace to remove
> the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
> I'm not sure that this is the right thing to be doing given that the DeskLib
> docs refer to the library being prepped for use in the GCCSDK -- suggesting
> that everything should just work. :-)
Copying in what I suggested on csa.p:
It would be possible, but compilers should be able to handle the canonical
form without source modification. It's especially important if you don't
know if you're cross compiling or not, and makes a mess of eg checking out a
new copy from a source repo or comparing hashes to see if anything changed.
Picking a random piece of RISC OS source:
https://gitlab.riscosopen.org/RiscOS/Sources/Toolbox/Window/-/blob/master/c/events
that does have
#include "objects/toolbox.h"
which indicates that Norcroft is happy with that syntax.
I think therefore the right thing to do would be to patch the headers to be
in the
#include "DeskLib/Wimp.h"
format, and then Makefiles need -IDeskLib:
and the path structure should be !DeskLib.DeskLib.h.Wimp
and in !Boot you have:
*Set DeskLib$Path <Obey$Dir>.
I don't know what others think of this plan?
How much breakage would it cause?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> The first, which I would like to sort out before moving on to the rest, is
> that the DeskLib headers installed by the process above contain several
>
> #include "DeskLib:Core.h"
>
> lines and similar, which GCCSDK can't sensibly resolve. I can make things
> build to a point where I'm looking at a handful of genuine-looking missing
> or conflicting source files in WinEd by doing a search and replace to remove
> the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
> I'm not sure that this is the right thing to be doing given that the DeskLib
> docs refer to the library being prepped for use in the GCCSDK -- suggesting
> that everything should just work. :-)
Copying in what I suggested on csa.p:
It would be possible, but compilers should be able to handle the canonical
form without source modification. It's especially important if you don't
know if you're cross compiling or not, and makes a mess of eg checking out a
new copy from a source repo or comparing hashes to see if anything changed.
Picking a random piece of RISC OS source:
https://gitlab.riscosopen.org/RiscOS/Sources/Toolbox/Window/-/blob/master/c/events
that does have
#include "objects/toolbox.h"
which indicates that Norcroft is happy with that syntax.
I think therefore the right thing to do would be to patch the headers to be
in the
#include "DeskLib/Wimp.h"
format, and then Makefiles need -IDeskLib:
and the path structure should be !DeskLib.DeskLib.h.Wimp
and in !Boot you have:
*Set DeskLib$Path <Obey$Dir>.
I don't know what others think of this plan?
How much breakage would it cause?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Subscribe to:
Posts (Atom)