Creating your own MAME Arcade Controllers
Right, now for something completely different... The following article goes out to all those 80s kids who remember that familiar clicking sound of real mechanical microswitches. We all spent our pocketmoney on Bubble Bobble, Snow Bros, Rampage, Street Fighter; but now you don't have to. Just install MAME and build the following controllers...
Here's the photo album of the construction of the controllers...
Note, before starting this, you should really just skip the keyboard hacking and buy one of these.
Also, for a LOT of information on doing this, visit Arcade Controls.
Initial thinking...
All peripherals for a computer need to connect via an I/O port. Although there are quite a few available on most modern machines, the one we will use is USB. I've chosen this port because they will be around for decades and the old style Serial, LPT and Gameports have pretty much already been phased out.
Now, there are many options once we choose USB:
- My Arduino to accept all the inputs and feed them to a computer...
- One of the many off-the-shelf 'keyboard' emulators...
- or I could just rip open a cheap USB Keyboard and wire up the keys...
From the above, the cheapest method is to rip open a keyboard. Officeworks here in Australia was selling the Microsoft Wired Keyboard 600 for AUD$11.97 and I couldn't resist.
One big question here was cabling. Once I'd hacked a keyboard apart and wired up one controller.. would I then use other keys from that first keyboard and run a cable to the second controller? I looked at the price of data cabling and realised it was cheaper to buy another USB keyboard than it was to rig up a sophisticated central box that both controllers ran to.
I therefore bought 2 USB keyboards.
Now, there is an issue here... I will be 'emulating' keyboard buttons presses when the joystick buttons are pressed. Since once computer can accept multiple different keypresses at once, this will work, but it cannot distinguish multiple presses of the same letter/key from different keyboards (i.e. if the 'A' key is pressed from two different devices.) This means that the second controller will have to be mapped to a different set of keys... pretty obvious, yes?
Update/Note that buttons 5 and 6 for Player 2 aren't set by default... I've set these to I and K as they were free... for some reasons I didn't check Player 3 and 4 controls first and this is a direct conflict with Player 3 directional keys! So, you can use the below but be careful... in my this blog post I've remapped them to U and O respectively.
Button | Keymapping 1 | Pins | Keymapping 2 | Pins |
---|---|---|---|---|
Joy UP | UP | 12, 24 | R | 11, 22 |
Joy LEFT | LEFT | 12, 26 | D | 16, 21 |
Joy DOWN | DOWN | 4, 26 | F | 11, 21 |
Joy RIGHT | RIGHT | 8, 26 | G | 11, 24 |
Button 1 | L-CTRL | 13, 25 | A | 18, 21 |
Button 2 | L-ALT | 9, 24 | S | 17, 24 |
Button 3 | SPACE | 1, 26 | Q | 18, 22 |
Button 4 | L-SHIFT | 10, 23 | W | 17, 23 |
Button 5 | Z | 18, 20 | I | 6, 22 |
Button 6 | X | 17, 20 | K | 6, 21 |
Player Button | 1 | 18, 19 | 2 | 17, 19 |
Insert Coin | 5 | 11, 25 | 6 | 7, 25 |
Hardware
So, from the above, you'll need 2 USB keyboards for the PC interface. You'll then need the actual arcade joysticks and controls. Below is the kit I found recently on eBay for around AUD$50. I'm sure you could get it cheaper; my purchase was on a very large impulse and I had a few regrets afterwards as there were better joysticks on offer for the same price.
The buttons themselves are exactly what you'd find in real arcade machines... the microswitches make their motion feel perfect as well.
So, with all the components, it's now time to get it connected together. Start by ripping open the keyboard...
Decoding a USB Keyboard
Keyboards are built on a matrix. Just like the LED project previously with the Arduino, each button on a keyboard is connected to one row and one column of the circuit board inside. The circuit board will scan each row and column hundreds of times a second to check which buttons are pressed and then report this back to the computer.
As you can see above, the controller inside the keyboard is not soldered to the matrix. This is great news as I was expecting to have had to solder to fiddly little wires instead of the nice connection pads that you can see.
Firstly I pulled out the multimeter and started decoding the keys I'd need to use. To do this I put one probe on the pad circle of the key and I then ran the other probe across the connection to see which wire it connected to... I then recorded all of my findings:
The data I gathered is in the table above. Each key has two pins and these map from left to right on the controller connection seen above. I have only decoded the keys that I need, but it's easy enough to work out the rest when you have an opened keyboard in front of you.
I then began to wire up the controllers. One the first attempt, I thought I would solder short wires to the controller and then use these for connection points. This worked OK until I was up to the final wires. It seems that constant moving around of the controller puts pressure on the soldered joints and I ripped many of the tracks off. I then had to get my tiny copper wire and re-solder the tracks as the pads were gone. This became quite tedious, but I learnt my lesson very quickly.
I got enough of the wires connected for the first joystick and then quickly connected it to test. I then managed to play a quick game of Bubble Bobble. Impressive! You can see below my initial prototype housing for the controls. The washing basket was the worst idea on earth... but it was a cheap mistake.
Building real housing
I ended up at Bunnings looking for ideas for a box to house the controls. There was nothing off-the-shelf, so I opted for enough wood to make a deep enough box for the controls. This was a pretty simple and ugly construction... but it did the job.
Finished products
After testing, I put backing panels on both of the controllers.
Each controller can only ever be used as Player 1 and Player 2 respectively as they are mapped to specific keys on the keyboard.
Of course, you could change the configuration of MAME, but that would be tedious... Although sometimes on games it'd be nice to be able to play as one of the other 2 players (3 or 4) ... but I'll create two more controllers for that.
Future plans
I want to build two more of these (actualy, I did, here's the link!)... 'The Simpsons' arcade and 'Teenage Mutant Ninja Turtles' require 4 players for the most amount of fun, and 'Rampage' needs all three creatures bashing up buildings.
Sending full bytes over .NET Serial Ports to the Arduino
Ok, I have just spent a good two nights of my life diagnosing why I could send all bytes up to value '127' and no higher. In hindsight, it all makes perfect sense and the documentation is clear, but when you've been taught to think in strings, you might hit this very quickly.
The Scenario
I have my MAX7219 + LedControl Library set up on my Arduino and all works fine. I use two functions to control it: setLed and setRow. setLed simply takes a boolean to determine if the LED you are pointing at is to be on or off, but setRow requires a byte. This is all fairly straight-forward as each 'row' in the LED matrix has 8 LEDs, and a byte has 8 bits. So, starting from the lowest significant bit, a value of b00000001 will turn on the first LED in a specified row. (i.e. setRow(DEVICE,ROW,BITS);).
All communications between my application and the Arduino had been based on strings and so I had previously been using one character (one byte) to set one LED. Due to this being a complete waste of bandwidth, I decided that each byte I sent through the channel should be a byte to control full row of LEDs. This meant that I could therefore no longer 'see' the output as a string (or ASCII), as the characters I would create from setting the bits may no longer be in ASCII range... this was no big deal, as I could just view the byte values and decode it all myself.
So, on the client end (C#.NET Application) I started encoding the bytes from bit values. This all worked until I tried to set the last bit...
byte b = 1 | (1 < < 7); //let's set the first and last LED. string buffer = (char)b + "\0"; serialPort.WriteLine(buffer);
Data Sent | LEDs lit | Correct? |
---|---|---|
b00000001 | 1st | OK |
b01010101 | 1st, 3rd, 5th, 7th | OK |
b10101010 | 1st, 2nd, 3rd, 4th, 5th, 6th | WRONG |
b10000001 | 1st, 2nd, 3rd, 4th, 5th, 6th | WRONG |
b01000000 | 7th | OK |
b10000000 | 1st, 2nd, 3rd, 4th, 5th, 6th | WRONG |
What the hell was going on? That 8th bit is fishy!
The Answer
So, after reading numerous blogs and not finding my answer, I went to the Arduino Forums and posted a topic asking for help. I was given advice to write a very simple test app to work out where the bytes were failing... but I never did get to write that app, instead I went to the MSDN site as soon as I saw that the Write() procedure could be overloaded.
And look what I found at the article on MSDN:
By default, SerialPort uses ASCIIEncoding to encode the characters. ASCIIEncoding encodes all characters greater than 127 as (char)63 or '?'. To support additional characters in that range, set Encoding to UTF8Encoding, UTF32Encoding, or UnicodeEncoding.
And guess what... ASCII Character ? is 63 in decimal and therefore b00111111 in binary!
So, whenever I was setting the 8th bit, the .NET Framework (in all its wisdom) would translate this to a question mark as it was not expecting to send an invalid ASCII character. Ladies and Gentlemen, ASCII is only 7 bits!
The work-around?
byte[] b = new byte[] { 1, 127, 128, 129, 255 }; //let's set the first bit, last bit, etc... serialPort.Write(b, 0, b.Length);
And then everything just worked. Do not send chars to your port if your receiver wants bytes.
Ugh… Taiwanese Components…
PLEASE be careful when you buy cheap and nasty electronic components from eBay... This is a public service announcement.
Check the photos below and tell me what's wrong:
Yes, that's right, the legs are different on both items (the Anode and Cathode are REVERSED)... they came from the same packet and I, prior to using macro on my camera, thought they were a lot more similar than they actually are. Either way, you have been warned.
This all came about whilst wiring up these sensors and receiving zero readings.... bastards....