RPCemu at London user group, Mon 18th June 2018
Bryan Hogan (339) 589 posts |
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) 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: ROUGOL meetings take over the pub’s upstairs restaurant for the evening. Entry is free, food & drink plentiful (but not free!). |
Steve Pampling (1551) 8155 posts |
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 |
Chris Mahoney (1684) 2165 posts |
That’s interesting, because I get the error every time! |
Steve Pampling (1551) 8155 posts |
Hmm, what would you normally have sitting on the iconbar when you shut down? 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. |
Colin Ferris (399) 1809 posts |
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. |
Chris Mahoney (1684) 2165 posts |
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. |
Steve Pampling (1551) 8155 posts |
ref. Work done:
If they are reading (I believe Peter looks in at times) then I’m sure they appreciate the thanks.
Just flipped into Fullscreen in recompiler and it carried on working… My normal setup is:
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. |
Steve Pampling (1551) 8155 posts |
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. |
Steffen Huber (91) 1949 posts |
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. |
Peter Howkins (211) 236 posts |
yes
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.
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.
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.
It is something I’ve put quite a lot of thought into recently :) |
Colin Ferris (399) 1809 posts |
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] |
Peter Howkins (211) 236 posts |
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)
As I mentioned above, the max for a risc pc is 256.
I guess you mean CPU reduction code when idling? If so, yes, for the last 6 years, just pick it off the Settings menu.
Possibly not, it’s probably easier to crack the copy protection off. |
Peter Howkins (211) 236 posts |
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)
As I mentioned above, the max for a risc pc is 256.
I guess you mean CPU reduction code when idling? If so, yes, for the last 6 years, just pick it off the Settings menu.
Possibly not, it’s probably easier to crack the copy protection off. |
Steve Pampling (1551) 8155 posts |
I’d not looked at that option previously. |
Colin Ferris (399) 1809 posts |
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 :-) |
nemo (145) 2529 posts |
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. |
Steve Pampling (1551) 8155 posts |
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. |
Andrew Conroy (370) 725 posts |
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. |
Colin Ferris (399) 1809 posts |
So where was the memory mapped? |
Wouter Rademaker (458) 197 posts |
|
Bryan Hogan (339) 589 posts |
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 :-( ) |
Colin Ferris (399) 1809 posts |
As a matter of interest – with using various DVD’s with Linux onboard – is the best option to use the Windows version under Wine? |
Frank de Bruijn (160) 228 posts |
Not in my opinion. Why would you want to do that? |