NOTE: This Gist was an early write-up of this blog post, part of what became an eleven-part series on my arcade cabinet. I'd suggest you read that post instead of this, but some of the comments on this Gist contain updates and field reports that you might find useful.
RetroPie, LED control, and you
I wanted LEDBlinky-style functionality out of my RetroPie cabinet. But I didn't need RGB control or magical frontend integration or anything like that. I had buttons with simple single-color LEDs.
I've got a simple control panel with six buttons per player. All I wanted was this:
- When I launch Street Fighter 2, all twelve buttons should light up.
- When I launch The Simpsons, only the first two buttons for each player should light up.
- When I launch Pac-Man, none of the buttons should light up.
You get the idea.
Here's a demonstration in the form of a shaky video.
Here's how I did it.
I got a Pac-Drive from Ultimarc. It's got 16 terminals for LEDs. 1–6 control Player 1's buttons; 7–12 control Player 2's buttons. The remaining four terminals got devoted to the start buttons (13 and 14), the coin buttons (both on 15), and four small buttons I use for functions (all on 16).
After all that's wired up, all you need is a single USB cable running to your Pi — or, even better, to a powered USB hub that is itself connected to the Pi. The LEDs get powered from USB.
Most of the software for the Pac-Drive is meant for a Windows environment. After some digging, I found this third-party utility for Linux that allows for controlling a Pac-Drive from the command-line. It was exactly what I needed, though it was eight years old and took some wrangling to get installed on a Pi.
From a stock RPi with Raspbian Jessie, you'll need at least these packages:
sudo apt-get install libusb-dev build-essential
You'll also need
libhid, which is hard to find because it's deprecated. There's no package for it in APT, the source code is behind a login for some reason, and then you've got to make a change to the source to get it to compile on the Pi. I solved all three problems by applying that fix and then putting up the fixed source on my server.
From your home directory:
mkdir src && cd src wget "http://andrewdupont.net/pi/libhid-0.2.16.tar.gz" tar xvzf libhid-0.2.16.tar.gz cd libhid-0.2.16 ./configure make sudo make install
Now we're ready to install the
cd ~/src wget "http://www.zumbrovalley.net/pacdrive/dnld/pacdrive_0_2.tar.gz" tar xvzf pacdrive_0_2.tar.gz cd pacdrive_0_2 make
If you do
make install it'll put the
pacdrive binary in
/usr/bin, though you can edit the
Makefile beforehand to specify a different directory. I did neither; I just manually copied the
pacdrive binary to
/home/pi/bin. (If you do this, make sure you put
/home/pi/bin in your
Hooking into RetroPie
So now you can control the LEDs from the command line, but that doesn't help much.
How will it know which LEDs to light up for which game?
One option here would be to use something called
controls.dat, which is a project for cataloguing the controls for most MAME games. (4-way joystick? 8-way? How many buttons? How many players? Hotseat, or does each player have their own controls? And so on.)
The problem with this approach is that (a) the
controls.dat project is dormant; (b) there are lots of gaps in its database.
If you're anything like me, you don't need a comprehensive solution. I don't care how many buttons some random mah-jongg game uses because I'll never play it. I've got about 100 arcade games set up and I don't mind specifying their configs manually.
So here's what I came up with:
- Create a
- Inside that directory, create another directory for each system you want to control. (I've got
daphne; you might have others.)
- Inside each system's directory, define a text file whose name matches the name of the game. For instance:
simpsons2pis the ROM name for the two-player version of The Simpsons, so I'd create a file called
simpsons2p.cfgwith these contents:
1, 2, 7, 8. In other words: light up buttons 1, 2, 7, and 8, and turn off all the other LEDs.
This way it's simple to define new configs and simple for RetroPie to know where to look for configs knowing only the system and the ROM name.
How will it light up the LEDs on game launch?
All emulator launches go through something called
runcommand.sh. There's a new feature in RetroPie 4.x: the ability to define scripts called
runcommand-onend.sh. These scripts will run before a game starts and after a game ends, respectively, and they receive some metadata, including the name of the system and the name of the game.
If you want to do it exactly how I did:
nano runcommand-start.sh(shouldn't need
sudo, but I might be wrong)
- Paste the contents of the
runcommand-onstart.shfrom this gist.
- Repeat steps 3 and 4 for
These scripts reference two other scripts called
led-end, which you should put in
/home/pi/bin. This is completely overengineered, but it lets me define some buttons as "always on" without having to include them in every single config file. That happens in a file called
/home/pi/.ledrc. Here's what mine looks like:
+13, +14, +15, +16
That means "always light up both start buttons, the coin buttons, and the small function buttons." You can read the source of
led-start to learn more.
If you want to use these scripts, you'll need Ruby, which isn't installed by default on Raspbian Jessie.
sudo apt-get install ruby2.1 should take care of it.
What if a game doesn't have a config? Well, if you followed these instructions to the letter, none of the buttons for either player will light up. That's fine with me, because I don't have any games without configs. You might want it to do something different in that situation.
If this doesn't work, it's probably because I left something out. Leave a comment and we'll figure it out together.
@nr002541 First of all, make sure you have Ruby installed —
which rubyfrom the terminal should tell you.
Next, make sure that the scripts in question can be executed...
If it still doesn't work, try doing some logging within the scripts. At any point you can add a line like...
and it will append that text to
debug.txt. That should help you narrow down where it's getting stuck.