Archive for February, 2015

Last week I got some more parts from which were added to the cardboard controller box without too much hassle.  The first was a weighted arcade spinner control for games like Tempest, Arkanoid, Warlords and anything else that had a paddle controller.  (In essence, it’s a one-axis mouse.) It feels great in the hand but you have to adjust each game’s sensitivity to fairly closely match the original hardware or it may not behave right, doing things like moving “backward” if you spin the knob too fast.  I found a great page to help with this here, which tells you the exact conversion factor for the 1200-pulses-per-rotation Ultimarc controller to most of the older games which typically had much lower resolution encoders.

I also got a full-size trackball (3″ diameter”), because let’s face it, playing Centipede, Crystal Castles, or Missile Command with a joystick is just wrong.

But that’s not what I’m here to talk about today.  What I really wanted to talk about was HDMI video on the Raspberry Pi.  If you’ve read this blog long enough (which is effectively nobody but me), you know that a few years ago I did a whole bunch of HDMI-related test system development at work.  So I know far more about the ins and outs of HDMI that anybody really should have to, but it didn’t really help today…

In figuring out what sort of display to put into this arcade build, the obvious solution is take advantage of the Pi’s built-in HDMI output, which provides an all-digital link directly to an LCD monitor and digital audio as well.  This is a good thing because the Pi’s analog headphone jack is well known for having a lot of noise, for arcane reasons that aren’t worth getting into here.  Adafruit, as a major US purveyor of RPi accessories, has several very nice little LCD displays perfectly suited to embedding into a project at various sizes and resolutions.  They’ve sourced the displays from various Chinese manufacturers and seem to have paired most of them with one from a family of little driver boards that they’re getting from another Chinese manufacturer that does the work of converting the HDMI input to the LVDS standard that the panels natively require.  In particular, the one I chose is 10.1″ diagonal and has a native resolution of 1280×800, which does not quite match the “HDTV” mid-range standard size of 1280×720. This mismatch seems to be typical for small LCDs for some reason.  This matters.

The driver board interrogates the connected LCD panel and determines its native resolution, and then in turn communicates the capabilities of the display back to the computer via the HDMI cable using a standard format called EDID that describes the pixel size of the display and various timing parameters so that the computer can generate video that the display will know how to deal with.  There are several “standard” modes defined by the HDMI spec at typical TV frame sizes, and there are also many other standard modes defined for computer monitors using the same method.  The difference is that the standard for computer monitors does not include audio, while HDMI does, so when a HDMI sender thinks it’s attached to a computer monitor, it stops sending audio.

So we hook this thing up to the Raspberry Pi, and it claims to be a computer monitor, so not surprisingly, no audio comes out.  Well, the Raspberry Pi people were pretty smart and figured this out a long time ago, and added a boot-time setting that is supposed to force the Pi to produce HDMI audio even if the monitor doesn’t claim to support it.  Trouble is, it doesn’t work.  At least not with this particular monitor.  Now, you can force the Pi to produce an “HDMI standard” resolution of video, and then the audio starts working the way it’s supposed to, except then the driver board produces a resized picture at something other than the panel’s native resolution, which while not awful, is not as sharp as it could be. I just want sharp video AND actual audio output. Not too much to ask for, is it?

After Adafruit’s recommended settings failed to produce the desired results after several hours of putzing around with this, trying in vain to use the settings recommended on their site, and a large quantity of unsuccessful reboots and experiments with other settings, I had to give up and settle for a little bit of scaling. Even Adafruit, the seller of the panel, hasn’t figured this part out, but neither do they warn anybody – their forum has a thread full of people wanting to return the monitor, who all think (like I almost did) that it’s defective because they can’t get any sound out of it (with the recommended settings).

I just wanna play some games now!


Linux setup nightmares

So in that last post, I hinted that getting the user-programmable joystick working properly on Raspberry Pi’s Linux OS was, well, less than ideal.  Here’s just how non-ideal it was:


  1. Download and install tools.
  2. Run tools and play around to your heart’s content.
  3. Walk around with a silly glow on your face.


  1. Linux joystick configuration utility has a link on the manufacturer’s download page.
  2. Tool must be compiled on the Pi’s particular Linux release. (This is pretty common since Linux runs on all kinds of different processors, and this tool is not part of the “standard” OS.)
  3. Tool requires libhid library to compile.  Locate and download libhid library source.  Account must be created on a Debian archive site before download is possible.
  4. Libhid requires libusb and lib-usbcompat libraries to compile.  Locate and download libusb/lib-usbcompat sources.
  5. Libhid needs to be manually patched before it will compile properly.  Locate blog post from other unlucky user who, luckily for me, has already endured and documented all this pain, with the appropriate fixes.
  6. With libraries compiled and installed, now the joystick utility can be compiled.
  7. Discover another recommended manual patch, this one to the joystick utility’s source code, apply patch and compile again.
  8. Running the utility to reconfigure the joystick works successfully, except the joystick is dropped by the Linux kernel’s USB HID driver after reconfiguration, leaving it inoperative.
  9. Follow instructions from previous blogger to create manual scripts to allow manual re-binding of the stick to the HID driver after uploading revised configurations.
  10. Discover that the Linux kernel driver also filters out half of the valid joystick location values with any of the customized configurations.  Anonymous comment on previous blog indicates a line in the kernel HID driver that can be commented out to disable overzealous validation of stick’s output values.
  11. Download entire RPi Raspbian Linux kernel source.
  12. Modify 3 lines of code.
  13. Recompile entire Linux kernel with Adafruit’s virtual-machine kernel-o-matic. (A breath of fresh air, something easy in a tedious process).
  14. Install new kernel and cross fingers.  Luckily, it boots correctly and doesn’t brick the device. (If you’re attempting to reproduce my pain, make sure you choose the branch that matches your existing kernel!)
  15. Validate that joystick now functions properly.
  16. Discover that during some bootups, Joystick is detected as “second” joystick rather than first, causing failure to detect stick in rickety old emulator program.
  17. Research and create “udev rules” which allow particular devices to be forced to have specific names in the OS, so as not to make the rickety old emulator grumpy.

Linux:  It’s the way of the future, you know.

I’m late to the party, but I started building a retro arcade machine using a $35 Raspberry Pi as the computer. The various buttons, joysticks, and other bits of control hardware will likely cost at least 5-6x times that amount by the time the whole thing is done.

I’m doing the Linux setup and prototyping control layouts (more about that tomorrow) but I’m hoping my buddy Raman with the awesome wood shop will help build a real cabinet for it when we’re ready. The thing I want to do that’s different from most of the emulator builds people usually do is that I want the control panel to lift out like a fridge shelf and be replaceable. That way when you want to play a game like Tempest or Centipede that needed a spinner or trackball, you just replace the controls. The rest of the time you can have a typical one or two stick-and-buttons setup, but this way the cabinet doesn’t need to be a mile wide to accommodate all the controls at once.

At the moment, though, it looks more like, well, “3rdWorldCade.” But it works great. Thanks to Amazon for the flexible and sturdy “building materials framework!”



%d bloggers like this: