Reading Sega Genesis controllers with Arduino

segaarduino1

NOTICE: This research and implementation in this post is not 100% correct. Please check out my SegaController Arduino library for better code and How To Read Sega Controllers for details on how it works.

Background

The Sega Genesis was my first and favorite childhood game console, so when I first picked up an Arduino a couple years ago, my first thought was to build something, anything, that used a Genesis controller. Unfortunately I got side-tracked by other projects, and the Arduino Uno I’d purchased got set aside.

Fast-forward to this year’s picade build, when I had to re-flash the main controller board, which at its heart is an Arduino Leonardo. Seeing how easy it was to work with, I finally decided to break out my Uno. After a couple sample sketches, I figured it was time start interfacing with some Genesis controllers.

Research

I started poking around online to see what others had done, and couldn’t find quite what I was looking for. What I did find was plenty of information on how the three-button pads worked. Some used that info to implement full three-button support – others, it seems, were satisfied with having just some of the buttons working (essentially using the controller’s innate backward compatibility with the simpler Sega Master System’s two-button controller design). No one had six-button controllers working.

What I want is full three and six-button support, something that I can plug any Genesis controller into and it’ll “just work”, like an actual Genesis console. My requirements therefore are:

  1. Correctly reads connected three-button controllers.
  2. Correctly reads connected six-button controllers.
  3. Automatically detects which type of controller is connected, with hot-swapping.
  4. Bonus: Support more than one controller at a time.

The real godsend to the first two was finding Charles Rosenberg’s Sega Six Button Controller Hardware Info. There he describes almost everything you need to know about how Genesis controllers work. I highly recommend giving it a full read for the really gory details before continuing, but here’s a “quick” overview:

How Sega Genesis controllers work

All Genesis controllers use a standard nine-pin DB9 serial port. On your regular three-button controller, you really have a total of eight buttons: Up, Down, Left, Right, A, B, C, and Start. With nine pins to work with, Sega could easily have gone with one +5v in and eight outputs back to the console and be done with it. But instead, in the interest of backwards compatibility with the Sega Master System (and potentially other DB9 based controllers like the old Atari joysticks), they implemented a simple multiplexer circuit.

Essentially you have three control pins (+5v power, ground, select) and six output pins. By default, all of the output pins are set high (meaning a button press will bring the pin down to ground). The Genesis (or more specifically, the game running on the Genesis) sets the select pin (DB9 pin seven) low, then reads the state of the six output pins to get the states for the Up, Down, A, and Start buttons. Then the game toggles the select pin to high, and re-reads those same six output pins to get the states of the Up (again), Down (again), Left, Right, B, and C buttons.

DB9 Pin Select is low Select is high
1 Up Up
2 Down Down
3 Ground Left
4 Ground Right
5 Control: +5V
6 A B
7 Control: Select
8 Control: Ground
9 Start C

The algorithm is pretty straight forward to implement on the Arduino, polling the controller exactly the way a Genesis game would. This satisfies my first requirement. Now, things get a little more complicated with the six-button controller:

DB9 Pin Select is low Select is high Every 3rd select pulse
1 Up Up Z
2 Down Down Y
3 Ground Left X
4 Ground Right
5 Control: +5V
6 A B
7 Control: Select
8 Control: Ground
9 Start C

First, let’s call each dropping of the select pin to low then back to high a “select pulse”. Now, on every third select pulse the six-button controller will instead report back the states of the X, Y, and Z buttons (instead of Up, Down, and Left). On its face, it looks like we couldn’t have a game that supports both three and six-button controllers, because how does a game know what kind of controller is connected? On every third pulse how does a six-button enabled game know whether to use the first table or the second? On every third pulse, how does a six-button controller know not to report X, Y, Z for games that only support three-buttons? If the game and controller aren’t on the same page and they use the wrong mappings, they’ll record incorrect button presses.

How do the games and controllers make the right decisions?

One part of the answer (as described in Rosenberg’s notes) is in how often games actually poll the controller. The three-button controller uses dumb direct logic, which means it always uses the first table. It also means that technically you can poll the controller state super-fast (say every 50 microseconds) or super-slow (say every 20 milliseconds) and always get the same result. Now typically, a game is only going to poll the controller once per game frame (sixty times per second, or every 16.6 milliseconds). Which means, at the time of the six-button controller’s release, the vast majority of the games already published (which were three-button enabled only) only sent a single select pulse every ~16 milliseconds.

The six-button controller can use this to its advantage. Instead of dumb direct logic, it uses an IC to watch how often the select pulses come in. The IC knows that (given the game indicates it wants six-button mode), it should return the states of X, Y, and Z on every third select pulse. But it also knows that most games only support three-button mode, so a safe default is to just pretend to be a three-button controller and ignore reporting X, Y, and Z on every third pulse.

How does the controller decide? The frequency of the select pulses. If the IC only sees one select pulse every ~16 milliseconds, or one pulse per game frame, then its best bet is to take the safe route and assume three-button mode. In this way, the six-button controller is backwards-compatible, and most games will never get any incorrect button presses.

If that’s the case, how does a game indicate that it actually wants those X, Y, and Z buttons?

If the game believes that a six-button controller is attached, it will instead pulse the select line three times very quickly in one game frame. The first two times the game reads (and the controller reports) the button presses for three-button mode. Then the game pulses the controller a third time. At that point, the controller’s IC, seeing how quickly those pulses came in, presumes the game wants X, Y, and Z, so it reports X, Y, and Z.

So to sum up: if a game just wants the three-button control states, it pulses once every frame and uses the first table to read the results. If a game wants six-button control states, it pulses three times in one frame, using the second table to read the results. With this in mind, we can now read both controller types, which satisfies the first two of my requirements. We can easily implement an Arduino sketch that implements one or the other algorithm, if we already know which type of controller we’re going to have connected.

But what about my third requirement? What if we want one sketch that implements both modes? How do we make our board detect what kind of controller is connected?

This one took a little bit of experimenting to figure out, since Rosenberg’s notes don’t address the issue. Turns out the six-button controller’s IC has another trick up its sleeve with watching how fast those select pulses come in. As we just saw, since most games only expect three-button controls, the controller can default to three-button mode, and seeing slow pulses, will stay in three-button mode.

But now, if the game wants to check for a six-button controller, it can send rapid select pulses when a controller is connected, and if it’s a six-button controller, the IC will report that both the Up and Down buttons are being pressed at the same time!

Under normal circumstances this is impossible, as the controller’s d-pad rocks in the direction you press it. So with this neat trick, the controller lets the game know that a six-button controller is connected, giving the game to option to start polling the controller in six-button mode.

The way we implement this is simple: by default we poll in three-button mode very quickly. For three-button controllers, this works perfectly. After every pulse, we can check for both Up and Down being pressed at the same time. If we see that, we know a six-button controller is attached, so we switch to six-button mode, pulsing more slowly so that we don’t reset the IC.

This solves the first part of my third requirement: detecting when a six-button controller is connected. But what about the other way? The way it stands, once we connect a six-button controller, and our board switches to six-button polling, it’s stuck that way until we reset the board. If we hot-swap from a six-button to a three-button controller, we’ll get those annoying paired inputs (specifically, pressing Up will return Up and Z, Down will return Down and Y, Left will return Left and X).

What we need is a way of knowing when a controller is disconnected, so that we can switch back to the default three-button polling. Turns out we have everything we need in the tables above, something that works for both three and six-button controllers.

At the very beginning I said that by default the console puts all six of the DB9 output pins high, so that a button press causes the pin to drop low. So if no controllers are connected those output pins should stay high. Only a button press from a connected controller will drop a pin low, right? We could just press a button to let the board know we have a controller connected, but wait, there’s a better way!

As we can see in the tables above, when the select pin is low, DB9 pins three and four both go low, regardless of any button presses. So in effect, the controller presses imaginary buttons on pins three and four when select is low automatically. So, all we have to do is watch those pins – if they go low when select is low, then we know a controller is connected. If they’re high when select is low, it means the controller is no longer connected.

In implementation terms, when select is low, we can simply check those two pins like we would for any other button, and map the results of those imaginary “On” buttons. Watching those “buttons” we know when a controller is connected or not, and therefore we can easily switch back to three-button mode when a controller is disconnected. With that we now have everything we need to satisfy my main three requirements for the board. As for the 4th and final bonus requirement, recognizing that we only needed seven pins to read one controller, we’ve got plenty of left-over pins on the Uno to cover connecting one more.

The Sketch

Ok, so now for the sketch. Our basic algorithm is the following:

  • Default to three-button polling as fast as possible, using the first table and select pulsing algorithm.
  • If you ever see both Up and Down pressed at the same time, switch to six-button polling, using the second table and select pulsing algorithm.
  • If you ever see the “On” button state go away, switch back to three-button controller polling.
/*
 * Sega Controller Reader
 * Author: Jon Thysell <thysell@gmail.com>
 * Version: 1.0
 * Date: 7/26/2014
 *
 * Reads buttons presses from Sega Genesis 3/6 button controllers
 * and reports their state via the Serial connection. Handles hot
 * swapping of controllers and auto-switches between 3 and 6 button
 * polling patterns.
 *
 */

// Controller Button Flags
const int ON = 1;
const int UP = 2;
const int DOWN = 4;
const int LEFT = 8;
const int RIGHT = 16;
const int START = 32;
const int A = 64;
const int B = 128;
const int C = 256;
const int X = 512;
const int Y = 1024;
const int Z = 2048;

// Controller DB9 Pin 7 Mappings
const int SELECT[] = { 8, 9 };

typedef struct
{
  int player;
  int pin;
  int lowFlag;
  int highFlag;
  int pulse3Flag;
} input;

// Controller DB9 Pin to Button Flag Mappings
// First column is the controller index, second column
// is the Arduino pin that the controller's DB9 pin is
// attached to
input inputMap[] = {
  { 0,  2,  UP,    UP,     Z}, // P0 DB9 Pin 1
  { 0,  3,  DOWN,  DOWN,   Y}, // P0 DB9 Pin 2
  { 0,  4,  ON,    LEFT,   X}, // P0 DB9 Pin 3
  { 0,  5,  ON,    RIGHT,  0}, // P0 DB9 Pin 4
  { 0,  6,  A,     B,      0}, // P0 DB9 Pin 6
  { 0,  7,  START, C,      0}, // P0 DB9 Pin 9
  { 1,  A0, UP,    UP,     Z}, // P1 DB9 Pin 1
  { 1,  A1, DOWN,  DOWN,   Y}, // P1 DB9 Pin 2
  { 1,  A2, ON,    LEFT,   X}, // P1 DB9 Pin 3
  { 1,  A3, ON,    RIGHT,  0}, // P1 DB9 Pin 4
  { 1,  A4, A,     B,      0}, // P1 DB9 Pin 6
  { 1,  A5, START, C,      0}  // P1 DB9 Pin 9
};

// Controller State
int currentState[] = { 0, 0 };
int lastState[] = { -1, -1 };

// Default to three-button mode until six-button connects
boolean sixButtonMode[] = { false, false };

void setup()
{
  // Setup input pins
  for (int i = 0; i < sizeof(inputMap) / sizeof(input); i++)
  {
    pinMode(inputMap[i].pin, INPUT);
    digitalWrite(inputMap[i].pin, HIGH);
  }

  // Setup select pins
  for (int i = 0; i < 2; i++)
  {
    pinMode(SELECT[i], OUTPUT);
    digitalWrite(SELECT[i], HIGH);
  }

  Serial.begin(9600);
}

void loop()
{
  readButtons();
  sendStates();
}

void readButtons()
{
  for (int i = 0; i < 2; i++)
  {
    resetState(i);
    if (sixButtonMode[i])
    {
      read6buttons(i);
    }
    else
    {
      read3buttons(i);
    }
  }
}

void resetState(int player)
{
  currentState[player] = 0;
}

void read3buttons(int player)
{
  // Set SELECT LOW and read lowFlag
  digitalWrite(SELECT[player], LOW);

  delayMicroseconds(20);

  for (int i = 0; i < sizeof(inputMap) / sizeof(input); i++)
  {
    if (inputMap[i].player == player && digitalRead(inputMap[i].pin) == LOW)
    {
      currentState[player] |= inputMap[i].lowFlag;
    }
  }

  // Set SELECT HIGH and read highFlag
  digitalWrite(SELECT[player], HIGH);

  delayMicroseconds(20);

  for (int i = 0; i < sizeof(inputMap) / sizeof(input); i++)
  {
    if (inputMap[i].player == player && digitalRead(inputMap[i].pin) == LOW)
    {
      currentState[player] |= inputMap[i].highFlag;
    }
  }

  // When a six-button first connects, it'll spam UP and DOWN,
  // which signals the game to switch to 6-button polling
  if (currentState[player] == (ON | UP | DOWN))
  {
    sixButtonMode[player] = true;
  }
  // When a controller disconnects, revert to three-button polling
  else if ((currentState[player] & ON) == 0)
  {
    sixButtonMode[player] = false;
  }

  delayMicroseconds(20);
}

void read6buttons(int player)
{
  // Poll for three-button states twice
  read3buttons(player);
  read3buttons(player);

  // After two three-button polls, pulse the SELECT line
  // so the six-button reports the higher button states
  digitalWrite(SELECT[player], LOW);
  delayMicroseconds(20);
  digitalWrite(SELECT[player], HIGH);

  for(int i = 0; i < sizeof(inputMap) / sizeof(input); i++)
  {
    if (inputMap[i].player == player && digitalRead(inputMap[i].pin) == LOW)
    {
      currentState[player] |= inputMap[i].pulse3Flag;
    }
  }

  delayMicroseconds(1000);
}

void sendStates()
{
  // Only report controller states if at least one has changed
  boolean hasChanged = false;

  for (int i = 0; i < 2; i++)
  {
    if (currentState[i] != lastState[i])
    {
      hasChanged = true;
    }
  }

  if (hasChanged)
  {
    for (int i = 0; i < 2; i++)
    {
      Serial.print((currentState[i] & ON) == ON ? "+" : "-");
      Serial.print((currentState[i] & UP) == UP ? "U" : "0");
      Serial.print((currentState[i] & DOWN) == DOWN ? "D" : "0");
      Serial.print((currentState[i] & LEFT) == LEFT ? "L" : "0");
      Serial.print((currentState[i] & RIGHT) == RIGHT ? "R" : "0");
      Serial.print((currentState[i] & START) == START ? "S" : "0");
      Serial.print((currentState[i] & A) == A ? "A" : "0");
      Serial.print((currentState[i] & B) == B ? "B" : "0");
      Serial.print((currentState[i] & C) == C ? "C" : "0");
      Serial.print((currentState[i] & X) == X ? "X" : "0");
      Serial.print((currentState[i] & Y) == Y ? "Y" : "0");
      Serial.print((currentState[i] & Z) == Z ? "Z" : "0");

      Serial.print((i == 0) ? "," : "\n");
      lastState[i] = currentState[i];
    }
  }
}

All you have to do is upload the sketch and connect the controller’s DB9 pins to the Arduino following the mapping in inputMap in the code. Then start up the Serial Monitor so you can see the output from the controller on your PC.

Here’s a closeup of how I’ve wired my Uno to a male DB9 breakout board (you can wire straight to the controller, or a male DB9 port, but I found the board the easiest solution):

segaarduino2

The sketch is also set up for a second controller connected to the analog pins on the other side of the Arduino, though I only had one male DB9 breakout board. Also note that this is my first real Arduino sketch, so I’m sure there are some best practices I’m breaking in my design.

I can already see room for future improvements. Right now I report the controller states over the serial connection as strings – easy to debug, but slow and wasteful. Of course, in your own sketches, you can just read the currentState integers directly.

Hope this helps anyone else out there trying to interface with Genesis controllers. Happy hacking!

/jon

PS. Obviously in the process of plugging and unplugging controllers, you may see some errant random button presses recorded. In the world of video games, this is to be expected, and only lasts for a second. If however, you’re planning on doing anything “bad” with a button press (say enabling a thermonuclear detonator), you might want to avoid hot-swapping controllers.

PPS. Final note, concerning the six-button controller’s “mode” button. Some games (notably Ms. Pac Man), don’t follow the rule of only polling the controller once per game frame, and select pulses more often. This causes erratic behavior as incorrect buttons presses are recorded. Ostensibly, when you plug in a six-button controller with the mode button held down, that signals the IC in the controller to always be in three-button mode and never report X, Y, or Z. Unfortunately, I couldn’t get it to work with my sketch and gave up because I saw no reason to limit my six-button controller to three-buttons anyway.

Update 29-SEP-2014: I’ve uploaded a new version of the sketch in Sega Genesis controllers and Arduino revisited, which includes support for reading the “Mode” button and reporting button presses as keyboard key presses (on compatible Arduino boards).

Update 26-JUN-2017: The source is now available on GitHub here.

Update 28-JUN-2017: I’ve announced a newer, stable, reusable version at Introducing the SegaController Arduino library.

Building the Picade Mini Part V, final touches

In Part I I put together the cabinet, in Part II I got the main electronics installed, in Part III I created a custom rear jack panel, and in Part IV I got everything up and running 95% how I wanted.

After that last post, I took the machine to work to show off. Got lots of people to try it out, and the biggest bit of feedback was people wanted their MAME games. I also really wanted to play six-button Sega Genesis games. So I spent some time updating my secondary RetroPie build to the latest version, which gave me a much more functional Genesis emulator, including save state support and six-button controls. Then I switched to mame4all-pi, and put the correct MAME roms on the box, which finally gave me working MAME games.

Once I was sure the update would improve things without breaking my Picade, I went ahead and switched back to that build. I updated the Picade, and when that was done, it turns out I was using the wrong resolution before. The Picade Mini has a 4:3 screen, and I was outputting widescreen before. Once I fixed that, I changed the splashscreen to use the official Picade art from the Kickstarter.

The last bit of work was getting MAME working. It involved making all of the requisite folders mame4all-pi needs to save configs and high scores. Once that was done, I spent the time to go into MAME and reconfigure all of the controls to use what I have on my joystick. Everything I’ve done is in the updated configs file I’ve attached at the bottom of this post.

Here’s an updated video of the build in action:

And the original video if you missed it:

Enjoy!

/jon

My Picade Configs [184k ZIP] Updated 02-JUL-2014

I’ve configured my build to use as much screen real estate as possible without compromising on aspect ratios. The buttons are set up such 1-6 on the top map to playing buttons (Y X L B A R), the front are for Start and Select, and the side buttons are Escape and Control. Holding the right side button while I hit another button performs various emulator commands:

  • Left side – exit the emulator and return to the menu
  • B (bottom row, first button) – lower volume
  • A (bottom row, 2nd button) – raise volume
  • R (bottom row, last button) – hits Ctrl+C to forcefully exit any game
  • Y (top row, first button) – load state
  • X (top row, 2nd button) – save state
  • Select – bring up emulator menu

Includes configs for all of the RetroArch emulators, and for mame4all-pi. Feel free to change the configs to support your own needs.

Building the Picade Mini Part IV, let’s finish this up!

In Part I of this build, I put together the main parts of the cabinet. In Part II I got the main kit’s electronics installed and tested. In Part III I created a custom rear jack panel.

Next step was to finally install the rear door. The included hinges and latch worked perfectly.

Rear panel attached Rear panel open

With the rear door in place, it was time to install the Raspberry Pi and put into effect my grand wiring scheme.

The goal has always been a single power supply with a single power switch to get me into a ready to play system. With that in mind I installed a single throw, double pole switch.

The first pole is responsible for powering the monitor and customized USB hub directly. For the monitor I used the cut off the barrel-end of the included power supply. For the USB hub I severed the power leads for the host plug (so that it would never draw power from the Raspberry PI itself) and ran new power lines straight out the side. Simple enough, and both devices power up as soon as I hit the switch.

Rear panel wired 2Now for the Raspberry Pi itself, I need something else. If I run power straight from the switch to the Pi, then killing the power threatens corrupting the Pi’s SD card and killing the machine.

Since it’s a common enough problem, and since I didn’t want to reinvent the wheel, I simply used a Mausberry shutdown circuit. In concert with a small script that runs on the Pi itself, what the shutdown circuit does is uses a pair of GPIO pins on the Pi to monitor when the Pi is running. When the switch is thrown, the circuit tells the script to tell the Pi to perform a clean shutdown. After the shutdown occurs (killing the script), the circuit finally cuts power to the Pi.

So essentially I wire power straight from my jack to the shutdown circuit, and attach the second pole of my switch to the designated spots on the shutdown circuit. (There’s also room for an emergency swtich to reset the Mausberry circuit itself, but I didn’t bother).

Rear panel wired 1Sum total is that when the power switch is turned on, everything is powered on. When the switch is turned off, power is cut immediately to the monitor and USB hub, and a signal is sent to the Pi to shutdown cleanly. About 2-3 seconds later, the Pi shuts down and power is cut to the Pi.

So as long as I don’t physically pull out the jack, I can safely hit the power switch to power off the machine, even in the middle of a game, as long as I wait for a few seconds before pulling the actual plug. The speakers pop when the Pi loses power, so I know I’m safe to unplug.

The last bit of hardware setup was to connect the Pi in to everything. I connected the shutdown circuit and Ethernet jack to the Pi and both the rear USB jacks and the Picade controller to the USB hub (I’ll explain why later). I connected the HDMI from the monitor to the PI and the audio out from the Pi to the Picade board.

Finally, time to start playing with the software!

My first attempt at building an emulator rig with Raspberry Pi used the wonderful RetroPie Project. Since I had already gotten that up and running on another build, (with lots of games working) I decided to take a shortcut and clone that SD card as my starting point for my Picade.

First I tweaked the config.txt to optimize the display for the Mini’s screen (I’ll attach my config at the end of the post). Then I configured the Picade joystick as the new (and only) device. Again, I ended up needing to reprogram the Picade controller, as the default key selections, while great for MAME, actually caused all kinds of problems with RetroArch, which is the framework a lot of my emulators were using. (Again, I’ll add my configs to the end of the post).

The last real configuration (and it still needs some work) was for audio. By default, if you have HDMI connected, the Pi won’t output audio from the 3.5mm jack. I fixed that with the Raspberry Pi sound troubleshooting guide. (Hint, it’s amixer -c 0 cset numid=3 1).

The only audio hiccup I still have is that by default the sound is at max volume at boot. And it is LOUD. Even worse, it seems like potentially something is shorting on the Picade board- such that if the Picade board is wired directly to the Pi, and a loud sound plays, the controls straight up die. The solution I found for the controls was to connect the Picade controller board to the USB hub instead. As for the loud sound, my current workaround is to go in and out of the settings for Emulation Station (the front-end UI for the emulators) after boot. For some reason this resets the audio to regular ranges until I reset or power down.

After figuring that out, the box pretty much runs the way I want it to. I can play NES, SNES, GB, GBC, and GBA without any problems. Master System doesn’t work too well. Genesis works but the emulator (Picodrive) for some reason is locked to 3 button mode only. I haven’t gotten MAME to work yet- none of my roms are the right version it seems.

At this point the project is basically done. I might add a headphones jack, but the joystick itself is super loud anyway. The whole thing fits comfortably on my lap to play, but the front edge is sharp on the wrists so I might grind that down a bit.

Anyway, hope you enjoyed following my build!

/jon

My Picade Configs [184k ZIP] Updated 02-JUL-2014

I’ve configured my build to use as much screen real estate as possible without compromising on aspect ratios. The buttons are set up such 1-6 on the top map to playing buttons (Y X L B A R), the front are for Start and Select, and the side buttons are Escape and Control. Holding the right side button while I hit another button performs various emulator commands:

  • Left side – exit the emulator and return to the menu
  • B (bottom row, first button) – lower volume
  • A (bottom row, 2nd button) – raise volume
  • R (bottom row, last button) – hits Ctrl+C to forcefully exit any game
  • Y (top row, first button) – load state
  • X (top row, 2nd button) – save state
  • Select – bring up emulator menu

Feel free to change the configs to support your own needs.

Update: See the video: Picade Mini build running RetroPie.

Update: Part V is up.

Building the Picade Mini Part III, with a custom rear jack panel!!!

Time for another Picade Mini update! In Part I of this build, I put together the main parts of the cabinet. In Part II I got the screen’s faulty driver board replaced and the screen and control electronics tested.

Now, according to the instructions, my last construction steps are to install the rear door and mount my computer. Then I should be good to start setting up the software. But, you don’t own something until you’ve modify it, so let’s modify this cabinet.

Starting pieces for a jack panel

I wanted to have a cleaner rear interface than just a bunch of cables sticking out the pre-cut slots in the bottom of the rear door. My idea was to install some jacks, so my first step was to create a template of the jacks that I want- 2 USB, 1 power, 1 Ethernet, and a nice power switch.

Template board Port layout on the template

At first I saw two choices: cut individual ports directly into the rear door, or cut one large hole and make a separate jack panel to mount there. Either way I’d need a template, so I did just that with a thin sheet of wood with graph paper glued to it. Then I traced out and labeled the jacks where I wanted them on the graph paper.

Drilling the power jack with the drill press Filing out hoels for the jacks

I used a drill press to cut the hole for the power jack and for the screws of the other jacks. Then I used a jigsaw and file to make the holes for the jacks themselves.

The jacks successfully mounted to the template front The jacks successfully mounted to the template back

All in all, I was pretty happy with the template. It was a nice compact arrangement of everything I wanted. Next it was time to decide whether to start cutting holes in that rear door, or make a separate panel. Given the thickness of the rear door, I chose to make the separate panel.

The next question was what material to use? My first idea was to use a thin sheet of metal, or even to use another thin panel of wood. Instead my future father-in-law (whose workshop and tools I was using for this part of the project) suggested I try plastic, specifically a light switch blank. He thought it’d be easier for me to work with and look better than what I could make out of wood or metal.

Sizing up a light switch panel to the rear door Drilling ports into the panel

Home Depot carried them in black for $0.89, so we picked up two and I got to work. He was right; the panel was really easy to work with. I transfered the template design onto it like a stencil with an awl and cut away. I’ll have to keep light switch blanks in mind when I’m working on electronic enclosures in the future.

Sizing the completed panel to the rear door Drilled holes in the door to cut out with a jigsaw

After cutting out the holes and making sure everything fit, it was time to  figure out where I wanted to mount it on the rear door. I chose the center bottom as the place to give me the most room inside the cabinet.

A hole in the door!

It was time to cut a hole in that beautiful rear door. I drilled holes to mount the panel and drilled out the corners so I could take the jigsaw to it. I cut out the smallest square I needed, and then for the moment of truth…

Finished jack panel front Finished jack panel rear

Viola! My custom jack panel installed perfectly, and looks way better than I expected! I realize it’s a little dirty in the pic- it got some glue stuck to the panel and I was too excited to take a photo to clean it off first. Now all I have left for the physical part of this build is to wire everything up and get that rear door installed onto the cabinet.

Stay tuned for the next part when I do just that!

/jon

Update (03/05/14): Part IV is up!

Update (03/05/14): See the video: Picade Mini build running RetroPie.

Building the Picade Mini Part II, new screen!!!

In the first part of this build, I got the majority of the main cabinet together, but I stalled out when the LCD refused to output correctly. The guys at Pimoroni finally identified that the LCD driver board had a bad firmware on it. A few emails later and a new board was on its way.

Testing the Picade Mini's new LCd driver boardThe hardest thing was getting the new driver board in place in the tiny space of the cabinet. I ended up removing the whole screen assembly from the cabinet to make life easier.

Installing the new LCD driver boardReplacing the board involved popping off the old one (pinching the little plastic pins that held it to the back of the screen) and disconnecting two ribbon cables- one large one for the screen’s control panel, and one tiny one that connected the board to the screen itself. Then I replaced the old board with the new one, reconnected the cables and powered up the screen.

A couple things to note. First, the thin ribbon cable from the board to the screen has to be in perfectly or the screen won’t work. You can’t just jam the cable in there (as I tried). There are two tiny little tabs on the edges of the board’s connector that must be pulled out so that the cable goes in easily, then pushed back in to pinch the cable in place. Secondly, by default the screen is set to go to sleep after 15 seconds of no signal, and you must have a signal in order to use the OSD menu. So if you want to play around with the screen’s settings at this point in the build, you’ll need something to display connected.

Installing the marqueeAfter I’d tested and reinstalled the screen, the next step was to go back and finish off the top of the cabinet, namely the marquee. This began probably the longest part of the evening because all of the tabs and slots for the top of the cabinet didn’t fit together nicely- I had to take sandpaper and a file to everything and still ended up forcing some bits in.

Testing the joystickOnce I got the marquee on and the top bolted shut, the build finally started to feel solid. Next was to fasten down the main control panel, but since I’d popped it in and out so many times while fixing the screen (and to clean out sawdust), I first decided to power up the controls and verify that everything was still working as expected.

Installing the control panelInstalling the control panel was much a repeat of the marquee, ie. none of the tabs fit quite right. It’s expected that you have to squeeze the cabinet a little to get the control panel on- you don’t want anything popping off in the middle of a game, but it was still more work than I expected.

Testing the controlsAfter getting the controls bolted on, it was back to testing. Namely I connected the Picade PCB direct to my laptop and verified that all of the buttons reported correctly and reliably.

Testing the connections againConfident that the buttons were ready to perform, I skipped ahead and installed the LCD’s control panel onto the side of the cabinet. I don’t intend to actually use it much- I want the screen to come on right when I hit the main power, and stay on until I shut down the machine. I don’t want to fiddle with any screen settings on this any more than I want to on any other device.

Testing the screen controls with the screen onA word on the screen buttons themselves- clever idea, with the acrylic buttons on top of the little buttons, but in my testing there was an inconsistent feel to them. I connected the screen to my test RasPi and while the power and input select buttons give a good solid click, the others feel mushy. I might need to fiddle with them a little more, but as I said, since I don’t plan on using them much anyway, it’s not my top priority.

Well, that’s it for this stage of the build. Picade Mini, looking good from the frontI have what’s amounting to a pretty nifty little arcade machine going on here, and as far as what the kit offered, I’m just about done. According to the kit all that’s left is installing the rear door, which I’ve skipped for now, and connecting up a RasPi. So now is where the fun really begins – though I still intend to mount my RasPi to the back door, I also want to make some major usability modifications first. Namely I want to install externally facing USB, Ethernet, headphone, and power jacks into the door, as well as a single physical power switch.

A single power switch with a single power supply means a more creative wiring system than hiding a bunch of wall-warts inside the cabinet. I also plan on adding a powered USB hub in there, which I’ve already rewired in advance to not draw power from the little RasPi. Basically I think I have all the pieces I need and I know how to wire it up- the main issue now is deciding where and how to mount everything.

But we’ll have to save that for next time. Stay tuned!

/jon

P.S. Big thanks to Jon at Pimoroni for getting me that replacement board so quickly. Despite all the nervousness one might have about the Kickstarter model, I’ve been thoroughly impressed by the turnout of this kit.

Update (02/10/14): Part III is up!

Update (03/05/14): See the video: Picade Mini build running RetroPie.