RPCemu at London user group, Mon 18th June 2018

The next meeting of the RISC OS User Group Of London will be:

RPCemu, presented by Matthew and Peter Howkins

Monday 18th June 2018, 7.45pm

The Blue-Eyed Maid (upstairs in the restaurant)
173 Borough High Street
London, SE1 1HR

http://www.rougol.jellybaby.net/meetings/

RPCemu is the free, open source, RiscPC emulator available for use on Windows and Linux systems. Originally developed by Sarah Walker, it has been maintained by brothers Matthew and Peter Howkins for almost 10 years and is now to able to support all versions of RISC OS from 3.50 to 6.20, and even the unreleased Phoebe version 3.80!

This year saw the release of version 0.9.0. Despite the small change in version number, this is a very significant release that has seen some major under the hood changes. Chief among those is the move away from using the old unsupported Allegro4 graphics/sound library to using Qt5. This enables the Windows and Linux versions to share a common and much improved user interface, reducing the support overhead.

Matthew and Peter will be talking about those changes, other recent improvements to the ARM and hardware emulation, and what their plans are for future versions on the road to the mythical version 1.00…

More info here – http://rougol.jellybaby.net/meetings/index.html

ROUGOL’s venue is easy to reach by public transport from in and around London and the south east:
- 2 minutes walk from Borough tube station
- 5 minutes walk from London Bridge station
- 10 minutes from Waterloo (two stops eastbound on the Jubilee line to London Bridge)
- 20 minutes from Euston and Kings Cross/St Pancras (southbound on the Bank branch of the Northern Line to Borough)

ROUGOL meetings take over the pub’s upstairs restaurant for the evening. Entry is free, food & drink plentiful (but not free!).

This year saw the release of version 0.9.0.

RPCEmu and RISC OS 5 on Windows updated to match. Tardy, I know.

Note 1: Users are now specifically advised NOT to install where the old installer based version would have placed things (Program Files) and to use something like D:\RPCEmu instead.

Note 2: The error listed on the RPCEmu site under “Limitations” for RO5 on RPCEmu (Windows) regarding the Shutdown and then Restart is not something I have managed to trigger with 5.23, 5.24, or 5.25

That’s interesting, because I get the error every time!

Hmm, what would you normally have sitting on the iconbar when you shut down?
A common one for many people is Alarm but I never run that in RPCEmu and run !Timeless for a small digital clock. StrongED for the text editing etc, Verma, and ARMalyser complete the routine right side.
Transient (with TrapDelete) and SparkFS(full) are the left.

I might load other stuff but that’s the always there list. Running interpreter or recompiler version? The fan works a bit but I run the recompiler.

Thanks for all the work on RPCemu.

Has the bug gone that caused the program to quit when run in Full screen Win7 recompiler.

Max screen memory 8Mb or more?

Max memory up to 500Mb – is that possible?

A way of using VRPC HostFS with RPCemu ie having one RO Harddrive?

Perhaps a simple program run first – that gives a choice of RO Version to load – like RedSq.
[ref startup prog – perhaps Brandy BASIC running a menu – does it do graphics]

Hmm, what would you normally have sitting on the iconbar when you shut down?

Anything or nothing. It happens with a completely fresh ROM/HD4, without running any apps. I’m not sure whether it happens if I boot the ROM “standalone” with no HD4, and I’m not at my Windows machine right now so can’t test it.

I wonder why it doesn’t happen for you! I typically run the interpreter version as it seems to be more stable but I think the issue occurs with both.

ref. Work done:

Originally developed by Sarah Walker, it has been maintained by brothers Matthew and Peter Howkins for almost 10 years

If they are reading (I believe Peter looks in at times) then I’m sure they appreciate the thanks.
I created a documentation page in the wiki and update sometimes…

Has the bug gone that caused the program to quit when run in Full screen Win7 recompiler.

Just flipped into Fullscreen in recompiler and it carried on working…

My normal setup is:

1. AnyMode loaded and screen resolution set to make the screen occupy the whole screen above the windows taskbar so flipping to a specific item on the dark side is a click away. Run the recompiler maximised
2. RPCEmu memory set to the maximum (256MB I’m afraid)
3. Video set to max – click on Switcher shows system total as 270336K (264MB) so that seems to be 8MB video memory.

NB. Using a laptop and recompiler make sure you either use a lap tray or a table for the laptop or risk severe temperature related injuries on your lap. I think that may be a wish list item to allow the emulator to idle when RO is doing nothing much.

I wonder why it doesn’t happen for you! I typically run the interpreter version as it seems to be more stable but I think the issue occurs with both.

Do you have networking setup? That’s one thing I’ve not got:

The laptop has an install of AnyConnect and that borrowed from OpenSSL so I think it argues with other items about use of the TAP and I can count the instances of anything working on my thumbs.

Has the bug gone that caused the program to quit when run in Full screen Win7 recompiler.

I don’t think this was a reproducible general bug, more one of the “it happens on specific machines with specific graphic drivers/GPUs” bugs. I never had it, and I often used fullscreen mode on Win7 with the recompiler.

The Qt5 version is in my experience a lot better when handling fullscreen and scaling issues. The 0.9.0 release version has no problems switching modes and going fullscreen/windowed both on my Win10 machines and on the only Win7 machine left. So just try it and see, it is surely worth it.

Has the bug gone that caused the program to quit when run in Full screen Win7 recompiler.

yes

Max screen memory 8Mb or more?

Currently if you select 2MB on the configuration window, you’ll get 8MB (on pretty much every RO version). There is a 16MB gap in the Risc PC physical memory map for VRAM and we have tested it on a couple of versions and it works, but it’s not tested enough yet.

Max memory up to 500Mb – is that possible?

There is only a 256MB space in the Risc PC memory map for RAM, so that’s the maximum. Incidentally if you have any Risc PC programs that use more than 128MB, please let me know, more than 128MB of RAM is allegedly buggy on earlier versions of RISC OS (due to not actually having the memory modules to test with).

The Risc PC 2 (Phoebe) has a theoretical 512MB maximum RAM size, but I wouldn’t recommend that as it was a buggy unfinished OS on an unfinished machine. It is also currently hard-coded to 128MB RAM in RPCEmu.

A way of using VRPC HostFS with RPCemu ie having one RO Harddrive?

No, unfortunately with VRPC it’s entirely possible to create HostFS drives that are incompatible with other versions (or other configurations) of VRPC, let alone RPCEmu.

Perhaps a simple program run first – that gives a choice of RO Version to load – like RedSq.

It is something I’ve put quite a lot of thought into recently :)

Thankyou for your development work.

Does the podule system work the same as VRPC?

(a standard HostFS for both progs)

As to programs that use memory – !NetSurf – uses memory – as fast as my cat drinks milk – and doesn’t give it up :-)

Here running VRPC-DL (non SA) – with 256Mb of memory – and that can run out!

Tried it with 512MB 2×256 – DL didn’t like it!

The 32bit version of !DAPicture – has a wimpslot set at -min 100M.

VRPC-DL seems to run fairly cool with a Win Laptop – is there a way around the Chestnut problem with RPCEmu? :-)

[edit1]
Can HostFS be made to Timestamp an ‘Dir’ like you can a ‘!Dir’ – Sib copy protection needs it.

Does the podule system work the same as VRPC?

No, VARPC podules as .dlls are not cross platorm (win + linux + others), so rpcemu podules are compiled into the source of the main binary.

(a standard HostFS for both progs)

(Snip progs that use lots of mem, thanks)

Tried it with 512MB 2×256 – DL didn’t like

As I mentioned above, the max for a risc pc is 256.

VRPC-DL seems to run fairly cool with a Win Laptop – is there a way around the Chestnut problem with RPCEmu? :-)

I guess you mean CPU reduction code when idling? If so, yes, for the last 6 years, just pick it off the Settings menu.

Can HostFS be made to Timestamp an ‘Dir’ like you can a ‘!Dir’ – Sib copy protection needs it.

Possibly not, it’s probably easier to crack the copy protection off.

Does the podule system work the same as VRPC?

No, VARPC podules as .dlls are not cross platorm (win + linux + others), so rpcemu podules are compiled into the source of the main binary.

(Snip progs that use lots of mem, thanks)

Tried it with 512MB 2×256 – DL didn’t like

As I mentioned above, the max for a risc pc is 256.

VRPC-DL seems to run fairly cool with a Win Laptop – is there a way around the Chestnut problem with RPCEmu? :-)

I guess you mean CPU reduction code when idling? If so, yes, for the last 6 years, just pick it off the Settings menu.

Can HostFS be made to Timestamp an ‘Dir’ like you can a ‘!Dir’ – Sib copy protection needs it.

Possibly not, it’s probably easier to crack the copy protection off.

I guess you mean CPU reduction code when idling? If so, yes, for the last 6 years, just pick it off the Settings menu.

I’d not looked at that option previously.
On a few quick tests it does remove the chestnut toasting effect but I get some fairly extreme lag on mouse click events such that a double click on a file or directory is treated as a single click or click-hold turning things into a drag if any small mouse movement occurs.
Flip back to no CPU reduction and the problem disappears.
Testing done on 64bit Win7 2.67 GHz 2Gb RAM laptop with RPCEmu alongside a running copy of Firefox 60.0.2 with 21 tabs open.

With ref to 512Mb memory – didn’t the RPC have that option with the fast ARM processor option – with extra fast ram fitted.

Must have been mapped somewhere :-)

Can HostFS be made to Timestamp an ‘Dir’ like you can a ‘!Dir’ – Sib copy protection needs it.

This is a natural consequence of the behaviour of the underlying filing system on the host – if it’s FAT it supports directory timestamps, if it’s NTFS then the timestamps of directories (usually) reflect the most recent change to any object within that directory. This is nothing to do with RPCEmu or any other program, it’s a Windows filing system behaviour.

As I’ve said only recently, it would be possible for a RISC OS module to implement timestamped directories via the use of a hidden file, in much the same way as LongFiles worked.

RPC have that option with the fast ARM processor option – with extra fast ram fitted.

Sounds like you’re thinking of the Kinetic upgrade board, but that had 256MB on the processor board. I’m not sure how much, in any, of the standard RAM on the main board was accessible.

Sounds like you’re thinking of the Kinetic upgrade board, but that had 256MB on the processor board. I’m not sure how much, in any, of the standard RAM on the main board was accessible.

If my memory is correct, the Kinetic processor could have 64, 128 or 256MB onboard. It also used all the motherboard RAM, but in order to use more than 256MB in total you needed RISC OS 4.39 or later. 4MB of Kinetic memory was used to softload the OS into from either the motherboard ROMs or the flash chips on the Kinetic, making it unavailable as RAM.

So where was the memory mapped?

So where was the memory mapped?

https://www.riscosopen.org/forum/forums/5/topics/1694

Reminder that the meeting is this coming Monday!

(Aside: I’ve just noticed riscos.info is down, which explains why my message about this sent to the RPCemu mailing list last week has not appeared :-( )

As a matter of interest – with using various DVD’s with Linux onboard – is the best option to use the Windows version under Wine?

Not in my opinion.

Why would you want to do that?