Hi, let me explain the idea before tracking down the circuit and a decent documentation.

First of all take in account that there is an already working software with a set of single-characters commands with the relative parser to connect the ChipKit PI by one side and the Raspberry PI to the other. It works fine and is modular and I can customise it in very few time. So all the input can already send to the PI just the corresponding "command" character. Not only but the parser in this case is monodirectional so the Raspberry PI component side can be simplified.

As the console uses almost vintage joysticks and buttons, I suppose that they has also the need to be managed properly to reach the switching quality needed by the micro controller hardware at the date. To simplify the software on the micro we can send already "cleaned" switch signals with a debouncing bank (also the cost is really very few $) with a circuit like the example image below, done for 5 switches (can be expanded as well)

Then we should consider that we are working with 30 input switches and the switch detection time is strategic in most of the arcade games. So all the 30 inputs can be read sufficiently fast by a shift-in register (four daisy chained registers can manage up to 32 inputs) so the ChipKit PI as a matter of fact should continuously monitor the four-bytes input status, check if some bit has changed and with some fast AND operations will send the corresponding character to the Raspberry PI. As the communication / parsing protocol on the Raspberry PI receives a CR as the end command it is also possible to send multiple characters if needed to manage simultaneous button press if needed. This is a parameter that can be set at software level.

As the Raspberry PI software is developed in C++ it is not difficult to integrate it in Python, as a command line parameter or in any other way (including a background process as it actually works).

Enrico

I haven't played these games much in the past, but I'm having trouble finding the 12 buttons on the attached images in the linked post. It looks like the console has two joysticks (4 switches each) and eight buttons (4 each). Are you planning to add more?

Ah yes, sorry -- I wasn't too clear there. Yeah, it's going to have a new control board, with more buttons on it   And some of the buttons might be on the cab itself, too.

Ahh ok.

Another approach could be to emulate USB keyboard presses for each button using a commercially available keyboard emulator, or better still an Arduino/Teensy programmed up with the keyboard libraries.

Maybe an alternative. But the bare buttons connected to an input are not sufficient in my opinion should be debounced. Then, there are 30 inputs, and I vote again Arduino. Better the PIC 80 MHz More reliable.

Enrico

Yeah, either a hardware debounce could be built. It might also be possible to employ some software debounce.

Software debounce is almost impossible for two reasons. The first is that you have 30 inputs so you should use a shift-in register and the second is that also when possible, this introduce a huge complexity in the code (AFAIK) that is easier to use something like the schematics I posted in above.

Enrico

Given that the Raspberry Pi 2 has 26 inputs (if I remember correctly), how do you think it'd manage if we just took the buttons direct to the GPIO? If we could run some kind of "GPIO-to-keyboard-presses" script, each button comes into the emulator as a key press. Is that likely to suffer from button bounce? If it is, would something as simple as a pF cap across the micro-switch terminals take care of that?

Also, I had another thought in case we need additional buttons. If it worked as above, with buttons going direct to GPIO, could a keyboard script recognise two simultaneous GPIO pins as a different key stroke?

For example, let's say that PLAYER ONE LEFT goes to GPIO pin 14, and PLAYER ONE RIGHT goes to GPIO pin 15. These two will never be physically used together, because of the joystick position. So if GPIO pins 14 and 15 are simultaneously grounded, could that be recognised as a whole different keyboard press, thereby effectively increasing our range of inputs without additional hardware?

Spanner Spencer wrote:

 

For example, let's say that PLAYER ONE LEFT goes to GPIO pin 14, and PLAYER ONE RIGHT goes to GPIO pin 15. These two will never be physically used together, because of the joystick position. So if GPIO pins 14 and 15 are simultaneously grounded, could that be recognised as a whole different keyboard press, thereby effectively increasing our range of inputs without additional hardware?

That might work, until the player tries pressing the up or down buttons on the joystick while pressing the "simultaneous" button. Most arcade buttons have a single SPCO microswitch, so simultaneously grounding on one button press may be complex to achieve.

Ah, yeah -- I think I see what you mean. PLAYER ONE LEFT might not register while the "simultaneous" button is being pressed, because that GPIO pin is already grounded? So you won't be able to move left or right while using that joint, "simultaneous" button.

Good catch, man