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

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

Why don't you just use one of those programmable button to Keyboard HID device boards that everyone else uses !

Stick it in the USB and you are away with out having to write custom support for the device to talk to the likes of Mame etc.

There's a lot to be said for making it easy for ourselves with one of those

But I thought it'd be good to explore as many options as possible; particularly if any of those options reduced the number of add-on or extras the project would need.

I've used the type of adapter you're talking about though, and they are smooth and simple.

Indeed it would be nice to use the GPIO directly but I think you may have problems if the cable length is significant maybe an IO expander like the MCPxxxx devices already mentioned would be good then have an I2C +interrupt say to  service the key press. you would also need to create some bodge ware to turn that GPIO button press to the corresponding keyboard events so that the non GPIO aware emulators can interface to it.

All the methods have some compromises, so really depends on requirements.

The USB k/b method is excellent, but suffers from N-key issue for an off-the-shelf part, unless you write your own code to support this, using any microcontroller with USB capability.

But is very excellent, since no need to write a driver for the RPI. And the number of keys simultaneously detected may not matter too much if they are games designed for a computer rather than a console.

The I2C method is great too, but requires a driver to simulate keypresses - maybe this already exists, I don't know. I did find source code in a google search, but for an old TI expander.

The GPIO method also needs a driver, but one does exist (the Adafruit one), although it would need modifications to support the 30 or so keys.

Maybe all-round, the USB k/b method is quickest and may be good enough.

The Ipac thing is what I was thinking of and since it has dedicated pins you don't have those "N" key roll over problems

http://www.ultimarc.com/ipac1.html

Ah yes, I've used an I-Pac before -- that was with a PC, and it was pretty good. Very simple, and it worked as advertised. I can only assume that it'd work just as well with an RPi. No reason to assume otherwise, anyway.

Very cool : ) That looks very good, and seems to have a ton of features for games.

Maybe (say) a FRDM board could be used to replicate some version of this, would be an nice project to build a key interface to USB for gaming uses. Maybe something like the K22F, which looks like it has enough I/O for it.

Anything with enough I/O and can implement a USB Keyboard HID device would be good I think Shabaz

If you are interested in connecting original controllers to the Pi like arcade controllers or other original controllers like SNES or Genesis/Megadrive controllers, you might be interested in the ControlBlock. It was designed specifically for that use case: https://blog.petrockblock.com/controlblock/ It even provides a power switch functionality.