I haven't seen it reported anywhere, so I thought I'd relate that I've got Virtual RiscPC Adjust working on WINE in Linux (Ubuntu Gutsy).
It was fairly straightforward to do, though helped by the fact that I already had it installed in a Windows XP Tablet partition on the same machine. I just symlinked the start of that partition to ~/.wine/drive_c and then did: $ wine c:/RISCOS/VirtualRiscPC-Adjust/VirtualRPC-Adjust.exe which is the path on the Windows partition with \ replaced by /
and it ran. Seemed to be a bit slow at starting up (spends ages at the RISC OS splashscreen), but once it's running I get between 20-70 MIPS (Centrino 1.6GHz, NVidia GEForce 5200 with closed-source drivers). Generally the scheduling is much better than Windows (sometimes when VRPC is running Windows slows to a crawl, which doesn't happen on Linux+WINE). VRPC still crashes on exit, just as it does in Windows (WINE tells me there's a page fault, if anyone from VA is interested in the log)
There are a few bits of display corruption where WINE doesn't draw the top and bottom of the window correctly but they don't affect RISC OS usage too much. Audio kind-of works, but is a bit distorted.
On boot I get some errors about Shared C Library out of date (don't know what's causing that, the same VRPC install works on Windows) and the battery being low (I suspect WINE doesn't emulate the battery monitoring calls) but otherwise it's fine. It manages to run Firefox (1.5) successfully so that's a fairly good workout.
I did try to run it without the Windows partition - WINE started claiming it wanted things like MFC42.DLL. These things are usually fixable by fiddling around with WINE and downloading various DLLs from Microsoft, but I just took the easy option and used my existing Windows install. Interestingly the copy protection didn't kick in, so evidently WINE's emulating the network MAC address correctly.
On Tue, 18 Mar 2008 11:49:28 +0000, Paul Vigay wrote: > In a dim and distant universe <jsv*uK...@news.chiark.greenend.org.uk>, > Theo Markettos <theom+n...@chiark.greenend.org.uk> enlightened us > thusly: > [Snippety snip]
>> around with WINE and downloading various DLLs from Microsoft, but I >> just took the easy option and used my existing Windows install. >> Interestingly the copy protection didn't kick in, so evidently WINE's >> emulating the network MAC address correctly.
> It's easy enough to customise the MAC address anyway under Linux.
It's easy enough to change the MAC address under Windows, too. Using the MAC as the "hardware key" is a completely ineffective way of doing copy prevention - it doesn't stop the people who actually want to rip you off, it just annoys the legitimate users. Much like most DRM.
I don't have a full RISC OS disc image to test with RPCemu, but a very quick test running TwinWorld at the opening screen (ie playing the game but not moving the player around, just watching things animate) gave:
RPCemu (SVN 124) with no sound: 13.5 MIPS (I don't know if sound works or it's turned off)
VRPC 1.3 with sound: 44 MIPS
Both are with RISC OS Adjust, and counts taken from each app's cycle count. Note that VRPC under WINE obscures its count most of the time in the mode TwinWorld uses and it only flickers up occasionally, so I could be sampling it at a time that isn't representative.
RPCemu is slicker - the mouse pointer works seamlessly from Linux to RISC OS, while under VRPC there's the same split-pointers as under Windows (you either have a RISC OS pointer which doesn't follow the Windows pointer well, and have some points on the RO screen you can't reach because the RO pointer stops moving once the Windows pointer has left the VRPC window. Or there's a capture-pointer mode where the Windows pointer disappears and you need to press a key to get it back). RPCemu supports left+right button=Menu click, which doesn't work for me under either Windows or WINE (I have it set up as the third button press on both Windows and X, but VRPC uses DirectInput and so gets in below this configuration on Windows).
VRPC is better at ceding the processor when RISC OS isn't busy - RPCemu makes my laptop hotter. RPCemu just about has networking, but I haven't played with it. VRPC's networking is fine under WINE as far as I can see.
Something I should have mentioned in the original article is that you need to be in the VRPC directory before running it, otherwise it can't find the config file: $ cd /windows/RISCOS/VirtualRiscPC-Adjust/ $ wine c:/RISCOS/VirtualRiscPC-Adjust/VirtualRPC-Adjust.exe
Paul Vigay <invalid-email-addr...@invalid-domain.co.uk> wrote: > It's easy enough to customise the MAC address anyway under Linux.
That's not the point, though. The point is the WINE supports reading the MAC address and does indeed serve up the MAC address of the first network card (eth0, which happens to be my fixed ethernet port - the same one as VRPC is bound to in Windows). It could easily not support reading the MAC address (it doesn't read the battery state, for example), or return some dummy value like 01:23:45:67:89:AB instead. Such support means it's possible to run a previously-registered VRPC under WINE.
In message <lsv*yu...@news.chiark.greenend.org.uk>, Theo Markettos
<theom+n...@chiark.greenend.org.uk> wrote: > cfer...@freeremoveuk.com.invalid wrote: >> How does this compare in speed etc with 'RPCemu' v0.7 run on Linux? >> http://b-em.bbcmicro.com/arculator/
> I don't have a full RISC OS disc image to test with RPCemu, but a very > quick test running TwinWorld at the opening screen (ie playing the game > but not moving the player around, just watching things animate) gave:
> RPCemu (SVN 124) with no sound: 13.5 MIPS > (I don't know if sound works or it's turned off)
> VRPC 1.3 with sound: 44 MIPS
That isn't a useful benchmark as is not necessarily running flat out. for a measure of CPU emulation speed, "REPEAT UNTIL FALSE" at the BASIC prompt would be more useful.
Timothy Baldwin <T.E.Baldwi...@members.leeds.ac.uk> wrote: > That isn't a useful benchmark as is not necessarily running flat out. for a > measure of CPU emulation speed, "REPEAT UNTIL FALSE" at the BASIC prompt > would be more useful.
Fair point, it was more an attempt to test video etc speed. Doing REPEAT UNTIL FALSE:
RPCemu out of the box: 15 MIPS VRPC: 10 MIPS but it could be 100MIPS and the last digit is getting truncated by the icon being too small RPCemu compiled with --enable-dynarec: 55MIPS
I also tried this: a%=TIME:b%=0:REPEAT:b%+=1:UNTIL TIME>a%+3000:PRINT b%
Which returned: VRPC: 5099959 and took about 32s (based on my watch) RPCemu out of the box: 1213293 and took 30s RPCemu with --enable-dynarec: 4630151 and took 30s
I'm lazy so I couldn't be bothered to average the results over many runs, but empirically I'd suggest there's at most two significant figures in those numbers.
The reason for testing by my watch is that these tests depend on the emulated timers, which aren't always synced properly with the host machine - that's why there are sometimes double-click or auto-repeat problems on emulators.
>Timothy Baldwin <T.E.Baldwi...@members.leeds.ac.uk> wrote: >> That isn't a useful benchmark as is not necessarily running flat out. for a >> measure of CPU emulation speed, "REPEAT UNTIL FALSE" at the BASIC prompt >> would be more useful.
>Fair point, it was more an attempt to test video etc speed. Doing REPEAT >UNTIL FALSE:
>RPCemu out of the box: 15 MIPS >VRPC: 10 MIPS but it could be 100MIPS and the last digit is >getting truncated by the icon being too small >RPCemu compiled with --enable-dynarec: 55MIPS
>I also tried this: >a%=TIME:b%=0:REPEAT:b%+=1:UNTIL TIME>a%+3000:PRINT b%
>Which returned: >VRPC: 5099959 and took about 32s (based on my watch) >RPCemu out of the box: 1213293 and took 30s >RPCemu with --enable-dynarec: 4630151 and took 30s
I have tried the same test here.
VRPC on XP OS6.06 4516921 RPCemu 0.7 OS4.04 4940326
Theo Markettos <theom+n...@chiark.greenend.org.uk> wrote: > I haven't seen it reported anywhere, so I thought I'd relate that I've got > Virtual RiscPC Adjust working on WINE in Linux (Ubuntu Gutsy).
