Re: [Rpcemu] HDF file format

[Peter Howkins]

On Sun, 19 Dec 2021 at 14:34, Justin F  wrote:

>
> There's no justification given in the comments, so I tried to work out a
> reason for it.
>

It was a bug, one that we now have to work around to not make sure lots of
people's disc images don't just stop working.

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] Future potential features

[Peter Howkins]

areAs mentioned in my previous Show email, we have a couple on things we
wanted
to share with people. We demonstrated them at the show, but for those that
couldn't attend, here are the details. These are both work-in-progress
features.

1) A dynamic recompiler targeting the ARM64 instruction set. Whilst at an
   early stage this already shows an impressive speed gain over the
   interpreter version on the same hardware (at the show we used a
   Raspberry Pi 4 with 64bit Linux on).

2) A multi-machine configuration and launcher program. This is ideal for
   people who have multiple copies of RISC OS installed, e.g. for testing
   software under different versions.

   Here is a screenshot:
   https://www.marutan.net/rpcemu/i/romultigui.png

Both these items are unfinished but are being worked on, we don't have any
details as to when they will be completed or which release they will be in.
As things progress further it may help us to ask you to help with the
testing of these items, we will post here again at that time.

Matthew Howkins
Peter Howkins
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.9.4

[Peter Howkins]

A new version of RPCEmu is available, 0.9.4
http://www.marutan.net/rpcemu/


ARM
Performance gains on x86 and x64 dynamic recompiler.

Many of the instructions that were not accelerated on the x64
architecture but were on x86 have now been implemented on x64.

Refactoring of Dynamic Recompiler code.

Many bugfixes.

Accessing CP15 should only be permitted in privileged modes.

Network Address Translation
You can now configure ports to be forwarded between your host
network and RPCEmu. This allows you to host servers under RPCEmu
that can be accessed by other machines on your network.
(Note, this still does not enable the use of ShareFS)

Floppy Disc
Support HFE format floppy disc images. HFE disc images are
lower-level than ADF discs as they can also store the information
required for various copy protection systems. Contributed by
Sarah Walker.

VIDC
If you are not using VRAM you can now use up to 4MB of RAM for
video modes.

Other
Fix the crash on shutdown or reset of RISC OS 5. Based on a
suggestion from Rob Sprowson.

GCC
Compiling with GCC 10 no longer needs a workaround for the common
symbols errors.

Matthew Howkins
Peter Howkins
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu at the RISC OS London Show, 30-10-2021

[Peter Howkins]

At the RISC OS Show, next weekend, in Feltham London, RPCEmu will be having
a stand.

It will be a great chance to catch up with people after a couple of years
and see all the latest projects.

On the RPCEmu stand we will be showing the latest features and also have
demonstrations of two work-in-progress advanced items that are due for
release in the future. [1]

Hope to see you there

Peter

[1] Don't worry too much if you can't make it, I'll post a summary here
afterwards :-)
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu licence and other topics

[Peter Howkins]

> Andrew notes arising:
>
> In your original email you said two blocks of 128 KB.  I *think*
> this should be MB, since RiscPC could in theory do 2x 128MB.
> Stability could be an issue with that on 26bit OSs because
> programs often didn't react well to more than about 140MB.
> However, I doubt that's an issue on RISC OS 5.
>
> Comment on names.  I tend to prefer the "RISCOS4Windows", BUT
> this sounds like RISC OS 4, which is the obsolete 26bit OS.  I
> suppose we need RISCOS5Windows but that doesn't sound good.
>
> Maybe winRISC, macRISC, linRISC?
>
>
RPCEmu is an emulation of a 27 year old computer, its main purpose is to
allow users to run obsolete software. Whether you consider RISC OS 3, 4, 5
or 6 is obsolete, is left as a personal choice.

Peter Howkins
Co-signed by
Matthew Howkins
Sarah Walker

>
A copy of this email has been sent to the RPCEmu mailing list, so that other
developers and users are aware.
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Hide MIPS and AVG

[Peter Howkins]

On Mon, 17 May 2021 at 13:11, Lioh Moeller  wrote:

> is there a way to hide the dynamic MIPS and AVG Display from the titlebar?
>

Not simply, if you are desperate edit src/qt5/main_window.cpp find the
method

MainWindow::mips_timer_timeout()

edit it out and recompile.

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support

[Peter Howkins]

On Tue, 22 Sep 2020 at 18:08, Steven Newbury  wrote:

> On Tue, 2020-09-22 at 17:39 +0100, Peter Howkins wrote:
> > On Tue, 22 Sep 2020 at 16:17, Steven Newbury 
> > wrote:
> > > On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > > > I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> > > > supports a hard-coded data path it doesn't lend itself to
> > > packaging
> > > > for
> > > > system-wide installation on *NIX.  So I've added support for
> > > multiple
> > > > search directories and XDG-BaseDir through libxdg-basedir.
> > > >
> > > Just noticed I didn't finish removing the fixed stack allocated
> > > filename buffers.  Probably not the only issues.  Please let me
> > > know if
> > > there's anything else to fix.
> >
> > Hello Steven, I'm afraid there are fundamental issues with this that
> > means I'm not interested in merging this approach, or any derived
> > from it at this point.
> >
> Anything specific?
>

If I'm reading it right

1) You can no longer run more than one copy of RPCEmu using different
settings
2) You're using XDG data directories that include system paths for things.
This breaks horribly on multi-user systems, users shouldn't be sharing
logs, config files, ide discs, hostfs, cmos files. About the only thing
that could theoretically be shared is the ROM, as it's read-only, but as
it's only one thing I can live with that also being a
per-user-per-configuration thing.
3) You broke windows and macos (but that's a relatively small fix up)
4) By allowing the related config and files for a machine to be stored in
separate directories on a system you lose the ability to keep them grouped
for future multi-machine aware rpcemu (admittedly you wouldn't have been
aware of that).

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] [PATCH] RPCEmu XDG-BaseDir support

[Peter Howkins]

On Tue, 22 Sep 2020 at 16:17, Steven Newbury  wrote:

> On Tue, 2020-09-22 at 16:00 +0100, Steven Newbury wrote:
> > I thought I'd add RPCEmu to my Gentoo overlay, but given it only
> > supports a hard-coded data path it doesn't lend itself to packaging
> > for
> > system-wide installation on *NIX.  So I've added support for multiple
> > search directories and XDG-BaseDir through libxdg-basedir.
> >
> Just noticed I didn't finish removing the fixed stack allocated
> filename buffers.  Probably not the only issues.  Please let me know if
> there's anything else to fix.
>

Hello Steven, I'm afraid there are fundamental issues with this that means
I'm not interested in merging this approach, or any derived from it at this
point.

There are many issues that need to be resolved for systemwide install on
multiple platforms and your method actually adds more problems than it
solves.

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Shut down message

[Peter Howkins]

On Mon, 27 Jul 2020 at 19:16, Dave  wrote:

> Nb: Any particular reason why that message was added in recent versions of
> RPCEmu?
>

Yes.

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.3 Build Failure

[Peter Howkins]

On Wed, 3 Jun 2020 at 15:28, Paul Bell  wrote:

> On Wed, 2020-06-03 at 12:13 +0100, Rob Kendrick wrote:
> > GCC 10?  That
> has apparently changed how multiple symbols defined in
> > different
> sources are dealt with by default, try adding -fcommon to
> > the
> > build
> flags to ld/gcc.
> >
> > The old way was to merge all instances of a global
> variable if they
> > all
> > agreed on initial value (or lack of one).
> >
> >
> Somebody will probably want to go through each global and tidy this
> >
> up.
>


Ta for this, we'll roll the fixes for the next release, in the mean time
the -fcommon is the workaround.

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.3

[Peter Howkins]

On Wed, 20 May 2020 at 14:12, John Rickman  wrote:

> In message  .com>
>       Peter Howkins  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

http://www.marutan.net/rpcemu/easystart.html

Approx 1GB

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Build instructions from RPCEmu

[Peter Howkins]

On Thu, 14 May 2020 at 09:24, Peter Moore  wrote:

> Hi guys,
>
> Are there build instructions for RPCEmu?
>

On the website

http://www.marutan.net/rpcemu/

Under the heading 'Documentation'

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] (no subject)

[Peter Howkins]

On Wed, 13 May 2020 at 21:02,  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?

https://en.wikipedia.org/wiki/Scanner_Access_Now_Easy ?

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.


> 
>
> 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
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] (no subject)

[Peter Howkins]

On Wed, 13 May 2020 at 19:08,  wrote:

> Le 2020-05-13 20:01, Peter Howkins a écrit :
> > On Wed, 13 May 2020 at 16:36,  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
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] (no subject)

[Peter Howkins]

On Wed, 13 May 2020 at 16:36,  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
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Installing to Linux

[Peter Howkins]

On Sun, 10 May 2020 at 21:40, Andrew Hodgkinson 
wrote:

> On 11 May 2020, at 2:25, John McCartney wrote:
>
> [...] interpreter or the dynamic recompiler [...]
> What's the difference and on what basis should I base my
> decision?
>
> The interpreter is slow but accurate, treating each ARM instruction
> sequence it encounters as if it were the for first time and translating
> them over and over. The recompiler tries to remember previously converted
> sequences, which increases speed a great deal but because of the
> complexities of CPUs and the recompilation process, this can reduce
> emulation accuracy and cause problems with some pieces of software.
>
> 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.
>
A bit more info here; I'll try to remember to update the compile pages to
link to what the different builds are.

The most important thing is to report as bugs things that don't work in the
recompiler but do in the interpreter, it's not that the recompiler *can't*
be as accurate, it's just that it isn't. Unreported bugs are much less
likely to get fixed.

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.9.3

[Peter Howkins]

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
   - RISC OS 3.71, an older '26-bit' version of RISC OS, ideal for running
'classic' applications.
  - Both are pre-setup with a large number of applications, tools, and both
ship with !Store and PackMan package managers for installing more.

 - ARM
  - Correct several issues related to the MSR instruction
  - Correct several instruction decoding issues
  - Generate undefined instruction exceptions in the correct places of the
instruction set
  - Implement ARMv4 (StrongARM) Load store extensions
  - Make ARMv4 extensions only available when configured as ARMv4

 - Floppy Discs
  - We now support loading of DOS and Atari 360KB (.img) disc images into
the floppy drives.

 - Other fixes
  - Settings files and CMOS ram files are saved as changes are made to
them, so these settings are retained even if the program is closed
abnormally.


Matthew Howkins
Peter Howkins
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu macOS mouse behaviour

[Peter Howkins]

On Sun, 22 Mar 2020 at 22:55, Andrew Hodgkinson 
wrote:

> That said, under Linux we also
> see the exact same behaviour and the "mousehack" mode plus patch does
> seem to do the trick there too.


This is odd, because in my experience it does work on Linux fine. Except
under one circumstance, if it's a Linux running under VirtualBox there's
virtual box bug that stops it :(

Can you confirm this, or if not please provide info on which Linux distro
you're running under?

It is definitely advantageous to be able
> to access the menu bar and get out of full screen mode in Mac OS, and
> advantageous to be able to thereafter scale the RPCEmu window and have
> the mouse coordinates still correctly mapped.
>

I'm also a bit confused about this one, at least on Windows and Linux, full
screen means you can pretend there's no Host OS there, it's great for games
and the like you're on a real machine. There isn't the menu bar available
(because either the menu bar is over the top of the RISC OS content, or the
RISC OS content has been squished under it?).

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu macOS mouse behaviour

[Peter Howkins]

On Sun, 22 Mar 2020 at 21:15, Timothy Coltman  wrote:

>
> Peter - in full screen (2560x1600), using a RISC OS resolution of 800x600,
> it does seem like I have to move the mouse quite a lot on my desk to get it
> to move a short distance on screen.  Andrew's comment about it not scaling
> between host and RISC OS coordinates does look to be correct.
>

Ah, if it were not clear from previously, full screen is using the full OS
code for mouse handling. As such changing the mouse speed in !Configure
will likely see this speed up to usable.

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu macOS mouse behaviour

[Peter Howkins]

On Sun, 22 Mar 2020 at 09:40, Andrew Hodgkinson 
wrote:

> The root problem is within quite strange (I'm being super polite here)
> mouse handling code.
>

I think the more fundamental issue is that you have issues with your Mac
setup or build system. You are right that two builds with different UUIDs
should not behave differently, but that they do should be investigated. If
I were thinking to diagnose the problem, I'd try the following;

1) Take the working and non working builds to a different Mac and run them
there

 a) If both builds no longer work in full screen, that suggests that Mac OS
stores some meta-data related to UUID and that there's a difference in
settings between the two builds. Finding these settings, understanding them
and possibly setting them on the new build will solve this issue.

 b) If the builds work and don't in the same way as your other Mac, that
suggests there's some hard-coded Mac OS workaround for that particular
UUID. If you can't find out why, the quick and dirty workaround is to set
the new build UUID to the same as the old.

I do not have a Mac so cannot suggest anything more specific than to stop
trying to work around the issue in the RPCEmu code.



However here is a quick mouse code primer for those interested.

RPCEmu uses two different sets of mouse handling code

1) "Capture Mouse" also used in "Full Screen" mode. Data from the Host OS
is fed into the relevant hardware registers (quadrature/ps2) of the IOMD
which RISC OS (or any other OS) interprets and moves its mouse.

The data injected is 'relative' coordinates from the Host OS, the amount
moved since the last time the 'mouse' was polled. Real mice only work on
relative movements as they have no concept of the displays they are running
on.

To do this in RPCEmu, the host mouse pointer is hidden, moved to centre of
the window, each time the mouse is polled the difference from that centre
point is recorded and fed into the emulator, and the mouse moved back to
the centre again. (The mouse keeps being moved back to the centre, as we
only receive Host OS 'mouse move' events if the host pointer is over the
RPCEmu window)

2) "Follow Host Mouse". Known internally (and for very good reason) as
"mousehack". RISC OS specific and whilst considerably better than it was (6
major bugs in the last 10 years) it still may have issues for yet to be
discovered usages of the RISC OS mouse API.

It works by intercepting Mouse SWIs used in RISC OS and directly injecting
results from the Host OS into the return values. It bypasses all of RISC
OS's low level handing of the mouse hardware.

The data injected in the return values of the SWIs are absolute values
(Host units converted for OS units, eigen values, and the fact the Y axis
goes the other way) as those are what the systems calling those SWIs expect.

Please note, "mousehack" still requires the support of the Host OS to move
the Host mouse pointer, as this is used when RISC OS uses a 'mouse bounding
box' such as error boxes that constrain the pointer to the error box.

You correctly note we use a heuristic to determine eigen values for the
display and mouse. Eigen values are entirely a RISC OS concept, the VIDC
hardware doesn't know about them.


Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

[Peter Howkins]

At some point Steffen Huber  wrote:
> I probably got confused by my RISC OS 4.02 installation not detecting
> a networking interface at all, then I read the docs and somehow jumped
> to the wrong conclusion (and after extracting AutoSense content from
> Mercurial, it DID detect the interface, which was probably even more
> confusing looking back now).

This is wrong, or rather you do not need to copy any autosense files in,
since version 0.9.1 (the previous release) the EtherRPCEm module will
automatically create the autosense files in the !Boot directory for you.

Can you tell me the contents of the 'netroms' directory in the RPCEmu
directory (alongside 'hostfs', 'roms', 'poduleroms' etc) there should
be one file 'EtherRPCEm,ffa'.

Can you tell me the output of '*help etherrpcem', it should be version
1.04 (06 Oct 2019) for version 0.9.2.

Can you double check that 'Network Address Translation' is selected in
Settings->Networking... windows. Only because you mentioned that you'd
hit the Bad PC bug on RISC OS 5 restart, this actually caused RPCEmu
to 'crash' out and not save its config (both these things are going
to get looked at).


I can't get networking to work. Neither on Windows 10, nor on Windows 7.
> Neither via WLAN nor via LAN. Neither running as Admin or not. Neither
> via DHCP nor via static IP. Neither with or without active Windows
> firewall. Neither with my usual RISC OS 5 and RISC OS 4 installations
> nor with a fresh reinstall of RISC OS 5.
>
> DHCP gets 10.10.10.10 as IP. Which is certainly not an IP address
> that my only DHCP server in the network would ever supply. Something
> is very wrong here and I am running out of ideas what to try.
>

10.10.10.10 is correct. NAT provides a 10.10.10.x network inside the RPCEmu
binary.
The DHCP server inside the RPCEmu binary will return 10.10.10.10 as the IP
address
to RISC OS.

Check the above advice about the netroms directory, it appears the module
hasn't
been loaded from the there and that your autosense hackery has loaded an
older
version (from your !System).

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.2

[Peter Howkins]

On Sat, 26 Oct 2019 at 12:48, Steffen Huber  wrote:

> Hi Peter,
>
> > Peter Howkins  wrote:
> >
> >
> > A new version of RPCEmu is available, 0.9.2
>
> The new networking guide refers to files inside HostFS in the Network
> directory,


Only in a section labelled "From version 0.9.1 of RPCEmu the following
steps are no longer required",
as such the files arn't included or needed in any version from 0.9.1
onwards.


> however the Windows ZIP and the Source tgz only has a ReadMe
> file inside. No !System, no Autosense.
>

If you read the ReadMe it explains it as well.

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.9.2

[Peter Howkins]

A new version of RPCEmu is available, 0.9.2

http://www.marutan.net/rpcemu/

Changes in this build

- Networking
  We have added a new networking mode, Network Address Translation, that
significantly reduces the effort required to setup.

  - Far fewer configuration steps
  - No need to run as root under Linux
  - No need to install and configure TAP drivers under Windows
  - Works with any host network, wired or wireless
  - Allows you to use DHCP in RISC OS for IP address configuration (if the
version of RISC OS supports it)
  - RPCEmu and RISC OS configuration does not need to be changed when the
host network changes

  Please see the updated network guide for more details;
http://www.marutan.net/rpcemu/manual/network.html
  The EtherRPCEm ethernet driver now implements some statistics for frames
and errors.

- Floppy Discs

 We now support loading of DOS (.img) and ADFS L format (.adl) disc images
into the floppy drives.

- Other fixes

 Fix for crash in RISC OS 6, with 8MB VRAM, in hardware scrolling.

- Windows

 Due to changes in libraries we compile RPCEmu with, RPCEmu is no longer
compatible with or tested with
Windows XP or Windows Vista. The minimum version supported is now Windows 7.

Matthew Howkins
Peter Howkins
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu at the RISC OS London Show, 26-10-2019

[Peter Howkins]

On Mon, 21 Oct 2019 at 19:03, Timothy Coltman  wrote:

>
> On 13 Oct 2019, at 08:56, Richard Torrens (lists) 
> wrote:
> >
> > In article
> > ,
> >   Peter Howkins  wrote:
> >> We have added a third networking mode to RPCEmu that reduces the
> >> configuration to just standard RISC OS configuration.
> >
> > Does this apply to the Mac OS version yet? Is it likely to?
> >
> > It would be useful, but I have decided I can make do without direct
> > network access.
>
> I think it would depend on what the underlying technology is.  If it's
> still TUN/TAP, as with the current release version, then no.  If it's
> something like what was discussed a few months ago (SLIRP?), then maybe.
> Peter, could you provide some enlightenment on this?
>

Yep, it's SLIRP based, in theory it should work on Mac OS. Assuming it's
not too different here, I have managed to also get it to work on FreeBSD
(as well as Linux/Windows) so it's pretty portable.

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu Windows XP and Windows Vista support

[Peter Howkins]

On Fri, 4 Oct 2019 at 17:46, Steffen Huber  wrote:

> Hi Peter,
>
> > Peter Howkins  wrote:
> >
> > Due to needing to remain on a supported version of a library that we use
> to
> > build RPCEmu, future releases of RPCEmu will no longer support Windows
> XP or
> > Windows Vista. We will continue to support the Windows 7, 8 and 10
> families.
>
> Could you go a bit further into the details? Which library? Something big
> like Qt, or something small where alternatives could be found? Last time
> I looked, RPCEmu did not really have much dependencies beyond the main
> toolkit (previously Allegro, now Qt).
>

It is QT, the previous Long Term Support version we were using, 5.6, has
now reached end of life. So I've moved to using the next Long Term Support
one, 5.9.

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu Windows XP and Windows Vista support

[Peter Howkins]

Due to needing to remain on a supported version of a library that we use to
build RPCEmu, future releases of RPCEmu will no longer support Windows XP or
Windows Vista. We will continue to support the Windows 7, 8 and 10 families.

What does this mean in detail?

1) All releases of RPCEmu so far released that do support Windows XP and
Vista will continue to run as they do currently. There is no magic code that
will disable old versions.

2) Previous versions of RPCEmu will continue to be available via the
previous
versions page, probably indefinitely.
 http://www.marutan.net/rpcemu/oldversions.html

3) Future Windows versions of RPCEmu will not be supported on Windows XP and
Vista. While it is theoretically possible they may still work, they will no
longer be tested, may partially work or fail in 'interesting' ways.

4) Bugs that are reported against previous versions on Windows XP and Vista,
that are not also present in the current, will not be investigated.

5) Bugs that are reported against previous versions on Windows XP and Vista,
that are present in the current version, will be investigated but the fixes
will come out in releases that are not compatible with Windows XP or Vista.

6) All good things come to an end, whilst we may be dropping support for
these older OSs, it is still 5 years more support than Microsoft gave the OS
itself.

Peter Howkins
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] Mount other Harddrives

[Peter Howkins]

> Q1) In RPCEmu Is there a way to Mount the Harddrives in the Host machine
> so they can be accessed from the icon bar as can be done in VRPC?

With multiple icons on the iconbar, no. However there is a workaround, but
please read and understand these caveats first

1) The webpage states "and all files used with it should be well backed up
before using them with RPCEmu.", this will now include any folders you
access via hostfs.

2) Due to the different way that windows/linux and RISC OS deal with
filetype information, windows/linux files that do not have a risc os
filetype that are loaded by a risc os app are often assigned one, this will
rename the file on the windows/linux filesystem. As you can imagine
renaming files that are used by windows/linux programs or the system can
render them unusable. (This is the same behaviour as VRPC).

3) If and when it all goes wrong, do not whinge here, you got warned, which
is more than VRPC has ever done.

Instructions

Use the windows filesystem link tool to create a subfolder inside hostfs
that points to a different location on windows.

mklink /d FoldernameinHostFS PathToItemYouWantToLink


Open windows command prompt as administrator

cd c:/path/to/RPCEmu/hostfs
mklink /d C C:\
mklink /d D D:\
mklink /d X X:\

You will now have three directories inside your hostfs root folder that
link directly to the windows drives.

> Q2) I have a portable USB SSD drive (R:), is there a way to either access
> or mount that SSD in RPCEmu.

I believe this should work the same way as above but haven't tested it.

mklink /d R R:\

Peter
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.9.1

[Peter Howkins]

A new version of RPCEmu is available, 0.9.1
http://www.marutan.net/rpcemu/
Changes in this release

User Interface
 - A screenshot can be saved of the current display, by choosing 'Take
   Screenshot...' from the File menu.
 - Entering full-screen mode displays a reminder of how to leave this
   mode. The message can be hidden by ticking the checkbox.
 - Choosing 'Reset' or 'Exit' from the File menu will request confirmation
   before taking the action.
 - The CD-ROM sub-menu has moved to the Disc menu.

Networking
 - The EtherRPCEm driver module now works with RISC OS Select 3 or later
   (4.39 - 6.20).
 - Networking configuration now requires fewer steps to be performed in
   RISC OS as a result of the following changes. The documentation has
   been updated to reflect this.
 - The driver module is now provided directly by the networking
   podule. This means there is no need to install the driver in the Boot
   sequence.
 - The driver module is now 26/32-bit neutral. This means that there is no
   need to install an updated SharedCLibrary for the network driver. Note,
   you may well still need this update for application compatibility.
 - The driver module now auto-installs AutoSense file in Boot sequence.

HostFS
 - The Create-Dir, Rename and Save entry points now return an error if
   part of the path is invalid, instead of saving the file to a wrong
   location.

Keyboard
  - Keys can no longer get 'stuck' if held down when interacting with GUI
menus.

Other fixes
 - Some potential crash scenarios when resetting/exiting have been fixed.

Windows
 - Shift-F10 key-presses are now passed through to the emulated machine,
   instead of invoking the Windows context menu handler.
 - If you are using a keyboard layout with 'dead keys' (e.g.
   US-International) these key presses are now passed through. Dead keys
   are used to compose accented characters, and are not found on the UK
   keyboard layout.
 - The Windows executable has Data Execution Prevention (DEP) enabled.

All the keyboard fixes and the enabling of DEP are based on contributions by
J. Percival.

Matthew Howkins
Peter Howkins
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu at the RISC OS London Show (take 2)

[Peter Howkins]

At this year's RISC OS London Show in just under 2 weeks time, RPCEmu
will be having a stand to demonstrate the latest updates and talk to
people about future plans.

http://www.riscoslondonshow.co.uk/

The show is in Feltham, west London and is easily accessible via
public transport and the motorway network.

Join us and bring your questions and suggestions!

Peter

ps My apologies if you are receiving a message like this twice, there
were some issues with the mailing list sending mails to some
addresses, and it seems a good excuse to post this again to test it.

___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu at the RISC OS London Show, 27/20/2018

[Peter Howkins]

At this year's RISC OS London Show in just over 2 weeks time, RPCEmu
will be having a stand to demonstrate the latest updates and talk to
people about future plans.

http://www.riscoslondonshow.co.uk/

The show is in Feltham, west London and is easily accessible via
public transport and the motorway network.

Join us and bring your questions and suggestions!

Peter

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 — Networking issues

[Peter Howkins]

I installed Ubuntu 18.04 and have got networking working using the
current instructions on the site.

However there is one setting you could have missed that can cause the
error you're seeing, in the RISC OS Internet configuration Name Server
configuration window.

https://www.marutan.net/rpcemu/manual/net-ro-tun.html
https://www.marutan.net/rpcemu/manual/i/ro-tun-7.png

Make sure you have a value in "Host name" and "Local domain", they can
be anything you like, and reboot. If not set to something then
namelookups fail in the manner you describe even if the "Primary name
server" value is set correctly.

Peter

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0 — Networking issues

[Peter Howkins]

On Wed, 30 May 2018 at 16:30, David Gee  wrote:

> I'm trying to get networking working on RPCEmu 0.9.0, running under
> Ubuntu 18.04/Gnome. I've followed the steps given for IP tunnelling, and
> everything responds correctly, except for the last phase: I can ping the
> router (192.168.0.1) but if I try 'ping www.marutan.net', I get 'unknown
> host www.marutan.net'.

> I've tried this with the name server set to 192.169.0.1

I presume you meant to type 192.168.0.1 here.

> and I've also
> tried setting this to 8.8.8.8 (Google public DNS), but that makes no
> difference, even though I can ping 8.8.8.8.

That you can ping by IP address proves your networking is up, but the lack
of name resolution means that DNS is failing.

Can you post your rpclog.txt file please, and I'll try to reproduce your setup.

Peter

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.9.0

[Peter Howkins]

On Mon, 7 May 2018 at 11:25, Steve Fryatt <li...@stevefryatt.org.uk> wrote:
> However... There seem to be problems with Full Screen mode on older
versions
> of Ubuntu which are Unity-based.

> Full Screen works fine on my desktop system, running Gnome-based GUbuntu
> 16.04, but on my laptop, which is still on Unity-based Ubuntu 14.04,
> full-screen just makes the window into one which can't be moved or
expanded.
> All of the window furniture is still visible, as are the Unity menu bar
and
> quick launch bar. The RISC OS iconbar is therefore lost off the bottom of
> the Linux screen.

I've had a web search around the issue and I think you might have run into
a Unity issue.

Could you test on this machine with a different window manager to confirm?

Unfortunately if this is an issue with Unity I do not think that it will be
fixed by Canonical, as you mention they've moved over to gnome.

Peter


-- 
Peter Howkins
peter.howk...@marutan.net
https://www.marutan.net/

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.102

[Peter Howkins]

On Mon, 26 Mar 2018 at 04:00, J Percival  wrote:

> Good to hear! I had a feeling it was Qt-related.


A quick update to let you know that a work-around in qt was discovered and
is included in the recent 0.9.0 release of RPCEmu. As such the escape key
works.

Peter

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.9.0

[Peter Howkins]

A new version of RPCEmu is available, X.X.X

http://www.marutan.net/rpcemu/

The two major changes in version 0.9.0 compared to previous versions.

  * Changed to the Qt5 library for the GUI. Previously we used the Allegro 4
library and additional win32 code.
   - The GUI is shared by all platforms, reducing maintenance work.
   - The Linux/BSD builds gain the full GUI that previously was Windows only.
   - The full-screen mode should no longer crash.
   - The full-screen mode uses software scaling. It will no longer resize
your
 host OS desktop and it preserves the aspect ratio of the emulator video
 modes.
   - The clock "drift" (where host and emulated clock move apart) should be
 gone. As such we no longer enable the SyncClock module by default.
However
 if this is causing you an issue please report it.
  * Changed the threading model of the program so that the GUI is in a
separate
thread from the emulation of the machine.
   - The most obvious change from this is that opening menus and configure
 windows does not halt the emulation of the machine while you work with
 them.

Additional fixes in version 0.9.0

  - Linux: Support being built as a position independent executable (PIE),
this
allows the 64-bit recompiler builds to work without modification on Linux
distributions which compile all software as PIE by default (e.g. Ubuntu
16.10 and later)
  - Windows: HostFS date stamps should be correct regardless of Daylight
Savings Time flag.
  - ARM Core: STM with store of R15 should vary with processor type (x86
recompiler).
  - ARM Core: STRT/STRBT with store of R15 should store same value as
STR/STRB.
  - The mouse will work when changing between A7000 and RPC models without
having to rerun RPCEmu.
  - In 'Follow host mouse' mode, enabled support for OS_Word 21,3 'Move
Mouse',
also supports BBC BASIC 'MOUSE TO'.
  - In 'Follow host mouse' mode, the mouse should work correctly if you
change
to fullscreen, change RISC OS mode and leave fullscreen again.
  - Clang compiler is now recognised when writing to the log file.

A special thanks to the members of the RPCEmu mailing list who helped with
testing these wide-ranging changes.


Matthew Howkins
Peter Howkins

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.102

[Peter Howkins]

On 24 March 2018 at 09:31, J Percival  wrote:

> I think I've managed to reproduce the issue with the 'Escape' key. Seems
> to be related to the menus.
>
> Case 1: Select a menu option, say 'File' then another, say 'Disc' straight
> after (i.e. with the menu bar still selected). Escape key no longer
> functions.
> Case 2: Select a menu option, and hit escape to deselect the option and
> then again for the menubar itself. Likewise.
>
> Windows 10 / Recompiler
>
>
I want to let you know that we've already fully reproduced the 'escape' key
issue now. Yes it is related to menus, when you have one menu open and move
to a second menu. After minimizing the bug the issue has now been narrowed
down to a Qt bug and has been reported to them, we're currently waiting a
little to see what their response will be.

Peter
___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu pre release test version 0.8.102

[Peter Howkins]

This is the fourth test release of RPCEmu based on the wide ranging 
chnages made for qt5.

https://www.marutan.net/rpcemu/testing/
 
Please test this version as thoroughly as possible, and if you previously 
reported an issue with 0.8.101 and it is listed below, please test and 
confirm it is fixed.

 - In 'Follow host mouse' mode, the mouse should work correctly if you 
   change to fullscreen, change RISC OS mode and leave fullscreen again.
 - Several fixes to the implementation of 'Follow host mouse' 'Move 
   Mouse' feature (introduced in 0.8.101). An off by one in the Y axis 
   fixed, and it should now work in rectangular pixel modes (such as mode 12).
 - Following reports of the escape key not working in previous versions 
   this appears to be resolved now. However, YOU MUST REPORT ANY INSTANCES 
   OF THE ESCAPE KEY NOT WORKING.

For further information and downloads please visit

https://www.marutan.net/rpcemu/testing/

Matthew Howkins
Peter Howkins

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Emulate other ARM processors?

[Peter Howkins]

On Thu, Mar 01, 2018 at 04:20:58PM +, Gerald Holdsworth wrote:
> Probably a stupid question, but, I’ve been thinking recently, how difficult
> would it be to extend the RPCemu emulation to emulate the ARM2, ARM250, 
> and ARM3 processors in order to run Arthur, RISC OS 2 and RISC OS 3 in 
> (and, effectively, emulate an Archimedes)?

It's a large amount of work for archimedes support, of which the ARM is 
the relatively easy bit.

I've considered it, but it's a long long way from happening anytime soon.

> Didn’t RPCemu evolve from Arculator, originally?

I think it might have been the other way round, though I'm not sure. They 
both shared a large chunk of code.

In general, stick to Arculator, if it does what you want it too.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.101

[Peter Howkins]

On Tue, Feb 06, 2018 at 03:36:14PM +, J Percival wrote:
>Thanks for the new test-version.
>I tested the 'MOUSE TO' behaviour and got some strange results.
>RO3.71, RPC SA, Windows 10, Interpreter (or Recompiler it seems) with
>default settings.
> 
>There seems to be a few problems:
>- If the host mouse pointer goes outside of the client window (or even on
>an edge sometimes) then MOUSE TO no longer has any effect

I suppose I should have noted this, but this was intentional. E.g. if 
you're happilly using your host mouse on another host program on the 
other side of the screen, rpcemu won't steal the mouse from you.

So the mouse needs to be over the rpcemu window for it to work.

>  and this can be
>caused by the command itself (e.g. to 0,0)

However, this was caused by an off by one bug in the os unit to host 
coordinate conversion, fixed.

>- In some modes the emulated pointer is in the right position but the host
>pointer sometimes moves to the bottom of the window (but at the correct x
>coordinate) (e.g. 28)
>- In other modes the emulated pointer ends up in the wrong vertical
>position (e.g. 15)

There were two other bugs here related to doublesizing up rectangular 
pixel modes, both now fixed.

Many thanks for your test program, it helped a lot in reproducing the 
issues.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.101

[Peter Howkins]

On Sat, Feb 17, 2018 at 11:13:00PM +0100, andre timmermans wrote:
> 
>Wish list:
> 
>- Extension in the config file to specify rom name path for hosfs & .hdf
>files. This would make it easier to switch to different OS versions
>(different ROMs, !Boot and compatible applications).

Hi Andre, thanks for the testing, on this matter I have an idea for a more 
comprehensive change to the way models are configured. But this will be 
in several releases time as there is prep work to support it first.

>- Possibility to access the other folders/discs of the host system without
>risk of modifying the file extension of the files (i.e. using mimemap like
>Win95FS or LanManFS). I make sense for documents to be readable on both
>sides without having constantly add and remove the ",xxx" filtype to the
>filename's extension.

This I suspect will never happen, it's difficult enough to create a 
filesystem that's RISC OS compliant without the extra headache of being 
compatible with a variety of host OSes requirements too. This is mainly 
due to my extremely poor experiences with the highly configurable hostfs 
provided with red squirrel and various versions of Virtual Acorn where 
they ended up not even being compatible with each other.

>Issues:
> 
>- ESC key not working

I have noticed this too occasionally, but have not been able to reproduce 
recently. When I did have it failing, it worked for a while then 
failed later. As such if you have any advice on how to reproduce it, 
please let me know.
 
>- when switching back to windowed mode the mouse on the RISC OS side
>cannot reach the top (I think it only occurs if the RISC OS resolution is
>not the same on exit of full-screen mode qs on entry),

Oh well spotted, this is not a new bug, but caused by needing to implement 
part of 'follows host mouse' even when not using that (fullscreen mode 
does not use 'follows host mouse'. There will be a fix for this in the 
next version.

>- sound is easely interrupted by disk accesses.

Annoyingly this is associated with the other fix of reducing the 'lag' in 
the sound you mentioned. I need to do a proper fix by triggering the sound 
interupts when data in consumed rather than just on a timer. However this 
is not going to be fixed by the next release version. There is a 
workaround (and you are allowed to be annoyed by me suggesting it) in that 
if you run it on a faster processor the timers smooth out and you get 
stutter free sound, it's not a great solution :)

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu pre release test version 0.8.101

[Peter Howkins]

This is the third test release of RPCEmu based on the wide ranging 
changes made for qt5.
 
https://www.marutan.net/rpcemu/testing/
 
Please test this version as thoroughly as possible, and if you previously 
reported an issue with 0.8.100 and it is listed below, please test and 
confirm it is fixed.

 - Windows - pass 'alt' key onto emulator correctly.
 - Windows - Re-enabled networking.
 - In 'Follow host mouse' mode enable support for OS_Word 21,3 'Move 
   Mouse', also supports BBC BASIC 'MOUSE TO'.
 - In 'Follow host mouse' mode, the mouse is now capped to the bounding 
   box (e.g. an error box), restoring the 0.8.15 behaviour.
 - Re-enable writing the configuration file to the log file to assist in 
   debugging.

For further information and downloads please visit

https://www.marutan.net/rpcemu/testing/

Matthew Howkins
Peter Howkins

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

[Peter Howkins]

On Tue, Jan 02, 2018 at 03:01:37AM +, J Percival wrote:
>Hi, I did a little more experimentation to see exactly at what point
>RiscOS locks up when running the universal-boot-2 sequence under the
>recompiler.
>It seems to be on execution of !Boot.Utils.BootVars so probably a bug in
>the recompiler code.

To let you know we have reproduced this and are investigating. Initial 
looks says it's not a quick fix (nor a regression in 0.8.100), as such 
it's unlikely to be fixed before the next release version and the 
workaround of choosing 'StrongARM' is probably a good idea here.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] BASIC mouse-pointer issue

[Peter Howkins]

On Sat, Jan 20, 2018 at 03:34:29PM +, J Percival wrote:
>RPCEmu Version: 0.8.15 and later
>Config: RPC-StrongARM/16MB/No VRAM/Sound Enabled
>I'm not sure if this is an emulator bug or not but I've noticed that the
>BASIC "MOUSE TO" command under RO3.71 changes the size of the pointer
>instead of its location - specifically the 'x' argument has no effect and
>the 'y' argument modifies the pointer's height.
>To reproduce:
>MOUSE ON:MOUSE TO 0,20

Thanks for this report, I've been able to reproduce it and am 
investigating. Oddly the reduction in the size of the pointer is related 
to the amount that is offscreen when moving TO the Y coord, e.g. MOUSE TO 
0, 2 means you have an even smaller pointer.

This only affects 'Follow host mouse' mode, so if you need a temporary 
workaround, use 'Capture Mouse' mode by deselecting 'Follow host mouse' 
(0.8.100) or chosing Capture Mouse (0.8.15).

Peter


-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

[Peter Howkins]

On Thu, Jan 04, 2018 at 01:13:58PM +0100, Steffen Huber wrote:
> I had a go at testing 0.8.100.
> 
> I was no longer able to provoke that crash. Thanks for fixing!

Good.

> However, I can half-reliably crash 0.8.100 by doing the following
> (Recompiler, StrongARM, 128MiB, RISC OS 4.02):
> - switch RPCEmu into fullscreen
> - change screenmode to "2560x1440 RPCEmu" 256 colours
> - try to change screenmode to "1920x1080" 32k colour
> - fatal crash
> 
> I had it once that it already crashed when changing to 2560x1440.
> I had it once that it did not crash when switching to 1920x1080,
> but it crashed later when switching between the two screenmodes.
> 
> I have collected the debug files that Windows provides. Let me know
> if you need anything (the MDF?) or if it is also reproducable for
> you. rpclog.txt says nothing.

I will need the MDF for this, also what boot sequence disc setup are you 
using, is it your own? I've not heard of that MDF before.

Also do you know if it was also an issue in 0.8.15?

> 
> Another problem:
> - fullscreen, change screenmode to 2560x1440, go back to window mode,
>   go back fullsctreen -> no longer scaled to available res, but
>   unscaled
> 
> Currently on a dual screen setup in Windows with 2x 1920x1200.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

[Peter Howkins]

On Sun, Dec 31, 2017 at 02:05:45PM +, J Percival wrote:
>Also just noticed that HostFS access crashes the recompiler except for
>CPU=StrongARM but it's not a regression as it does so in 0.8.15 as well.

Erm, this doesn't happen here, as such let's try to reproduce it.

- What do you mean by crash? Emulator exits? with or without error 
  message? emulator stops running (lock up)? Error reported in RISC OS? 
  something else?
- At which point does the 'crash' happen, on boot? on accessing a 
  particular file? something else?
- Which version of RISC OS are you running?
- What files have you put in HostFS, a boot sequence? which? something 
  else?
- What settings are you using for, memory, vram?

Can you also post your rpc.cfg and rpclog.txt files.

>Think you must already be aware of it

This isn't directed at you particulaly, but to all users of rpcemu.

We really really need people to report all the bugs they find, there are 
so many potential configurations and pieces of software out there that we 
can't run everything, as such the chances are that we're not aware of it.

But every good bug report stands a very good chance of being fixed which 
makes everyone's life a little better.

Even if you figure out a workaround (e.g. change setting to something 
else) please still report the original issue.

> is there a list of known issues somewhere?

There isn't at the moment, I'll look into adding one.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.100

[Peter Howkins]

On Sun, Dec 31, 2017 at 12:56:59PM +, J Percival wrote:
>All fixes mentioned on the webpage seem to work except for the
>Alt-Handling. The menus are no longer accessed accidentally but it seems
>the key is now also ignored in the emulated system.
>I noticed this when trying to strafe in !Doom but it's easier to see just
>by pressing F12 from RiscOS and hitting Alt-A which should produce an 'ae'
>character.

OK, I think I have a fix for this, when blocking the alt effect in windows 
I wasn't also passing the key onto the emulator.

I've not got Doom to hand to test, but the 'ae' thing is working.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu pre release test version 0.8.100

[Peter Howkins]

This is the second test release of RPCEmu based on the wide ranging 
changes made for qt5.

https://www.marutan.net/rpcemu/testing/

Please test this version as thoroughly as possible, and if you previously 
reported an issue with 0.8.99 and it is listed below, please test and 
confirm it is fixed.

 - HostFS now working on Windows build.
 - Crash bug caused by dragging window to bottom of screen fixed.
 - Disable some keyboard shortcuts in the frontend. Allows them to be 
   passed to the emulated OS and fixes issue where 'alt' key seemed to get 
   stuck down.
 - Syncclock module not included in default distribution, please check 
   for clock drift.
 - Mouse will work when changing between A7000 and RPC modes without 
   having to rerun RPCEmu.
 - UI will no longer report 'I need to reboot' when changing VRAM 
   settings of machines that don't have VRAM (A7000/A7000+/Phoebe).

For further information and downloads please visit

https://www.marutan.net/rpcemu/testing/

Matthew Howkins
Peter Howkins

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Website problem

[Peter Howkins]

On Sun, Dec 24, 2017 at 05:28:39PM +, J Percival wrote:
>Just noticed that the security certificate seems to have expired on
>[1]https://www.marutan.net/ 

Resolved now.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Questions/issues

[Peter Howkins]

On Mon, Dec 18, 2017 at 03:39:38PM +, J Percival wrote:
>Hi there! Been using this great emulator for a while but have noticed some
>issues. You're probably already aware of them but I thought I would
>mention them anyway. These refer mainly to the 0.8.99 super-secret
>pre-release.
> 
>Setup:
>Windows 10/64-bit
>V0.8.99 Interpreter
>RISC OS 3.71
>Configuration: 2/8MB VRAM, 32MB RAM, Sound Enabled
>- HostFS shows as empty both from the desktop and command line. No
>files/folders added via Windows or RISC OS appear even though it will
>happily create them (ok on 0.8.15). I wondered if it might be a
>permissions issue at first but that doesn't seem to be the case.

It was related to us not setting the correct character encoding in the 
hostfs code, it was trying to use unicode. This has been fixed now.

>- Keyboard handling problem after a menu is accessed via ALT (largely acts
>like ALT gets stuck down afterwards) (ok on 0.8.15).

Yep, we spotted this very weird behaviour too, it's now been fixed.

>- Graphical corruption when configured as RiscPC/ARM810.

This, I'm probably not going to investigated now, as ARM810 is very very 
experimental code ... unless someone wants to give me an arm810 card I can 
test against :)

>- Starting as an A7000 model means mouse doesn't work when switched to a
>RiscPC model and vice versa.

Ooh, well spotted, this is an 6 year old bug. I've got a fix in now. (this 
is a fullscreen/mouse capture issue only, not 'follow host mouse')

>- Configuration options let you try and set VRAM on an A7000 model at
>which point it says it needs to restart (but doesn't do so

I've fixed this issue of the erroneous 'you must restart'.

> and then
>indicates it being present until the emulator is closed and reloaded.
>Maybe it would be better to have separate options provided and saved for
>each machine type.

But I'm not going to fix this now, eventually I have a different idea 
about how machines and models should be setup.

>- In fullscreen mode there doesn't seem to be any way to switch back to
>windowed mode. Selecting the fullscreen option again via ALT-S does
>nothing and the conventional Windows Alt-Enter also has no effect. In
>addition the menu bar doesn't show up when you press ALT, which is a minor
>thing but could definitely confuse some people.

The keyboard shortcut for leaving fullscreen is crtl-end

>Finally, a few difficulties I had with the emulator when I was starting
>out:
>Getting RISC OS up and running was easy enough but the universal-boot
>provided on your website seems to be missing the Shared C Library. I ended
>up using the 'UniBoot 2' version at
>[1]https://www.retro-kit.co.uk/page.cfm/content/UniBoot-for-RISC-OS/
>instead.

I presume you mean the 32-bit Shared C-Library? Which used to live at
http://www.iyonix.com/32bit/system.shtml
now
https://web.archive.org/web/20150412211454/http://www.iyonix.com/32bit/system.shtml

One reason I generally don't provide large amounts of pre-setup stuff as 
theoretically the emulator is just like a real Risc PC in respect to 
allowing people to pick the version of the OS and the software themselves.

Also, it's too hard to support everyone's issues with risc os in general.

>I was then confused why I couldn't change the display mode in RISC OS
>until I eventually remembered that the newer machines rely on monitor
>definition files. Could these perhaps be provided with the emulator?

I believe all the boot sequences include the MDFs?


At some point soon, I'd like to roll a second test version (0.8.100) to 
allow everyone to check their reported bugs are fixed now, and a second 
chance to spot new ones.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.99

[Peter Howkins]

On Sun, Oct 22, 2017 at 12:49:19PM +0200, dfeu...@ascinfo.fr wrote:
> 'Reduce CPU usage' (on RISC OS 5) is almost impossible to use under
> CLI (F12 or no desktop).
> 0,1 MIPS all the time. Even keyboard entries become slow.

Hi David, we've not been able to reproduce this issue yet, can you tell us 
the exact version of RISC OS 5 you are using and can you post the 
rpclog.txt.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.99

[Peter Howkins]

On Sat, Oct 21, 2017 at 10:18:05PM +0200, Steffen Huber wrote:
> Hi Peter,
> 
> > Peter Howkins <rpcemu.howk...@marutan.net> wrote:
> > 
> > 
> > On Sat, Oct 21, 2017 at 12:19:04AM +0200, Steffen Huber wrote:
> > > I did a quick test.
> > > 
> > > Apart from the reported HostFS problem, I encountered a
> > > reproducible crash, with both interpreter and recompiler.

A quick note to say I was able to reproduce it and commit a fix.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.99

[Peter Howkins]

On Sat, Oct 21, 2017 at 12:19:04AM +0200, Steffen Huber wrote:
> I did a quick test.
> 
> Apart from the reported HostFS problem, I encountered a
> reproducible crash, with both interpreter and recompiler.
> 
> I did a full CDVDBurn recompile, which means a lot of I/O.
> I took the taskwindow where the compile ran and put it to
> the bottom of the screen (a few pixels off-screen). I then
> clicked the window resize button and dragged it quickly down
> -> crash. I will try if RPCEmu 0.8.15 also exhibits this.

Hi Steffan, I've not been able to reproduce this crash yet, as such, 
here's a lot of questions.

Does it require the compilation to be happening in the task window or is 
it all the time?
Does it need to be the task window, or any window?
Were you in fullscreen, windowed mode, or does it happen in both?
Which wimp mode are you in, does it happen in other colour depths or 
resolutions?
If you're in windowed mode were you using 'Follow Host Mouse', or the 
capture mode when that is turned off?

 
> I like the new warning dialog that RPCEmu will be reset if you change
> the settings. One minor niggle: the warning dialog is centered to
> the display and not to the RPCEmu window.

I can look into that

> Is it still sensible to have RPC with ARM610 being the default
> machine? Does the recompiler work correctly with this config - ISTR
> reading that it needs StrongARM config to be active?

For the last couple of years the recompiler has supported all the ARM CPU
models. There no speed benefit for StrongARM as we emulate them in the 
same way, so we stick to ARM610 as this is compatible with all versions of
RISC OS from 3.5 onwards.

> Host mouse following mode still exhibits a minor problem when
> e.g. a RISC OS error window moves the RISC OS mouse pointer inside
> the restricted area. It is irritating that the host mouse pointer
> is not also silently moved. On the other hand, I agree that the
> host mouse pointer must not be restricted to the RO pointer
> rectangle.

This has actually changed from 0.8.15 where we did capture the mouse in 
the error box, but as I was changing the code for Qt I couldn't make up my 
mind if this was the correct behaviour. There's not really a good option 
here :(

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu pre release test version 0.8.99

[Peter Howkins]

On Fri, Oct 20, 2017 at 09:38:03PM +0100, Peter Howkins wrote:
> On Fri, Oct 20, 2017 at 10:20:31PM +0200, dfeu...@ascinfo.fr wrote:
> > On Fri, 20 Oct 2017 20:11:55 +0100, Peter Howkins wrote:
> > >https://www.marutan.net/rpcemu/testing/
> > >
> > Hostfs drive not seen (empty) under Windows
> > Both under RISC OS 4 and 5.
> 
> Please post your rpclog.txt file.

Actually don't worry about it, I've traced it to a commit last week.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Networking error

[Peter Howkins]

On Wed, Jun 21, 2017 at 04:10:39PM +, Tony Moore wrote:
> I have installed RPCEmu 0.8.15 / RO 6.20 on Windows 7 Pro 64 bit,
> running on an HP3500 desktop machine. The installation is fine, apart
> from a lack of networking.
> 
> I carefully followed the instructions in the RPCEmu Networking Guide,
> using OpenVPN v2.3.8 to create the TAP driver. Following installation,
> *ifconfig -a , and *show inet* , return believable results, however
> *ping shows no connection.
> 
> >From the log, I note that the TAP driver is 32 bit. Could running this
> on a 64 bit machine lead to the errors?

No, you're using a 64 bit driver on 64 bit windows 'win32' in this context 
is the name of the API we use (which is suitable for both 32 and 64 bit).

I don't have any specific answer to this error. However one previous user 
who had this error indicated that it was due to not having set up the 
network bridge in windows correctly, recheck that section of the 
instructions.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu and Time

[Peter Howkins]

On Sun, Mar 26, 2017 at 12:49:04PM +0100, Dave Symes wrote:
> Last night the spring clock time changes happened.
> 
> RPCEmu 0.8.15 RISC OS 4.02, 4.39, 6.20, 5.23.
> 
> As per usual, for as long as I can remember, ALL my RPCEmu installs that
> use Organizer were Organizer wise FU.
> Organizer failed to run because of some file time stamp failure with its
> files.

Can you describe the exact eror or behaviour you see when running this?

> Wrong! I've discussed this with Martin over the years...

Can you get Marin Avison to describe the issue as he sees it?

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.8.15

[Peter Howkins]

A new version of RPCEmu is available, 0.8.15

http://www.marutan.net/rpcemu/

Note: If compiling on Ubuntu 16.10 or derivatives please see the 
information here. http://www.marutan.net/rpcemu/linuxcompile.html

* All Platforms

  - Issue with 8MB VRAM being less stable has been resolved, code is now
correctly allowed in the 2-8MB area.
  
  - ARM SWP instruction correctly handles unaligned access.

  - Enhancements to TLB to correctly flush caches on more operations.

* Windows

  - The window maximise button has been disabled, as the size of the 
window is determined by the mode in RISC OS.

Note: Using the windows install to upgrade from
  previous versions may overwrite your cmos.ram
  and rpc.cfg files.

Matthew Howkins
Peter Howkins

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Information

[Peter Howkins]

On Mon, Oct 24, 2016 at 01:50:50PM +0200, David Feugey wrote:
>Hi all.
> 
>Several questions.
> 
>Do you know what stretchmode is in rpc.cfg?

Yes, an old alternative way of blitting graphics data to the screen. It is 
now the default, and this option can be ignored.
 
>Is there a way to hide the maximize button?

Nope

>A way to inform RISC OS of the current size of the window would be
>fantastic, but I suppose CallWin32 is not (and will not be) available.

A way for RISC OS to know the dimensions of the host (windows/linux) 
windows including furniture? Taking into account double-sizing modes? I'm 
not really seeing a usecase here, perhaps you can explain why you want 
it? RISC OS itself has APIs for knowing the size of the RISC OS desktop.

>I still have problems with fullscreen mode under windows (crash). Is there
>a way to remove the option?

Edit the code and recompile :) In general though the crash on fullscreen 
is being particulaly annoying to track down, it seemd to only affect 
certain video card manufacturers on specific configurations, it may be an 
allegro bug or an odd race condition. We have a very long term solution 
for it, stay tuned in about 2 years for an update ;)

>Nota: the bug when you change modes is still here (undefined instruction
>when launching new applications after a mode change).

Temp workaround, try configuring 0mb VRAM, there's a fixed bug related to 
code (rather than video data) being in the extended 2->8MB VRAM setting.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Network time

[Peter Howkins]

On Sun, Oct 16, 2016 at 08:48:54PM +0100, Dave Symes wrote:
> Evening folks,
> I need a bit of info please.
> 
> Does RPCEmu pick up network time from the host machine's Windows network
> time?

RPCEmu takes the time from the host machine. How that is set 
(network/manual) is up to you in the host OS.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] rpcemu on Linux Mint

[Peter Howkins]

On Sun, Jul 03, 2016 at 07:18:17PM +0100, Philip wrote:
> Hello there,
> Up to a couple of months ago I had rpcemu 8.13 running happily
> on Mint 17.3. Unfortunately I jiggered my Linux installation, and
> found that the new install of 17.3 would not run rpcemu. As I also
> could run it on LXLE (I have a separate Home partition), I thought I
> would wait until Mint 18 was available to try again.
> Unfortunately, I get "segmentation error" when I try to run
> rpcemu on Mint 18 (cinnamon 64bit). I have made sure that I have the
> liballegro packages installed. Do I need to re-install rpcemu, or is
> there something I have missed?

Are you recompiling RPCEmu for your new system, or just copying the 
compiled binary over from your old system?

In general a recompile is recommended as Linux's binary backwards 
compatibility isn't guaranteed.

Peter


-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Running 1280x1024

[Peter Howkins]

On Mon, Jun 06, 2016 at 01:01:03AM +0100, Reuben Thomas wrote:
>I'm running rpcemu 0.8.14 on an x86_64 GNU/Linux system (Ubuntu 14.04).
>I am using RISC OS 3.71, with StrongARM emulation, 2Mb VRAM selected, and
>32Mb of RAM. I am not using dynrec (I found it unusably unstable) and I
>have "reduce CPU usage" selected.

The dynarec issue and the one you mention below are probably the same 
thing ...

>I am running happily in 1024x768x256 colours. I have the (apparently
>default) AKF85 monitor selection.
>When I switch to 1280x1024, the display change normally works fine, but I
>get constant crashes until I switch back to 1024x768.
>Any clues?
>If I've failed to supply enough/the right information, do let me know!

The last version added auto patching for 8MB VRAM for RISC OS 3.7 if 2MB 
VRAM is sslected. There's a bug in it (now fixed in the development 
repository).

Basically to enable large screen modes in 3.7 select 0MB VRAM and find the
BandLimit line in the file !Boot.RO370Hook.Boot.PreDesk.Configure.!Run add 
a 0 to the end of each of those numbers, this should allow larger 
modes with 0MB VRAM (don't do this on a real machine, but it's fine on an 
emulator).

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] Large files in HostFS was Re. RPCEmu Mac OS X test build of 0.8.14

[Peter Howkins]

On Tue, Feb 16, 2016 at 05:52:36PM +, Sprow wrote:
> In article <20160216173419.ga20...@spod.org>,
> > For the long explanation of why this HostFS patch is not included in 
> > RPCEmu, please see this post from 2011.
> >
> > http://www.riscos.info/pipermail/rpcemu/2011-October/001383.html
> 
> I recall that discussion at the time, and the thread continued
>   http://www.riscos.info/pipermail/rpcemu/2011-October/001384.html
> then fell silent.
>  
> The tests performed in the post you've highlighted didn't really elicit any
> new information:
>   Old FileSwitch + 4GB files + vanilla HostFS => doesn't work
>   Old FileSwitch + 4GB files + 4GB HostFS => doesn't work
>   New FileSwitch + 4GB files + vanilla HostFS => doesn't work
>   New FileSwitch + 4GB files + 4GB HostFS => does work
> 
> the point being that having the underlying HostFS being 4GB capable is
> harmless for OS versions that it already doesn't work on, it's only when
> coupled with RISC OS 5.20 and (chronologically) later that you get benefit.

Unfortuanately it is not harmless on OSes < 5.20 nor harmless on >= 5.20.

At this time it seems to be important to state the requirements that 
HostFS should have. These may only have been implicit before.
 
1) HostFS needs to work on all versions of RISC OS that RPCEmu can run (at 
   least 3.5, possibly even 3.1 for arcem support).
2) RPCEmu users can place any size file in their HostFS directory on the 
   Host Side, and HostFS must handle this gracefully.
3) HostFS should protect RPCEmu user's data from loss or corruption.

One specific case discussed here of 3) is that allowing files to be opened 
that are larger than the maximum size that RO supports risks data loss, as 
a program can only work on only some of the data in a file, which can cause
corruption.

Here follows a table describing the current situation in RPCEmu.
I have used the phrase 'Data Safe' to represent that they don't allow 
files to be opened that are larger than OS supports.

  32bit builds 64bit builds

RO 3,4,6  Data Safe (2GB filesize limit)   Data Unsafe (no filesize limit)
RO 5  Data Safe (2GB filesize limit)   Data Unsafe (no filesize limit)

The problem of RPCEmu as it stands at the moment is that it does not meet 
our requirements of protecting users data on 64bit builds. Because HostFS 
allows the opening of files that are beyond what the OS can safely handle.
The 32bit builds (including windows binaries) are implicitly data safe, 
due to using the 2^31 file APIs.
The 64bit builds allow files from 2^31 (2^32 on RO5) to 2^63 to be opened 
when they shouldn't.

This is the effect your patch has:

  32bit builds 64bit builds

RO 3,4,6  Data Unsafe (no filesize limit)  Data Unsafe (no filesize limit)
RO 5  Data Unsafe (no filesize limit)  Data Unsafe (no filesize limit)

Your patch has the effect of increasing the cases in which user's data is 
not protected. As such, we can not commit it.

I propose that we do the following instead, add a check in HostFS's file 
open to prevent large files being opened (>2GB) and return a "file too 
large" error to RISC OS, this meets the requirements of protecting the 
users data in all scenarios.

The effects of this proposal are in this table:

  32bit builds   64bit builds

RO 3,4,6  Data Safe (2GB filesize limit) Data Safe (2GB filesize limit)
RO 5  Data Safe (2GB filesize limit) Data Safe (2GB filesize limit)

A limitation of 2GB files on a RISC OS that supports 4GB files is not 
ideal, but safe from data corruption. It is much safer than setting the 
limit at 4GB and allowing 2-4GB files to be opened on a RISC OS that only 
supports 2GB files.

If there is a backwards compatible way that a RISC OS file system module 
can determine that it is running on an OS that supports files up to 4GB 
in size, then this API could be used to modify HostFS to increase its 
filesize limit to 4GB on supported RISC OSes.
This would need to be something much more robust than an OS version check, 
and involve HostFS declaring it could use 4GB files as well as the OS 
declaring it wants to use 4GB files (a negotiation).

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu Mac OS X test build of 0.8.14

[Peter Howkins]

On Mon, Feb 15, 2016 at 11:55:44PM +, Theo Markettos wrote:
> 
> I've also applied a patch from Sprow to support 4GB files.
> 
> Please let me know if there are any new bugs this has introduced.

For the long explanation of why this HostFS patch is not included in 
RPCEmu, please see this post from 2011.

http://www.riscos.info/pipermail/rpcemu/2011-October/001383.html

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.8.14

[Peter Howkins]

A new version of RPCEmu is available, X.X.X

http://www.marutan.net/rpcemu/

* All Platforms

  - RISC OS Select 4i2 to 6i1 (6.06 to 6.20) now boot 'out of the box' due 
to clearing the *unplug bits in the distributed cmos.ram file.
If applying the upgrade to an existing install you must use the 
provided cmos.ram file and then apply your changes to cmos settings 
afterwards.

If you have used the 'installer' version on Windows Vista, 7, 8, 10 
then you will probably need to delete the copy of cmos.ram that is in 
this directory
C:\Users\\AppData\Local\VirtualStore\Program Files (x86)\RPCEmu


  - Add support for 8MB VRAM (via patching) on RISC OS 3.50/3.60/3.70/3.71/
4.04/4.29/4.33/4.37/4.39/6.02. This is in addition to the support for
RISC OS 4.02 (via patching) and RISC OS 5.2x and 6.10 to 6.20 via OS
autodetection.

  - RISC OS 5.2x now works with 0MB VRAM as we now allow video data to be
stored in any part of Simm 0 Bank 0 of RAM.

  - RISC OS Select 4i2 to 6i1 (6.06 to 6.20) now work with 0MB VRAM as we 
no longer create TLB entries for VRAM when none is configured.

  - Translate characters in HostFS paths that would be invalid on Windows,
using the same translations for ? < and > as used by LanMan. 
Contributed by Alan Buckley.

Note: Using the windows install to upgrade from
  previous versions may overwrite your cmos.ram
  and rpc.cfg files.

Matthew Howkins
Peter Howkins

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.14

[Peter Howkins]

On Mon, Feb 08, 2016 at 07:24:22PM +, Dave Symes wrote:
> In article <20160208145008.ga30...@spod.org>,
>Peter Howkins <rpcemu.howk...@marutan.net> wrote:
> 
> [Snippy]
> >   - RISC OS Select 4i2 to 6i1 (6.06 to 6.20) now boot 'out of the box'
> > due to clearing the *unplug bits in the distributed cmos.ram file.
> > If applying the upgrade to an existing install you must use the
> > provided cmos.ram file and then apply your changes to cmos settings
> > afterwards.
> 
> [Snippy]
> 
> I've tried upgrading an existing 6.20 install with everything from the new
> archive except (Obviously) HostFS and the 6.20 Rom.
> 
> With your cmos.ram file in place it gets a little way through the boot
> process then halts and fails with  "Boot failed"
> 
> Sorry, no furthur info possible as it can't get past that point.
> 
> If I replace your cmos.ram file with the (my) original from the 0.8.13
> install then 0.8.14 boots perfectly okay.

For all bug reports please attach the rpclog.txt file that's created.

Also, just to check the obvious, have you done the following

*configure filesystem hostfs

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Patch for HostFS file name translation on Windows

[Peter Howkins]

On Mon, Nov 02, 2015 at 01:43:58PM +, alan buckley wrote:
> I’ve attached a patch for hostfs.c (made using diff –u) to fix the
> problem with
> the “?”. “<” and “>” characters when they are used in HostFS on Windows.
> It translates them to “#”, "$" and "^" in Windows which matches some
> documentation I've seen on DOSFS.

Hiya, do you have a link to the docs anywhere? It'd be useful to check.

> k
> I have a Google test to test them if you require, but it's easy to do it
> by hand, at the CLI just try.
> 
> *create a?b
> *create a *create a>b
> 
> These will fail before the patch is applied.
> 
> Can some one apply this to the RPC Emu code please?

One other consideration is whether these should apply to linux as well, 
they are not required for operation, but are needed if you want to be able 
to take a hostfs image from linux to windows or vice versa.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Allegro not installed Ubuntu 14.04

[Peter Howkins]

On Thu, Oct 22, 2015 at 10:23:26PM +0100, Matthew Phillips wrote:
> This problem is awfully similar to that which people were getting a year ago
> (the subject line referenced Mint 17).
> 
> I have installed liballegro4-dev, liballegro4.4 and liballegro4.4-plugin-alsa
> 
> I have gcc and build-essential.
> 
> When I do
> 
> cd rpcemu/src
> aclocal

Why are you running aclocal?

http://www.marutan.net/rpcemu/linuxcompile.html

> ./configure

On a fresh copy, does ./configure on its own work?

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.8.13

[Peter Howkins]

A new version of RPCEmu is available, 0.8.13

http://www.marutan.net/rpcemu/

* All Platforms

  - Dynamic recompiler is no longer StrongARM specific. It supports a 
wider range of OSes with more processors. (RISC OS 3.50, 3.60, 3.70, 
3.71, 5.22).

  - Host pointer integration (follows host mouse) now works in rectangular
pixel modes (e.g. Mode 12).

  - The daylight saving time flag in CMOS should be automatically set on
startup based on the timezone information from the host machine.

  - ARM Core
   - Abort handling of LDM/STM now follows the varying Abort Model of the
 different ARM processors.
   - LDM/STM now check for abort on each data transfer, which gives 
 accurate abort detection.

* Linux

 - The display now supports pixel doubling of rectangular pixel modes 
   (e.g. Mode 12) in the same way as the Windows version.


Note: Using the windows install to upgrade from
  previous versions may overwrite your cmos.ram
  and rpc.cfg files.

Matthew Howkins
Peter Howkins

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Windows 8/10 Networking, working, updated manual

[Peter Howkins]

On Mon, Oct 05, 2015 at 03:33:40PM +, Tony Moore wrote:
> 
> Networking was fine, but I found it necessary to re-build the network
> bridge after every Win10 re-boot (as for WinXP). Do you find the same?

No, all the settings survive reboot here.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] Windows 8/10 Networking, working, updated manual

[Peter Howkins]

There's an updated version of the windows networking page.

There is a caveat, that if you update from windows 7/8 then you will 
probably need to uninstall and reinstall the openvpn TAP driver.

There is also an additional configuration you need to do, to prevent a mac 
address clash.

http://www.marutan.net/rpcemu/manual/network.html
http://www.marutan.net/rpcemu/manual/net-win.html

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Another connection problem

[Peter Howkins]

On Tue, May 12, 2015 at 07:47:39AM +0200, David Feugey wrote:
  Perhaps you should mention which version of TAP you're using.
 
Latest version 9.21.1
 
 
  Also attach the full log file to the thread.
 
It is basically done.
The rest (AKA ...) is loadconfig lines, and OS lines. With no error.

Yes, those are what I want to see. Those lines were added to aid in 
reproducing the setup that the user has, a reproducable bug is one that's 
likely to get fixed rather than ignored.

Please post the log on *all* issues reported.

  Also *disable* windows firewall (or any third party firewall) and test.
 
Already tested. No effect.
 
  2) The version I'm using is 'TAP-Windows Provider V9' (Open VNP 2.1.3)
 
Interesting. I read somewhere that with newer versions of OpenVPN, TAP
code was rewritten, and more strict on sync/async code (multiple commands
= async, even if you use sync functions... or something like this). Many
people seems to have problem to use it from their code.
 
I tried with OpenVPN 2.1.3, and the TAP driver now works! Thanks.
Should I suggest an update? I'm now stuck with an old version of OpenVPN
(that I use for other purposes), including many flaws... Not very optimal
(but it works).

Incidentally, now I know it causes an issue I'll see if I can add which 
version of the the TAP drier is in use to the log file 

I'll attempt to reproduce this with the new driver and see if there's a 
simple fix.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Another connection problem

[Peter Howkins]

On Mon, May 11, 2015 at 10:06:50PM +0200, David Feugey wrote:
Small but important correction.I made tests again. Interface is OK under
RISC OS with right MAC address.
When pinging something, packets are sent, answer is received by the bridge
but does not reach the TAP interface.
Nota: the same TAP module works with OpenVPN.
Perhaps I should try with an old version of TAP?

Perhaps you should mention which version of TAP you're using.
Also attach the full log file to the thread.
Also *disable* windows firewall (or any third party firewall) and test.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Way to turn off logging?

[Peter Howkins]

On Wed, Feb 18, 2015 at 08:12:17AM -, WPB wrote:
 
 I'm finding that RPCEmu periodically gobbles all the remaining space
 on my drive (around 10GB) with an enormous log file. Is it possible
 to stop RPCEmu logging, or limit the logfile size?

There isn't a way to turn off logging. However it shouldn't be generating
10GB files, that's a bug. What is in the log?

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu at the RISC OS London Show 25/10/2014

[Peter Howkins]

This year RPCEmu will be having a stand at the show in Feltham, London, 
this Saturday.

http://www.riscoslondonshow.co.uk/

Please come along and say 'hi', we'll be there all day doing practical 
demonstrations and answering any questions.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.8.12

[Peter Howkins]

A new version of RPCEmu is available, 0.8.12

http://www.marutan.net/rpcemu/

Changes in this version

* All Platforms

  - ARM Core
   - Fix 4 issues related to the SWP instruction
   - Fix for STRB where the PC should be offset
   - Fix implementation-specific behaviour for single data transfer

  - Floppy Drive
   - Support the FDC Format and Verify commands, this enables you to format
 an empty 800KB or 1600KB file as a disc image. Including code provided
 by Rob Sprowson.
   - Experimental fix for floppy-drive support in Recompiler. Please report
 any issues discovered with this.

  - Fix rendering of wimp modes 29 and 30 (800x600 in 1bpp and 2bpp)

  - HostFS
   - Add support for RISC OS ImageFS extensions and add a default disc name
 This enables several programs that previous failed to work to work,
 including Photodesk and the Acorn C/C++ installer.
   - Add support for querying HostFS free disc space.

  - Add a 'Help' menu to the UI with links to the website and manual


Note: Using the windows install to upgrade from
  previous versions may overwrite your cmos.ram
  and rpc.cfg files.

Matthew Howkins
Peter Howkins

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Rpcemu Digest, Vol 85, Issue 1

[Peter Howkins]

On Sat, Sep 06, 2014 at 02:07:43PM +0100, David Pitt wrote:
 
 (I still have not persuaded the mercurial latest to visibly start RISC OS
 yet.)

If that's RISC OS 5.2x that's because RO 5 uses IOMD version number to do
'special' things for rpcemu. We need to revert the IOMD version numbers to 
0 before the next release.

In the mean time edit, iomd.c, static const IOMDVariant iomds[], and 
change the 3 item in each row from 3, 3, 1, 1, to 0, 0, 0, 1

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Patch for floppy reading on ADFS 3.34 and later

[Peter Howkins]

On Mon, Jan 20, 2014 at 09:34:45PM +, Sprow wrote:
 The following patch implements that missing command. It's actually
 remarkably similar to the read sectors command, except there's no data
 transfer phase (in the real hardware the 37C665 swallows it all).
 
 I've tested this by grabbing the empty 800k floppy image from marutan.net
 (now it's back online) mounting it in RISC OS 5.21, and writing a 600k
 sprite image into it, rebooting, and reading it back.

Hi Sprow, thanks for this, I'll see about merging it in. I had another
patch in the same area for allowing floppy formatting, so I'll see about
getting them both in.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Can't run !Photodesk on RPCEmu0811/520

[Peter Howkins]

On Fri, Dec 13, 2013 at 06:58:07PM +, George wrote:
 I'm using RPCEmu0.8.11/5.20 (base system is a Win7-64 desktop) and  
 trying to run !Photodesk 310 from HostFS. It loads to the icon bar, 
 but an error message Filing system does not support this operation‘ 
 instantly appears. Checking in !Scrap.ScrapDirs.ScrapDir shows that 
 !Photodesk has created an empty clipboard directory on loading; 
 nevertheless it will not run.

 It works fine on 0.8.9/4.02, either from 
 HostFS or HardDisc4 locations.

This sounds like the blocking factor is RISC OS 5.20.

 I've tried v3.09 with exactly the same 
 result on the various RPCEmu setups listed, and I confess I‘m stumped.
 
 Has anyone managed to get !Photodesk to run on /520? Any advice would 
 be most gratefully received, as it's a great pity IMHO not to be able 
 to use this app in conjunction with RPCEmu on the fastest and most 
 efficient (fully 32-bit) OS version.

Do you know if Photodesk 3.10 works on RISC OS 5.20 on a real Risc PC?

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.11

[Peter Howkins]

On Thu, Oct 24, 2013 at 10:44:40AM +0100, george greenfield wrote:

 Indeed. What's it like compared to a standard StrongARM? Presumably 
 running under RPCEmu-Interpreter rather than -Recompiler more than 
 offsets any possible emulated architecture improvements. Have 
 you/could you run any benchmarks (e.g. ROmark)?

Real Phoebe performance with ROMark is compared on this page,

http://www.stardot.org.uk/forums/viewtopic.php?f=16t=6753

On the emulator however the speed will be pretty much the same as RPC1 
(SA, arm 610, arm 710) running in interpreter mode. The speed of the 
emulator isn't limited to the speed of the emulated hardware, it just goes
as fast as your computer will allow regardless of settings.

There are no significant changes to the architecture that have an impact
on emulated performance.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] 26/10/2013 RPCEmu and the real Phoebe at the RISC OS London Show

[Peter Howkins]

This coming Saturday, RPCEmu will be having a stand at RISC OS London Show

http://www.riscoslondonshow.co.uk/

Come along and see all the latest improvements, chat about new features 
and bother us with bug reports!

As a special treat, the Centre for Computing History have lent us the only
working Phoebe in the world, so you can compare the new RPCEmu with the 
real machine and check we are bug for bug compatable :)


Matthew Howkins
Peter Howkins

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] RPCEmu 0.8.11

[Peter Howkins]

A new version of RPCEmu is available, 0.8.11

http://www.marutan.net/rpcemu/

* All Platforms
  - Support for emulating Phoebe, the Risc PC 2. Produced with the 
assistance of The Centre for Computing History.

Instructions on how to setup Phoebe emulation and the required files
are on the 4corn website.

http://www.4corn.co.uk/articles/phoebe/

Note, this is a prototype machine, so is more for historical interest
than running production code.

  - Introduced the concept of configuring the Hardware Model rather than 
using CPU type to determine hardware. See the Settings-Settings 
window for details. You may need to reselect a model based on your 
previous CPU choice.

  - Fix very rare bug in which the MIPS count was sometimes wildly 
incorrect.

* Windows
  - Fix 'Follows Host Mouse' bug, where the host and emulated mouse
pointers were not lined up until the RPCEmu window had been moved.

  - Fix network GUI bug where the selected networking type was not 
correctly set.

Note: Using the windows install to upgrade from
  previous versions may overwrite your cmos.ram
  and rpc.cfg files.

Matthew Howkins
Peter Howkins

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Filetype translation

[Peter Howkins]

On Sat, Sep 14, 2013 at 09:36:53AM +0100, Gerald Holdsworth wrote:
Hi all,
Is there a way to specify the translation of Windows/Mac files to RISC OS
filetypes in RPCemu?

No, mainly as things end up as broken as the red squirrel tree you mention 
below.

I have a RISC OS 4.39 HostFS disc image from RedSquirrel, with tons of
applications in it, and want to open these in RPCemu...but one can't just
drag the entire disc image into an RPCemu HostFS directory, as both treat
filetypes differently. At the moment, my only solution would be to try and
fire up RedSquirrel and ZIP each and every application (or folders of
them), then bring these across to RPCemu. However, if there is someway of
telling RPCemu that an '.oby' file is a RISC OS Obey file, for example, it
would make life so much easier...IIRC, RS has all these definitions in a
text lookup file.

Restoring a red squirrel tree for use in rpcemu involves renaming the 
files, I have used cygwin (for a unix like bash shell under windows) and 
the following commands to change all the filenames within the hostfs 
tree. (note, don't run this on your whole harddisc, else a windows 
reinstall would probably be needed ...)

find . -depth -type f -name *.txt -exec sh -c 'mv $1 ${1%.txt},fff' _ {} 
\;
find . -depth -type f -name *.dat -exec sh -c 'mv $1 ${1%.dat},ffd' _ {} 
\;
find . -depth -type f -name *.htm -exec sh -c 'mv $1 ${1%.htm},faf' _ {} 
\;
find . -depth -type f -name *.arc -exec sh -c 'mv $1 ${1%.arc},ddc' _ {} 
\;
find . -depth -type f -name *.png -exec sh -c 'mv $1 ${1%.png},b60' _ {} 
\;

find . -depth -type f -name *.jpg -exec sh -c 'mv $1 ${1%.jpg},c85' _ {} 
\;  \
find . -depth -type f -name *.jpeg -exec sh -c 'mv $1 ${1%.jpeg},c85' _ 
{} \;  \
find . -depth -type f -name *.gif -exec sh -c 'mv $1 ${1%.gif},695' _ {} 
\;  \
find . -depth -type f -name *.html -exec sh -c 'mv $1 ${1%.html},faf' _ 
{} \;

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

[Peter Howkins]

On Thu, Aug 22, 2013 at 08:18:16AM +0100, george greenfield wrote:
 In message 7b84d77e53.old_coaster@old_coaster.yahoo.co.uk
   Tony Moore old_coas...@yahoo.co.uk wrote:
 
  On 21 Aug 2013, Peter Howkins rpcemu.howk...@marutan.net wrote:
  
  [snip]
  
  If you're running on Vista or 7 and you used the windows installer,
  don't check Program Files/RPCEmu/rpc.cfg but Users/your
  userame/AppData/Local/VirtualStore/Program Files/RPCEmu/rpc.cfg
  

George, can you confirm whether your config file issue was resolved by 
comparing this other file.

As to your new issue, try not using 256MB of RAM, but a lower value. 
There's some interesting issues with risc os and that much ram on real 
hardware, and I'm wondering if similar occurs when emulated.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

[Peter Howkins]

On Tue, Aug 20, 2013 at 05:09:40PM +0100, George wrote:
 I've been running 0.8.10/5.20 daily for about a week now, and have 
 noticed an oddity relating to the MIPS readout on the header bar, 
 which seems to display activity (sometimes /a lot/ of activity - up to 
 1400 on one occasion(!) and generally around 250-350 on my system*) 
 regardless of whether any application is active (i.e., when TaskUsage 
 will be displaying '0' or low single-figure activity levels).

RISC OS machine by default don't have any power-saving (with reduce 
cpu-usage off), they run flat out providing wimp null events even when 
there's no apps running anything. This busy-wait loop uses up CPU cycles, 
which are the MIPS you're seeing.

 I haven't noticed this with any previous 5.xx version or 4.02, where in 
 both cases the MIPS display conformed pretty closely to activity as 
 perceived on the desktop.

No, (assuming reduce-cpu-usage is off) all the versions of the OS will run 
flat out.

The mips count can also vary depending on the complexity or ease with which an
instruction can be emulated. A tight loops of instructions that are easy 
can temporarily skew the MIPS count higher.

 Selecting Settings-Reduce CPU Usage doesn't 
 seem to affect the behaviour.

However, this should have kicked in the power-saving stuff. *provided* 
that the OS starts seeing enough null events, e.g. if you're running a 
task that uses all spare cpu in risc os, this will have no effect.

After about 10 seconds you should see the mips count start to drop ... 
unless something has changed in RO 5.20 from earlier ...

 Windows Task Manager gives the same readout as MIPS.

I think windows task manager just takes a copy of the window title string. 

You can use task manager to see that until you engage 'reduce CPU usage' 
RPCEmu will use all available CPU power on one core, but with reduce CPU 
usage that should drop to a negligable level.

TBH, as with most benchmarks, interpretting the output of the MIPS count 
is complicated :(

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] 0.8.10/5.20: MIPS readout oddity

[Peter Howkins]

On Wed, Aug 21, 2013 at 05:38:55PM +0100, George wrote:
 It doesn't: cpu_idle = 0 in rpc.cfg, even though the CPU is, clearly, 
 idling correctly! But several items in rpc.cfg bear no relation to 
 reality:
 
 RPC.CFG  REALITY
 mouse_twobutton = 0  correct

snip

If you're running on Vista or 7 and you used the windows installer,
don't check 
Program Files/RPCEmu/rpc.cfg
but
Users/your userame/AppData/Local/VirtualStore/Program Files/RPCEmu/rpc.cfg

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] rpcemu on Mint15

[Peter Howkins]

On Mon, Aug 05, 2013 at 04:50:24PM +0200, Frank de Bruijn wrote:
 
 Alternatively, as liballegro4.2 itself doesn't seem to be present in the
 recent repositories either, switch to liballegro4.4 or 5.0 and see if
 you can get that to install with all its dependencies. No idea if
 compiling rpcemu with those versions would work, though.

4.4 is fine
5.x is not

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RO 5.20 RPCEmu networking problem

[Peter Howkins]

On Mon, Aug 05, 2013 at 06:47:02AM +0100, Dave Symes wrote:
 Unfortunately, that wouldn't help me as I can't get any of the RPCEmu 5.nn
 installs to network.

pebkac

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Upgrading from 0.8.9 to 0.8.10

[Peter Howkins]

On Thu, May 16, 2013 at 04:07:23PM +, Tony Moore wrote:
 On 16 May 2013, george greenfield george.greenfi...@tiscali.co.uk
 wrote:
  In message 20130516134814.ga2...@spod.org
Peter Howkins rpcemu.howk...@marutan.net wrote:
   On Wed, May 15, 2013 at 06:39:24PM +0100, george greenfield wrote:
 
I've downloaded the 0.8.10 zip file and was wondering, is it
feasible simply to copy across the new RPCEmu-Interpreter and
RPCEmu-Recompiler into my existing 0.8.9 RPCEmu folder (which
contains an 1GB HD4 drive as well as Hostfs, 4.02 Roms and all the
usual files), or is it necessary (or desirable) to create a
brand-new 0.8.10 folder?
  
   You should create a new folder, because it's not just the two
   executables that can change.
 
  As I've just discovered :-o
  Allegro-4.4.2.mt is implicated also.
 
 With due respect to Peter, as far as I can see, the 089 and 0810
 distributions are identical, apart from the .exe files. Allegro-4.4.2-mt
 (not Allegro-4.4.2.mt) is certainly the same.
 
 I've just switched from 0810 to 089, and back again, just by swapping
 the .exe files, as I suggested. No problem.

With no respect to Tony, if you try this it might work, but if you try
this it *will* bite you at some upgrade in the future.

Libraries, RISC OS support modules, support files and pretty much anything
can change between builds and I in no way want to have the support 
nightmare of people mixing and matching and rolling their own unknown 
versions of the program, and then complaining it doesn't work.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RPCEmu 0.8.10

[Peter Howkins]

On Tue, Apr 02, 2013 at 12:12:45PM +1100, Terry Duell wrote:
 * Linux
 
   - A program icon has been added to the main Window.
 
 A minor issue, but here (Fedora 18 x86_64, Cinnamon) there is no
 sign of an icon.

A bit of extra note about this, it's an icon that is attached to the 
*running window*, not browsing to the executable in a file manager.

Depending on where your window manager places it, it could be on the title 
bar, system menu bar, only visible when you minimise the window.

It was tested on gnome (2.x), cde, xfce, twm, fvwm, so I'm pretty sure 
it's using the standard method. (The only one that it appeared not to work 
in was jwm, for unknown reasons).

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] See a CD in RPCEmu

[Peter Howkins]

On Fri, Mar 08, 2013 at 07:45:29PM +, Dave Symes wrote:
 Thanks to the help from Tony, I'm almost done with my RPCEmu setting up.
 
 So, I have a CD with some RO software on it, how do I configure RPCEmu
 filer to display this CD.

I was about to say Just select the Host CD/DVD(drive letter) entry off 
the CDROM menu.

But then I discovered the bug in which that menu wasn't getting populated. 
It's broken in 0.8.9, we'll have to roll a new release out, then it's as 
simple as CD goes in the drive, and select which windows drive to map the 
cdrom too from the menu.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Network setup question

[Peter Howkins]

On Thu, Feb 28, 2013 at 06:20:28AM +, Dave Symes wrote:
 The question:
 It says in the Networking info (Windows side) that because XP doesn't have
 a native TAP driver, one needs to be installed, and that's what happened
 some while back when I did get RPCEmu networking on an XP install.
 
 Does Win-7 Pro have its own TAP driver, if so, does it obviate installing
 an additional TAP driver?

All versions of windows need the tap driver installed, I'll tweak the 
docs.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Linux difficulties with rpcemu

[Peter Howkins]

On Thu, Feb 14, 2013 at 02:36:05PM +, Philip Glover wrote:
 Have tried again, but the second instruction on the guide throws up
 the error,

Can you post a link to which guide you are using?

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Linux difficulties with rpcemu

[Peter Howkins]

On Wed, Feb 13, 2013 at 03:31:13PM +, Philip Glover wrote:
 I wonder if anyone can help with problem outlined in attachment?

You don't have the allegro graphics library installed on your new system.

*and* when moving between distributions, recompile the rpcemu source code
on your new system. This will require you to install the the build 
requirements again. This is because Linux distributions are not 
necessarily compatible between each version or different vendors, a binary
made on one has no gaurentee of running on another.

*and* please try to avoid putting questions in attachments ...

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Linux difficulties with rpcemu

[Peter Howkins]

On Wed, Feb 13, 2013 at 07:25:53PM +, Philip Glover wrote:
 Thank you Peter for the reply, and apologies for using an attachment
 instead of retyping my originally rejected mailing.
 I have checked my package manager, and allegro4.4, which says it is
 a portable Library, is installed.

Do you also have the allegro development files installed? It is often a 
seperate package and is needed. (liballeg-dev)

 It was while trying to recompile a
 new build, as you suggest, (using the instructions from the
 website), that I got the messages about AM_PATH_ALLEGRO not found,
 and the error message about lib-plugin-jack, so the build was
 unsuccessful.

It sounds like you're running autoconf or automake here, you don't 
need/want to do that. Run ./configure to create the makefiles.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Rpcemu: mounting CDs

[Peter Howkins]

On Sat, Feb 02, 2013 at 04:45:38PM +, Dave Symes wrote:
  The PC utility I use to rip to ISO is this:
 
  http://www.imgburn.com/
 
 Sorry Mike, I have no idea what the above means.
 You can enlighten me if you like.

http://www.google.com/search?q=what+is+an+iso

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] RISC OS 6 install instructions - revised

[Peter Howkins]

On Fri, Jan 25, 2013 at 06:24:17AM +, Gerald Holdsworth wrote:
New revised instructions for installing RISC OS 6 on RPCemu, to take into
account the recent testing by Tony Moore confirming compatibility with
other RISC OS 6 versions (essentially, just changed RISC OS 6.20 to RISC
OS 6, and added Tony's email).
 
New version at:
[1]http://www.geraldholdsworth.co.uk/Installing%20RISC%20OS%206.pdf

Just for info, if you're wondering why we haven't altered the 
compatability page on the website. It's because we still need to fix the 
bug related to booting 6.x when a !Boot isn't present (fix that and 6 
becomes as easy to install as all the other versions).

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Risc OS 6.20

[Peter Howkins]

On Fri, Jan 04, 2013 at 08:56:15PM +, Gerald Holdsworth wrote:
 Has anyone managed to get Risc OS 6.20 running on RPCemu 0.8.9?

No, no one has yet.

http://www.marutan.net/rpcemu/manual/romimage.html

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Firefox on RPCEmu

[Peter Howkins]

On Thu, Oct 11, 2012 at 01:51:50PM +0100, george greenfield wrote:
 Has anyone managed to get Firefox (any version of the RO port) running 
 under RPCEmu/4.X or /5.X?  I tried with r2.0.0.20 on RO 4.02 and it 
 wouldn't run. The !Help file includes VirtualRPC (StrongARM edition), 
 but excludes RiscPCs, amongst the suitable hardware list: quite where 
 that leaves RPCEmu 0.8.9/RO 4.02 is unclear, hence this plea.

I have to admit to not having tried. This is mainly because a version of 
firefox that isn't 6 years old, runs considerably faster and  isn't full 
of known security issues is available on every one of RPCEmu's host 
platforms.

As for why it doesn't work, possible bugs in SA emulation might be a 
cause.

Peter.

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] How to recover from bad monitor mode?

[Peter Howkins]

On Sun, Jul 01, 2012 at 02:51:29PM +1000, Terry Duell wrote:
 Is there a way of booting RPCEmu into a safe screen mode, to allow
 these sort of errors to be corrected, without having to resort to
 replacing the hard disc image?

There's a few methods (that apply to real hardware too).

1) Hold down 'shift' on startup to prevent !Boot from running (which loads 
the dodgy mode), and then poke around in !Boot to change which mode is 
used.

*or*

2) Wait till you're in the 'desktop' (or best guess when that it). hit F12 
and blindtype 'wimpmode 28' (without quotes) and hit enter. This should 
put you back into 640x480, and then poke around in !Boot to change which 
mode is used.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Some ques re RPCemu-0.8.9 on Linux

[Peter Howkins]

On Tue, Jan 17, 2012 at 04:37:01PM +1100, Terry Duell wrote:
 I haven't had any success with getting RPCemu to crash whilst
 running under gdb.

 All that has been happening is that RPCemu appears to freeze when I
 attempt to open my root dir on the host linux system.

I haven't forgotten about this, I've been trying to come up with an
alternate method of debugging.

As you mention above, you're having issues accessing the / of the host,
can you run the following command in a terminal and send me the results.

ls -l /

Do you also have issues accessing your home dir, or is it always only /?

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] CD problems with RPCEmeu 0.8.9 on Winows XP

[Peter Howkins]

On Tue, Jan 17, 2012 at 07:27:01AM +, Timmermans, Andre wrote:
 The drive E has number 5.

Are you absolutely sure you don't have the entry Host CD/DVD Drive (E:) 
on the cdrom sub-menu? As that's exactly the right number a CD drive is 
meant to return.

Peter

-- 
Peter Howkins
peter.howk...@marutan.net

___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu