GeminX was something I needed. Still need. It allows me to run Windows in a window in RISC OS. I dabbled with the idea of releasing it as a product, but along the way, it’s hit a few brick walls.
The first is the software. It’s basically a “rebadged” version of Andrew Sellors’ RDPClient attached to some hardware. RDPClient is a few years old now, and was last updated to ARMv7 in 2010, so in technology standards, it’s quite long in the tooth (obviously not in RISC OS terms, but generally it is!). And it’s a sod to configure for end users. Numerous attempts to contact Andrew Sellors to see if he’s willing to update it and/or provide a configuration front end yielded no response – it may be like many other RISC OS aficionados of the past, he’s moved to pastures new and all the old email addresses are no longer checked.
The second is sourcing decent Windows-capable hardware for a price that made sense to both the prospective buyer, and the supplier too. After many attempts to source something useful and functional, and available at the right price, RISCOSbits HQ (the shed at the bottom of the garden) has a room full of Windows 10 Mini PCs that didn’t quite meet the mark, and a few that do but are too expensive, too big, or too rare.
The third is enforcing the internal design specification – that it should fit inside any old or new RISC OS desktop computer, needing to fit in the space available for either a couple of PCI cards or a podule slot. It also needs the capability to turn on when power is applied, so a separate button isn’t required. The original PC Card didn’t need a separate on/off button, so why should a new version?
It’s proved difficult to meet all the demands so it makes more sense to release the “concept” for other RISC OS users to play with, rather than let it wither on the vine. People can then build their own, to their own spec, to meet their own needs. After all, that was the original plan.
So, here it is… a guide to creating your own Windows (or Linux) PC Card.
You’ll obviously need some Windows capable hardware. So far, items that have been tested that “work” are as follows:
- LattePanda 4GB/64GB
- LattePanda 2GB/32GB
- Intel Compute Stick Z8300
- Lenovo IdeaCentre Stick 300
- Generic Windows 10 K6A TV Box
These all switch themselves on when power is first applied, but the LattePanda and the K6A required a specific BIOS update to enable the feature. For the LattePanda, this is relatively straightforward. The K6A is a bit of a minefield, being a generic Chinese Mini PC.
Other devices to consider are a stripped down and de-cased Voyo V1 Mini PC for expansion capabilities, the Up Squared boards for greater peformance, the Up Core boards for lower pricetags, and other 2nd Generation Intel Compute Stick models (can be expensive!), but these have not been tested and results/capabilities may vary. Wildly.
The concept really does benefit from use of an ethernet port for most effective connection, but WIFI will also allow reasonable functionality. Indeed, the original model shown at the London Show in October 2016 was running over wireless to a network connected RiscPC, albeit not the one it was installed inside! It just needs to be connected to the same network as the RISC OS machine, or be linked directly in some way. The LattePanda devices have the option to attach your own high-gain wireless antenna to boost signal reception, and they also have ethernet ports.
Given that the PC hardware is the basis of the GeminX device, the better the specification of the device used, the better the usability. Key considerations are obviously the processor, memory and storage, but also factor in expandability via USB 2.0 or 3.0.
As RDP runs over a network, the main hardware requirement is the capability to connect both the RISC OS machine and the GeminX device to the same network.
The core applications required are as follows:
- RDPClient (for RISC OS) and its dependencies
- RDPWrapper (for Windows)*
- WispyConf (optional and needs adjustment – get in touch for the source code if you want to develop it further – it made a great start for both Wispy and GeminX, but needs further work that the original developer can no longer offer. Contact for a copy/details)
- RISCOSbits RDPClient enhancements and prettifications (optional and slightly pointless).
*RDPWrapper allows a level of RDP connection on Windows 8/10 that RDPClient can manage. It also enables RDP on Home versions of Windows, where it is otherwise disabled. See below about issues with the Creator’s update though.
Installing the software is relatively straightforward.
On RISC OS, it is simply a matter of downloading RDPClient to an appropriate folder on you hard drive, adding the “dependencies” (DeepKeys and the sound modules) to the !Boot sequence as required.
RDPWrapper is similarly easy. Download it, run it, and it patches Windows appropriately. Sometimes, it takes a couple of goes to get it to work properly, and a restart helps, but it’s not tricky.
Configuring the software is more complicated, especially on RISC OS, but first, the Windows side needs to be sorted.
RDPWrapper requires some minor configuration to work with RISC OS, mainly to avoid authentication issues. The best way is to set the RDPConf program as shown:
It’s worth noting that the latest Creator’s Build of Windows 10 Home completely breaks RDP, and RDPWrapper can’t overcome this, at time of writing. An upgrade to Windows 10 Pro or greater resolves this issue.
Now to setting up RISC OS to access the RDP connection on Windows. This is a much trickier prosposition. A sample, working !Run file, contained inside the RISC OS connection app will look something like this:
It’s worth dissecting the “switches” to try to make it easier to understand.
- -u geminx is the user name of the PC being connected to, in this case username geminx
- -p xxxxxxxx is the password for the user (obviously this is not the real password, but it could be as it’s not obfuscated in any way).
- -g 1360×768 is the resolution to be connected to. This will either run in a window or change the screen resolution to match if you choose to run fullscreen
- -a 15 is the screen colours. Options here are 8 for 256 colours, 15 for 32k colours, 16 for 64k colours and, perhaps not surprisingly at this point, 32 for 16m colours.
- -D w is the display mode, in this case it will open in a window of 1360×768 pixels (as set by the -g switch previously). Other options here are f for full windows (that is, a window taking up the whole screen) and s for a single tasking application that takes over the display entirely.
- -z enables compression of the RDP connection data. This tends to make everything a bit quicker, but if you want to disable it, simply miss out the -z switch.
- -x b sets the “experience” or, in lay terms, how much of the Windows fancy stuff is seen on RISC OS! In rough terms, b (for broadband) means the theme is shown, but the backdrop is supressed, l (for LAN) means you get the full windows experience, animations and everything, whereas m (for modem), gives you a very cut down Windows experience
- -r tells RDP what to do with a set device. In the case above, sound:local tries to pull the sound through to RISC OS, and clipboard:active enables anything on the clipboard to be pulled through to RISC OS.
- geminx at the very end of the line is the server that the connection attempt is being made to. It can either be the Host Name or the IP address, and whatever it is will appear under the App icon on the icon bar.
There are a huge amount of other switches, but many of these either don’t work correctly, or create such a long, complicated line that it becomes quite confusing when things go wrong, and it has to be unpicked. The shown line, above, is the basis of a very simple connection that, assuming RDP is set up correctly on the GeminX device, “just works” with modifications to the -u, -p, and server name switches to suit the settings on the GeminX device.
The full list of switches is available by shift double-clicking the RDPClient application and double-clicking the RDPClient appfile within.
The one found to cause most difficulty is the -P switch to enable persistent bitmap cacheing. It seems to break the display. Some others seem to be non-functional, or superfluous.
A couple of issues with the -r switches listed above are worth noting. The sound redirection doesn’t seem to work with RISC OS 5 and is flaky with RISC OS 4, but this may be down to the 2002-ish vintage Sound modules and SharedSound 1.07 that are required. Additionally, the clipboard:active switch clashes with RComp’s UniClip and can stiff the RISC OS machine, requiring an Alt-Break.
If you haven’t lost the will to live by this stage, it should connect nicely to your GeminX device!
Internal Mounting Options
For mounting inside a Podule Slot on a RiscPC, the Up Board is possibly easiest, as it fits very nicely into a PiPOD Adapt mounting plate! When prototyping the initial devices, it was necessary to develop some simple Podule covers which allowed for the mounting of a single HDMI adaptor and an RJ45 adaptor. With the “stick” PC options, this made mounting them as simple as plugging the HDMI connector directly into the HDMI socket adaptor and it worked. However, there was no ethernet connector on the sticks, so the RJ45 hole was used for a badly fitting USB extension cable.
Original GeminX prototype in a RiscPC slice. Note the molex to microUSB splitter cable for power
For the most part the easiest way to mount any of the other devices is to secure them elsewhere in the case. Drive bays are handy, and most boards will fit in a 5.25in bay, if not a 3.5in bay. Again, in prototyping, a 5.25in USB 3.0 hub like this one but sourced in the UK on eBay enabled a LattePanda to be mounted in the bay, utilising the Hub to bring four USB 3.0 ports to the front for easy access. More cables then trailed inside the case to a couple of PCI brackets – one for 2x USB plus 1 HDMI (originally intended for 2x USB and 1x eSATA) and one for ethernet. When cable-tied together (because we all do that, don’t we?), it still looks quite tidy.
Again, in prototyping, the same HDMI adaptor used with the Compute Sticks was found to fit perfectly in any Serial port bracket, which are relatively easy to pick up. Given that the HDMI is only used for debug and setup purposes, this isn’t strictly necessary. The same serial port can just about fit an RJ45 adaptor (with a bit of careful, sharp knife adjustment or some rigorous filing) or a USB extension cable, although the tabs tend to bend inwards a litte. It’s fair to say, many of the cables and adaptors were sourced from Kenable and brackets are fairly ubiquitous on old PCs and eBay.
It is suggested that a minimum of ports that need to brought from the GeminX device to the outside of the case for easy access is actually none. If it’s connected over a wireless network, once you’ve set it up and it works, no port access is required, assuming everything is going swimmingly. However, Windows does have a habit of mangling things sometimes, so for debug and usability purposes, it’s handy to have at least a USB port available, and HDMI and ethernet are useful on occasion. In prototype setups, HDMI and USB were always available, along with ethernet if available/necessary. More ports may be necessary if you want to connect scanners/printers and other peripherals directly to the GeminX device.
All of the devices listed as tested run from 5v, so a simple molex splitter with trailing +5v and ground leads has proved useful. In most cases, this has been adjusted to connect to a micro USB cable (for the Compute Stick, Lenovo and LattePanda) or to a standard barrel connector (for the UpBoard and K6A). These aren’t readily available, but aren’t difficult to make. With the 4 port USB hub, this can also power the hub, so only one cable from the PSU is used.
Whilst the images of actual mounted GeminX hardware all relate to RiscPC hardware, the concept is the same for PC cases with PCI brackets, depending on the size of the case.
There are some obvious uses for GeminX. Al lot of them don’t strictly NEED something like GeminX, but they do make it a bit easier and more RISC OSish… Full-featured browsing for one. It offers easy access to the rest of the web that Netsurf can’t access. Especially if the browser is running full screen on GeminX – it looks just like an ordinary window on RISC OS!
Cloud computing is also a feature that GeminX can enable, especially when combined with LanManFS to mount the Cloud folder on the PC natively. DropBox, that near ubiquitous cloud provision, is relatively easy to use via RISC OS in this way. Simply “share” the DropBox folder using Samba on the PC, and then access it through LanManFS or LanMan98. well, not as simple as that sounds, but other tutorials exist to help with that.
Other uses include testing files exported in non-RISC OS formats from RISC OS apps, to see if they actually work in Windows. Word files from Techwriter/EasiWriter, EPS files from ArtWorks, even exported PDFs – it enables last minute tweaks before they get bunged off to printers, friends, colleagues and bosses who all say they can’t do RISC OS, so you should stop using it!
It’s more of a case that the more you use it, the more it incorporates itself into the RISC OS experience. In my experience, anyway. And it opens up a world of new tools to RISC OS, like 3D Printing control software, or just flashy printers and scanners using UniPrint. No, it’s not “native” and it never will be, but it feels a bit like it might be.
Some things still don’t work. YouTube, for example, is too juddery to watch over the connection.
UniPrint/UniServer – this is a real boon to GeminX, as it allows interoperability and facilities way beyond the standard. Launching URLs directly onto the PC is also a fantastic feature, when that PC is already loaded into a RISC OS window.
LanManFS or LanMan98 – both of these apps allow RISC OS to access Samba shares on the PC. This can be especially useful for DropBox access, finding files that have been downloaded in a browser, or as an enhanced “clipboard” for bigger files that can’t use the inbuilt clipboard.
Wake Up – Dave Higton’s app can force GeminX devices to wake up, if Wake On LAN is enabled in the BIOS.
RISCOSbits Easy Resolution options – early in the prototyping stages, before any kind of configuration app was envisaged, one of the easy ways to change the setup was to have multiple !Run files. Ultimately, it made sense to use !Run to open a directory of those files which, when double-clicked, redirected to the Connect file within RDPClient.
Bluetooth Audio Out – as audio redirection fails more often than not, it’s easy to use a Bluetooth audio receiver from any of the above listed boards. It takes a bit of experimentation, but it does mean it’s possible to listen to those YouTube videos, even if they’re not that smooth to watch! Alternatively, for the LattePanda, K6A and UpBoard, a simple 3.5mm socket also works.
Using RDPClient with Linux
Linux can use RDP too. xRDP works well on many Linux setups, including Raspbian and linux variants for the small Orange Pi boards, as used in RISCOSbits Wispy. Indeed an early prototype of Wispy used an Orange Pi One purely as an RDP-connected browser and LibreOffice set up.
Much of the complication of setting up GeminX/RDPClient on RISC OS remain, but in Linux, just use the installed package manager. There may be some hoops to jump through (such as having to remove the built in VNC server in Raspbian before installing an alternative one and THEN installing xRDP) but it provides a very nice (and cheaper!) alternative to Windows GeminX variants for those who just want browsing and occasional file access.
There are plenty of tutorials around to set up xRDP on the Pi or other Linux distros, so this won’t be covered in any depth here.
Current Set Up
As more and more RISC OS machines became available, and therefore needed to be bought(!), ultimately a GeminX in every machine proved too costly for me and meant maintaining too many Windows setups and buying too many versions of programs.
I opted to cable a Brix 2807 with 4GB and an SSD directly to my router so that it could be accessed from any RISC OS machine on the network. It was left on at all times. This was later replaced with a Fujitsu Esprimo Q520 Core i5 with 8GB RAM and a 256GB SSD. This is proving to be very effective and quick and almost feels “native” even though it’s running over the network. And it’s cheap to leave on permanently. It has become the most used machine on the network (and it even has an installation of Virtual RPC!).
I also set up a VPN/DDNS service so that I can access this PC remotely, either from others PCs or from a RISC OS Pi-Top or BÜRP based IGEPv5 machine that I carry around, using GeminX/RDPClient.
In all cases with RISC OS, a modification is used to allow connections at a variety of resolutions on the double click of an Obey file from a directory opened when GeminX is run. This has proved handy and allows more flexibility, depending on the monitor.
Whilst the GeminX concept works well, some things would greatly benefit from a few extra functions. Being a completely incapable programmer, I have no idea if any of these things are easy, hard, or even possible! If any capable programmers are looking for something to do, then please read on…
It would be fantastic to be able to drag icons from RISC OS into the GeminX window and for that file to be placed on the desktop or in the Windows folder where it was dropped. It’d be even better if it worked BOTH ways. It’s suspected that it falls into the “practically impossible” category. But, look at what RComp have already done with UniServer/UniPrint.
Talking of UniServer, the option to launch GeminX (or another app) when launching a URL on the PC so it opens up in, say, Chrome in a Window in RISC OS would greatly enhance RISC OS web browsing until a more full-featured browser than Netsurf comes along (if that will ever happen!). This could also work for documents and other files that often can’t be used natively in RISC OS, like PowerPoint files, EPS files and the like.
Getting sound to work over the RDP connection in a reliable and predictable way would be useful. Most of the board listed have either 3.5mm or bluetooth audio out, or both, but “native” audio would be better.
A proper adjustment to WispyConf to make it work well with GeminX would make life easier. It works as it is, but removing the Wispy bits and making it a bit more friendly, including additional options could greatly enhance its usage. Perhaps an alternative solution built into or added onto RDPClient to configure the !Run file on the fly would be a better alternative.
The concept of GeminX is currently based on code from 2008, but, then again, the core of RISC OS may be much older than that! There is potential if the software were updated to a more contemporary code base to increase reliability, functionality and efficacy. This could lead to:
- Increased efficiency with existing hardware plus compatibility with new hardware;
- Improved mouse handling and video performance (moving video is currently poorly supported);
- Improved graphics acceleration;
- Better clipboard redirection.
Suggestions and further information
As a suggestion, the best GeminX device out of the ones listed above is the LattePanda 4GB/64GB, especially with the four port USB Hub in a 5.25 bay. You may not need all those USB ports, so the hub can be dispensed with. With the hub, though, it’s a bit like having a fully accessible PC inside your RISC OS machine, both physically and in a window. The only downside is it comes without Windows 10 activated, so needs a bit of extra expenditure, unless there’s a license key lying around, unused. It’s also available direct from China through DFRobot (but watch the added import charges) or in the UK from The Pi Hut when it’s in stock.
It’s best to avoid first generation Intel Compute Sticks (such as the Z3735f model), as they had severe performance issues, apparently. The Z8300 version listed above works fine though – it’s actually quite nippy. Second hand versions pop up on eBay from time to time, which could be fine for occasional use. Obviously, your mileage may vary.
If you want to know more about the GeminX concept, there is a mailing list for open, unmoderated discussion about it. An email address will be needed to sign up to contribute, but just reading the archive (should anyone contribute) is just a case of browsing the online archive. Please use it and share your experiences, woes, troubles and solutions with others. The more people contribute, the better the GeminX concept could be.
RISCOSbits has some spare parts left over from the prototyping of GeminX, including cables, USB and HDMI PCI brackets, podule plates, and a few bits of PC hardware useful for GeminX. We can also supply complete GeminX systems on request. Please use the Contact page to get in touch.
Hopefully, if you’ve got this far, you feel that GeminX may be of some use to you, and if you manage to build one for yourself, let everyone know about it on the mailing list! Have fun!