Not so long ago, a new version of RPCEmu (0.9.0) was released, featuring a new (and much improved) QT front end. As with most RPCEmu releases, I eagerly compiled it on my Mac, only to find that the keyboard doesn't work! It seems that when you get keyboard events from QT on the Mac, you don't get a scan code, which is what RPCEmu uses to map keypresses to PS/2 codes for RISC OS to process.

For the last couple of weeks, I've been playing around trying to get the keyboard working. It's been a process involving a large amount of guesswork, but I think I finally have it working. Fortunately there are no changes required to QT, just to RPCEmu. You can get most of the information you need from other fields of the key event from QT and from another event that RPCEmu ignores on Macs, and the only key I've found that needs special treatment is Caps Lock (mainly because you don't get a "key up" event for some reason).

Before I submit a patch to RPCEmu's mailing list, would anyone be interested in doing some beta testing? It works fine on my 2017 iMac with a normal Apple keyboard and I'll probably give it a whirl on my MacBook too, but I don't have any other hardware available to use.

The patch adds a couple of new files and modifies a few others. I've currently got it working so the keys are in the same layout as a normal RISC PC/Acorn keyboard, so the backslash key is to the left of "Z", not to the left of "ENTER". I'm weird like that: I use a normal "PC" keyboard layout when I'm in Windows, even if it's in a virtual machine running in OS X.

The patch won't be ready for couple of weeks as I'm off on holiday next week, but hopefully it will be ready shortly after I return. Unfortunately I never remember to make a copy of files before I change them so I have the originals to use to compare using "diff" so I'll have to faff about with that for a bit.

Last edited by VincentVega on Wed Jul 11, 2018 8:40 pm, edited 2 times in total.

I'm still on holiday (it's so nice not to think about work!), but I managed to find some time yesterday and today to start working on putting together a proper patch. It's going pretty well (C/C++/Objective C are very different to .NET, and making them work together is something I've not done before) and I just need to do a bit of tidying up before I pull everything together and upload something so you can all have a play. It will be a single unified diff, which you will need to apply to a fresh "rpcemu-0.9.0" folder via the "patch" command in Terminal. I'll endeavour to get something finished during the weekend, all being well.

I've had a quick play on my 12" Macbook, and the patch works fine there too, so it's looking fairly promising.

As promised, I have a patch ready for testing. You can download it here: here. The download is around 84K in length and contains the following:

* "rpcemu-0.9.0-mac.patch" - a patch file in unified diff format.
* "macosx" - a folder that contains icons in various sizes for the Dock icon.

To apply the patch, you will need to have installed the Mac developer tools at minimum, and probably Xcode as well. The easiest way to do this is to start the Terminal application (in /Applications/Utilities) and to type the following:

This will prompt you to choose which you want to install - just the command-line tools or the full Xcode experience.

Once you've done that, you'll need to install QT. This can be downloaded from the QT web site here. Most people will want the Open Source version. This will download a small installer that connects online and downloads what it needs. Alternatively, you can obtain an off=line version or the source code from one of the links here.

The final thing you need is the source for RPCEmu. At the moment, the patch is for the current release version, 0.9.0. You can obtain the source from here.

After all the downloads are ready and everything is installed, create a new folder in Finder and copy the "rpcemu-0.9.0.tar.gz" file and the "rpcemu-mac-patch-0.9.0-1.tar.gz" into it. Next, start a Terminal session.

You will need to create the make files for the project, using the QT "qmake" command. The exact line you type in depends on where you installed QT and whether the path for the QT stuff is in the $PATH environment variable. My QT installation is in "/usr/local/qt", so I type:

You can get to this via the Finder from your home directory. If "Library" doesn't show up, you can remedy this by clicking on "View > Show View Options" and turning on "Show Library Folder". Double click on "Library", then "Application Support".

Create a folder named "RPCEmu".

Open another Finder window and browse to wherever your "rpcemu-0.9.0" folder is. From this folder, copy the following to the "RPCEmu" folder you just created:

You will also need to copy a RISC OS image into the "roms" folder. I've found that 5.24 doesn't work (it errors on boot), but 3.71 works fine.

All being well, if you then double-click on "rpcemu-interpreter-debug", it should launch the emulator, complete with working keyboard.

Things to note

1. The keyboard layout mimics that of a UK RISC PC keyboard, not a Mac one, so the key to the left of "Z" is the backslash/pipe and that to the left of RETURN is hash/tilde.
2. There is some slightly odd behaviour keyboard-wise:

* SHIFT-3 produces an angled bar.
* The pilcrow key to the left of "1" on a standard Apple aluminium keyboard produces the pound sign.

I am not sure whether this is an issue with the patch or with RPCEmu. I haven't had the time to compile on Windows/Linux to check.

3. F13, F14 and F15 are mapped to "Print Screen/SysRq", "Scroll Lock" and "BREAK" respectively. In theory, the "Fn" key (on my keyboard, between F13 and DELETE should function as "INSERT".

4. The patch uses virtual key codes, not scan codes, as these are apparently not accessible. This means that if you have a non-UK keyboard layout where keys are in different positions, the wrong key will be sent to the emulator. For example, if you have a French layout and you press "Z", the emulator will think you actually pressed "Y". It is possible to work out what keyboard layout is currently active (there is some unused code in the patch for this), so it would be possible to have the emulator work out what keyboard layout is active and switch the key mappings accordingly. I haven't put much thought into this, let alone done any development.

5. If you compile a debug build (which is the default) the application icon doesn't show up in the Finder. However, it does with release builds. If you want this, type "make -f Makefile.Release" instead of "make".

I think that's enough to be getting on with. Any feedback and bug reports would be appreciated.

Last edited by VincentVega on Tue Jul 24, 2018 5:53 pm, edited 3 times in total.

the build then proceeded without error, but the resulting app was called rpcemu-interpreter.app, and was placed in the same directory as the rpcemu-0.9.0 source directory (one level higher than I had expected).

The rpcemu-interpreter.app app is running nicely, so far. One difference from RPCEmu 0.8.14 that I've noted is that I have to select "Two-button mouse mode" to get the middle mouse button menu behaviour working, with the menu button then being assigned to ctrl-trackpad-click.

Anyhow, so far, so good!
Thanks again for your work on getting the latest RPCEmu onto Mac OS X!

The folder thing is because I missed out a step from the compile stage. Before you type the 'qmake' command, you need to change directory into the 'qt5' folder within 'src'. I'll tweak the instructions accordingly.

From a quick review of the mercurial changelog I couldn't see this committed, is this change stable enough to be submitted or is further testing required (in which case I might help out if time allows)?

I haven't had time to submit the patch yet due to other (both computing and non-computing) projects and certain events affecting family members, but I'm hoping to get it sent over next week sometime when I'm off work. I haven't had any feedback other than that from lcww1, so I'm assuming that all is well with the patch.

Update: the patch was submitted last week, but hasn't shown up on the mailing list yet. I had an email come through from the list saying that my message was held for approval because it was bigger than a specific size, but since then nothing. The list archives don't show any postings since June, so I have no idea what's happening.

I've just built version 0.9.0 on my Retina iMac — THANKS for the instructions and patch, which are MUCH appreciated.

I've been very much looking forward to seeing 0.9.0 on the Mac, because having continued use of RPCEmu is important to me, so I was concerned about upgrading beyond Sierra. Now that this is working, I'll probably hop over High Sierra and go straight to Mojave. Anyway, that's for another day. I have a little feedback that I'd like to share – both good news and bad.

GOOD NEWS:

1. It works!
2. The mouse buttons work again! They used to work OK for me in a previous OSX version (Yosemite? El Capitan?), but in recent times, with 0.8.14, I had only Select working, and Menu and Adjust both had to operate with keyboard modifiers, which was both a pain and made certain software functions impossible to use. Now, all three buttons work just as I'd expect, and without the need to use the two-button mouse option (though I do have a third party Mac mouse driver installed).
3. Contrary to the report about RISC OS 5.24 not working, I can confirm that it works perfectly for me! Moreover, I've patched my copy to work with Aemulor, and I've got that running too. The setup I'm using is exactly the one that I was running under 0.8.14, so there's no reconfiguring to do.
4. The Mac and RISC OS pointers no longer lose track of each other when entering/exiting the window.
5. It's no longer necessary to enable RPCEmu as a 'low-res' app to make it fill its window (trivial point, but even so…).

BAD NEWS:

1. It's APPALLINGLY slow! I don't just been slightly slower; I mean painfully slower!
2. Screen updates are very choppy, with visible rectangle redraws and tearing
3. Using the mouse is like dragging it through treacle.
4. 256MB of RAM still doesn't work (it didn't work on 0.8.14 either); I'm limited to 128MB.

For what it's worth, I'm emulating a 128MB StrongARM machine, with Aemulor installed.

I'll be able to live with the new version for light use, but its performance is REALLY disappointing, especially considering how fast the previous non-Qt versions were. In fact, quite honestly, I'd be better off running it under WINE. I also have a version of 0.8.14 that I built under WINE when I was having problems with the native Mac port, and it's a bit clunky by comparison in terms of its interface, but it does at least work. And its performance is slower than native as you'd expect… but it's a LOT faster than this new Qt build.

Just to give an idea, I have a fairly complex ArtWorks file that I used to test the overall speed.

These timings are very approximate, but I think they illustrate the problem quite well. If feels like going from a StrongARM back to an ARM 6.

Overall I'm happy in that I have a native build that works, and in terms of interface, it's clearly better than both the previous version and the clunky WINE-based one. And it's perfectly usable… but it's really disappointingly slow. I wonder why there should be such a huge difference, and whether anything might be done about it.

It'd be nice if networking worked too, now, but I haven't had time to test it and I haven't read anything about it, so I'll assume for the time being that the situation on the Mac (i.e. networking either extremely difficult or impossible to get working) is unchanged.

Richard Hallas

Former editor of RISC User and Foundation RISC User magazines
Designer of the RISC OS cogwheel logo • Designer of the RISC OS 5 icon set

I have never used Xcode or Qt before but the build was easy, thanks to the very clear instructions, on this late 2013 non-retina iMac running Mojave. Both interpreter and recompiler versions were built.

RPCEmu is working very well, running the latest OS5.25. Very briefly measured, speedwise the recompiler looks to be about equivalent to a Raspberry Pi 2.

That it is a 64bit application is excellent, RISC OS can have a life on the Mac after Mojave.

I just love the acorn nut on the Mac's Dock.

Noting the "BAD NEWS" in the post above I am emulating a 128MB StrongArm, with "Reduce CPU usage" enabled. The interpreter build is slower but shows no signs of treacle here. Just in case it is relevant the qt is qt-opensource-mac-x64-5.11.2.

One little thing, the "Reduce CPU usage" setting is not preserved.

Last edited by pittdj on Sun Oct 07, 2018 4:35 pm, edited 1 time in total.

Just as a quick follow-up to my previous message… I gave timings for a real-world task (redraw of an ArtWorks file), but I forgot to quote the relative timings from the software itself.

So, just to give an idea of the relative difference, when I've got RPCEmu just sitting with its window open and the RISC OS desktop more or less idling, the figures I see in the title bar are:

Old Mac-native version 0.8.14: MIPS AVG: 473 (approx.)

New Mac-native version 0.9.0: MIPS AVG: 91 (approx.)

Certainly, dragging windows around etc., the old version is instantly responsive and slick, with no obvious graphical artefacts to worry about, whereas the new version feels jerkier in overall mouse movements, there are obvious redraws going on, and the windows tear a lot when being whipped around the screen. Moreover, I can trace a path with my mouse movements and watch the pointer follow it after a delay (easy to see when dragging a window). It feels very sluggish compared with the previous version.

As I say, I can live with it because it's usable, and overall the new version certainly works better than the old, with the mouse buttons being fully supported again. That's great. But I do wish it hadn't suffered about an 80% speed loss…!

Richard Hallas

Former editor of RISC User and Foundation RISC User magazines
Designer of the RISC OS cogwheel logo • Designer of the RISC OS 5 icon set

I've fixed the issue found by pittdj - it was attempting to read the configuration from the current working directory (usually "rpcemu-interpreter-debug.app/Contents/MacOS") instead of "~/Library/Application Support/RPCEmu".

There is a new release of the patch, which you can download here. I've bumped the version number (from 0.9.0-1 to 0.9.0-2). You will need to trash your existing build directory and restart from "Part 1 - unpack the archives".

Richard - by default, it compiles the interpreter version ("rpcemu-interpreter"/"rpcemu-interpreter-debug"), so it will be quite slow unless you've told it to compile the speedy ("rpcemu-recompile") variant. It will also default to an ARM710 with 24MB of RAM if it can't find the configuration file due to the bug mentioned above. You will need to edit the "rpcemu.pro" file in "src/qt5" to get it to do this if you haven't already - see step 3 here: http://www.marutan.net/rpcemu/linuxcompile.html. My 2017 iMac 27" has an average MIPS of around 60 on the interpreter version, but it's currently around 420 on the dynarec one.

Thanks for the updated patch. The 'here' link is however pointing to the first version. Once the later patch was downloaded a rebuilt RPCEmu does read the rpc.cfg file. The downside is that attemtping to save changed preferences crashes RPCEmu in much the same way as happens on a Linux build, so this is not a Mac specific.

When exactly does it crash when saving the preferences? I haven't experienced that (administrative user, OS X 10.12.6) - if I go into the "Settings" menu and change something, or modify something in the preferences dialogue, it works fine (and the settings are saved if I quit the emulator and restart). I get prompted whether I want to reboot and the emulated machine is restarted.

If it crashes on OS X, you should (in theory) get Apple's standard "quit unexpectedly" dialogue, where you ought to be able to see technical information about the error (you may have to click on the "Send Report" button) - feel free to post here and I'll see if I can work out what's happening. It would be best with a debug build, as the diagnostics should be more detailed.

It goes wrong on clicking OK to restart, the RISC OS window shows vertical smearing of the backdrop and a force quit is required. I believe, or hope, it will be fixed in the next release which may be soon. It is RISC OS version dependent, OS 4.02 seems OK on the Mac build but OS 5.25 is not.

Ah, that'll be why - I'm using 3.71. I tried 5.24, and it happens with that as well, but not always. I attached lldb (the Mac debugger) to it and it looks like it's getting stuck with QT waiting for something. There are lots of threads and calls into the bowels of Apple's libraries, none of which I am familiar with. Possibly it's a threading issue.

Thanks so much for the update and extra info. Mac users haven't been troubled with the difference between Recompiler and Interpreter versions of RPCEmu in the past, so quite honestly I'd forgotten that there was the choice. (I wonder why the much slower one is the default, given that I've never experienced any problems that are unique to the faster one…)

Anyway, that's great! Having rebuilt it with the new patch, not only is the config bug fixed (I'd wondered why ARM7 was suddenly in use…) but the speed is now back to roughly where it should be. This latest version doesn't seem quite as fast as the old one, but it's close enough not to matter. In fact, with the same ArtWorks test file (which rendered in 12 seconds in my old version), the rendering time is now about 19 seconds. I.e. it's the same speed as the old version running under WINE – though, thankfully, without the interface clunkiness. I can live with a minor speed drop given the other positive benefits.

One oddity is that if I attempt to restart RISC OS (i.e. Shutdown followed by Restart button in the power-off dialogue), I now get an error appearing in a Mac error box, saying "Bad PC fc001000 fc001000" – and then it quits rather than restarting. No big deal, though.

The worst remaining issue, unfortunately, is that the mouse pointer behaviour is STILL like treacle, and the screen updates are still quite jerky. The slight loss of immediacy in the screen updating isn't a big problem, but the pointer behaviour is. E.g. If I drag a window in a circle or an S-shape or whatever in the emulator, I can make the motion and then wait and watch it happen a second or so after I did it. The emulator is now running at a good speed, but there's this huge lag between moving the pointer and the reaction. Sometimes clicks get, stuck too: e.g. I can click down on a title bar of a window, and it remains depressed in the emulator – as though I were holding down the mouse button – even after I've released the click. Another click is necessary to clear it.

Does no-one else see this mouse lag? I wondered if it was because I'm running a third-party mouse driver (I use SteerMouse), but I tried turning that off and it made no difference.

The frustrating thing is now that the old version of the emulator simply doesn't have these problems. The screen updating is smoother generally (immediate response and no stuttering or obvious redrawing going on), and in particular the mouse movement is instant and lag-free; it feels just like moving a mouse on a real machine. As soon as I use the new version of RPCEmu, though, the pointer lag is both instantly obvious and a significant problem. Clearly the emulator is usable, but the pointer has to be moved slowly and with care in order not to lose control and to be able to simply click in the right place.

Richard Hallas

Former editor of RISC User and Foundation RISC User magazines
Designer of the RISC OS cogwheel logo • Designer of the RISC OS 5 icon set

One oddity is that if I attempt to restart RISC OS (i.e. Shutdown followed by Restart button in the power-off dialogue), I now get an error appearing in a Mac error box, saying "Bad PC fc001000 fc001000" – and then it quits rather than restarting. No big deal, though.

Richard - I haven't experienced any mouse lag issues, and I use SteerMouse as well (version 5.3.1). Do you have any other processes running that might be causing an issue? Try running Activity Monitor and see if it reports anything chewing up processor cycles.

pittdj - I can reproduce an issue with the keyboard on changing spaces. I have CTRL+1 to CTRL+5 set up to change to a difference space and if I have !Edit running in a window and click and then type after switching away and then back, the emulator thinks that the CTRL key is held down (so for "a", you get "[01]', "b" is "[02]" and so on), even though it isn't. Presumably the key release event is being claimed by OS X, so the emulator doesn't receive it. You can get around the problem by pressing and releasing CTRL a few times. Is this the same as what you're seeing?

Last edited by VincentVega on Wed Oct 10, 2018 5:43 pm, edited 3 times in total.

CTRL characters is one of the effects and a press of the CTRL key restores normality.

There is a second condition, multiple characters and an erratic clock. What seem to happen is that on sleep or a spaces change the clock stops. When RPCEmu becomes active again the clock seems to run fast to catch up. Bizarrely if a key is held down the clock runs even faster!! With once the clock has caught up to the host's time it runs at the right rate and keypresses return to one character at a time. On the other hand if a key is held down for too long and the RPCEmu clock gets in front of the host then the fault never clears.

Which of the two faults one gets may depend on how long the RPCEmu was hidden.