Discussion:
[Rpcemu] Patch for 0.9.1 - Mac keyboard support
Timothy Coltman
2018-11-19 19:43:18 UTC
Permalink
Hello all

Please find attached a ZIP archive (169K) containing a patch for RPCEmu 0.9.1 that implements keyboard support for OS X/macOS. The file contains a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder ("macosx") containing the icons for the Mac's dock. This should be unpacked in the "src" folder and the patch applied from there.

This is a development of the same patch that I had previously posted on the Stardot forums (where I used to post as "VincentVega"), and incorporates some of the suggestions made there.

Once compiled, a Mac RPCEmu application will appear in the top-level "rpcemu-0.9.x" folder. Double-click in the normal way to run. You can compile the interpreter or dynamic recompilation versions - both work on a Mac. The patch has been developed on "Sierra" 10.12.6 - it should hopefully work on all later versions.

When you run the application for the first time, it will prompt you to configure a directory where the emulator can expect to find the various files it needs to run, such as the RISC OS ROMs, hard drive images and so on. This allows you to copy the RPCEmu application into the "/Applications" folder if you want, but keep the other files in a separate location in your home folder. Once you've selected a folder with the "Select" button and pressed "OK" the emulated machine will start as normal. If you want to change the folder at a later date, hold down the "Cmd" key as the application starts. You can also delete the "~/Library/Preferences/org.marutan.rpcemu.plist" file.

There are a few things to note:

1. The keyboard mimics that of a RISC PC, so the key to the left of "Z" is blackslash/pipe and the one to the left of RETURN is hash/tilde.
2. There are a few quirks with the keyboard: SHIFT-3 produces an anged bar; pilcrow (to left of "1") produces a pound sign.
3. F13/F14/F15 on a standard Apple aluminium keyboard are mapped to "Print Screen/SysRq", "Scroll Lock" and "BREAK". "Fn" should be mapped to "INSERT".
4. The patch uses virtual key codes and assumes a UK keyboard layout. There is support for other keyboard layouts, but needs these to be defined in the "keyboard_macosx.c" file (there is a very basic French layout defined that swaps "Y" and "Z").

Please note that there is no networking support. I did try and get it up and running, using some of the code from the "Caliston" builds of Francis Devereux and whilst it did look promising at one point (I could ping from one end), I wasn't able to get it to work fully.

Any comments and suggestions would be appreciated. If anyone wants binaries (so they don't have to compile), please let me know and I'll make some available in due course.

Many thanks.
Tim
Theo Markettos
2018-11-19 21:49:16 UTC
Permalink
Post by Timothy Coltman
Hello all
Please find attached a ZIP archive (169K) containing a patch for RPCEmu
0.9.1 that implements keyboard support for OS X/macOS. The file contains
a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder
("macosx") containing the icons for the Mac's dock. This should be
unpacked in the "src" folder and the patch applied from there.
That's great. It looked so good until I came across the Qt keyboard
problem, so fixing that should improve the RPCEmu Mac experience a lot.
Post by Timothy Coltman
4. The patch uses virtual key codes and assumes a UK keyboard layout.
There is support for other keyboard layouts, but needs these to be defined
in the "keyboard_macosx.c" file (there is a very basic French layout
defined that swaps "Y" and "Z").
I've had no end of problems with things getting keyboard layouts wrong on
MacOS (usually with remote connections to other machines where the other end
is set differently) so it wouldn't be the first time.

Does your layout handle US keyboards (it's usually \|~`#@" that get
into trouble)?

I usually use the 'British PC' layout on a Macbook Pro which is additional
fun because the keys are now moved around compared to the Apple layout.
Post by Timothy Coltman
Please note that there is no networking support. I did try and get it up
and running, using some of the code from the "Caliston" builds of Francis
Devereux and whilst it did look promising at one point (I could ping from
one end), I wasn't able to get it to work fully.
Those are my builds, and I never got networking to play nicely.
I wonder whether, instead of using TUN/TAP, on MacOS it might be worth
investigating NETunnelProvider as a native API for networking?
https://developer.apple.com/documentation/networkextension
That would make a much nicer user experience.
Post by Timothy Coltman
Any comments and suggestions would be appreciated. If anyone wants
binaries (so they don't have to compile), please let me know and I'll make
some available in due course.
Peter may have other opinions, but AIUI he doesn't have any means of
producing Mac builds. It sounds like you're set up to do that, so you could
take over producing them from me - I didn't have any special infrastructure
for that beyond a very hacked up Xcode with Snow Leopard libraries - I was
just making random builds on my laptop from time to time. (and running any
kind of CI with MacOS is a pain, so they're not straightforward to automate)

Theo
l***@maemagel.com
2018-11-20 21:38:56 UTC
Permalink
Post by Theo Markettos
Post by Timothy Coltman
Hello all
Please find attached a ZIP archive (169K) containing a patch for RPCEmu
0.9.1 that implements keyboard support for OS X/macOS. The file contains
a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder
("macosx") containing the icons for the Mac's dock. This should be
unpacked in the "src" folder and the patch applied from there.
That's great. It looked so good until I came across the Qt keyboard
problem, so fixing that should improve the RPCEmu Mac experience a lot.
Post by Timothy Coltman
4. The patch uses virtual key codes and assumes a UK keyboard layout.
There is support for other keyboard layouts, but needs these to be defined
in the "keyboard_macosx.c" file (there is a very basic French layout
defined that swaps "Y" and "Z").
I've had no end of problems with things getting keyboard layouts wrong on
MacOS (usually with remote connections to other machines where the other end
is set differently) so it wouldn't be the first time.
into trouble)?
I'd imagine that most of the US keyboard layout will work, though I've
not tried it myself. The code works by defining a base keyboard layout
(UK) and you can add additional layouts to the code by telling it which
keys are handled differently - so for French, for example, I've told it
that "Y" and "Z" are different. It reads the current keyboard layout in
when the application starts and goes from there (all in the
"src/qt5/keyboard_macosx.c" file). It's probably not the best solution,
but it does work. If there are keys on a US layout that are different,
it would be trivial to add in the relevant mappings, whilst allowing
other layouts to work unaffected. None of this would be needed if you
could obtain scan codes from OS X, but you have do make do with virtual
keys, handle modifiers separately and handle CAPS LOCK even more
separately.
Post by Theo Markettos
I usually use the 'British PC' layout on a Macbook Pro which is additional
fun because the keys are now moved around compared to the Apple layout.
Post by Timothy Coltman
Please note that there is no networking support. I did try and get it up
and running, using some of the code from the "Caliston" builds of Francis
Devereux and whilst it did look promising at one point (I could ping from
one end), I wasn't able to get it to work fully.
Those are my builds, and I never got networking to play nicely.
I wonder whether, instead of using TUN/TAP, on MacOS it might be worth
investigating NETunnelProvider as a native API for networking?
https://developer.apple.com/documentation/networkextension
That would make a much nicer user experience.
My hacked version would have been pretty awful, even if it had worked.
Kernel extensions need to be signed in newer versions of OS X and I'm
not a registered developer, so I ended up downloading an application
called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which
were signed. The emulator would randomly stall during !Boot when
setting up networking, so I decided to cut my losses and gave it up as a
bad job. I'll have a look at "networkextension", just to see, though
I'm not too experienced when it comes to OS X development.
Post by Theo Markettos
Post by Timothy Coltman
Any comments and suggestions would be appreciated. If anyone wants
binaries (so they don't have to compile), please let me know and I'll make
some available in due course.
Peter may have other opinions, but AIUI he doesn't have any means of
producing Mac builds. It sounds like you're set up to do that, so you could
take over producing them from me - I didn't have any special infrastructure
for that beyond a very hacked up Xcode with Snow Leopard libraries - I was
just making random builds on my laptop from time to time. (and running any
kind of CI with MacOS is a pain, so they're not straightforward to automate)
Peter did ask me whether I'd be prepared to create Mac binaries when I
emailed him previously off-list, and I "umm"ed and "ah"ed about it. It
really depends on how much work there is, and whether there are any
other oddities thrown up by OS X that need to be worked around (such as
the keyboard and networking). It would be nice to have a proper
installer as well (there is an installer builder in QT apparently,
though I've not investigated in any detail).
Post by Theo Markettos
Theo
Cheers
Tim
Theo Markettos
2018-11-20 22:08:40 UTC
Permalink
Post by l***@maemagel.com
My hacked version would have been pretty awful, even if it had worked.
Kernel extensions need to be signed in newer versions of OS X and I'm
not a registered developer, so I ended up downloading an application
called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which
were signed. The emulator would randomly stall during !Boot when
setting up networking, so I decided to cut my losses and gave it up as a
bad job. I'll have a look at "networkextension", just to see, though
I'm not too experienced when it comes to OS X development.
Using Tunnelblick's TUN/TAP was what I did - it worked, but it wasn't exactly
user friendly. I don't think I've tried it on anything post Mavericks,
though.

Apple does say:
The com.apple.developer.networking.networkextension entitlement is required
in order to use the NETunnelProvider class. Enable this entitlement when
creating an App ID in your developer account.

but according to StackOverflow (which must be true) that's no longer the
case. (It may still apply to iOS). There are also things like:
https://github.com/zhuhaow/NEKit
that build on top of NETunnelProvider and handle the entitlement, like you
do with Tunnelblick.
Post by l***@maemagel.com
Peter did ask me whether I'd be prepared to create Mac binaries when I
emailed him previously off-list, and I "umm"ed and "ah"ed about it. It
really depends on how much work there is, and whether there are any
other oddities thrown up by OS X that need to be worked around (such as
the keyboard and networking). It would be nice to have a proper
installer as well (there is an installer builder in QT apparently,
though I've not investigated in any detail).
I don't think there's much to do beyond putting the files in a .app bundle
inside a .dmg archive? I don't think there's any need for an installer,
users open the .dmg and just drag RPCEmu.app to /Applications. You'd
probably put the Qt libraries inside the .app so there's no system
dependencies, or even statically link.

Looks like this is the tool to make a bundle including Qt libraries:
http://doc.qt.io/qt-5/osx-deployment.html

A wizard that's roughly 'what ROM image do you want', 'where do you want
your hostfs to go' etc would be nice, but not critical.

My Allegro binaries were pretty much fire-and-forget - I got a few people
asking about stuff, but not a lot.

Theo
Theo Markettos
2018-11-21 12:45:22 UTC
Permalink
There are also things like: https://github.com/zhuhaow/NEKit that build on
top of NETunnelProvider and handle the entitlement, like you do with
Tunnelblick.
Shortly after writing that post, I had a better idea.

QEMU uses a library called SLIRP, which contains its own ethernet stack,
including servers to do DHCP, DNS, etc. When a QEMU VM wants to use the network,
the default mode is to push packets into SLIRP which will NAT them and emit
them from the QEMU app as if they were native connections. This enables
no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
In principle, doing the same for RPCEmu would allow no-setup networking
across all the platforms it supports.

QEMU's source code is not pleasant to work with (I have the scars), but
somebody has done libslirp, which is the SLIRP code ripped out into a
separate library with an easy-to-use interface:
https://github.com/rd235/libslirp
(it's mostly GPL as RPCEmu is)

Since I had a spare couple of hours, I plugged libslirp into RPCEmu as a new
'NAT' networking type, just in the Linux code for now as a proof of concept.
Currently it doesn't work - transmitted packets go into libslirp but none
are received from it as network_plt_rx() is never called to fetch them,
probably because I need to understand how the RPCEmu network card does
interrupts. libslirp can either do a synchronous receive call, or a file
descriptor via poll() or select().

As I don't know when I'll next get time to work on this, I've put the
code up here:
https://bitbucket.org/caliston/rpcemu-libslirp/
in case anyone gets around to taking a look before me.

Theo
Theo Markettos
2018-11-21 14:38:44 UTC
Permalink
The Mac emulator BasiliskII uses slirp for networking. It doesn't require
setting up. It's open source so it may be easier than QEMU (or it may
just use the same code).
Thanks. It appears to use an earlier fork of the same code, without the
library-ification.

Theo

Loading...