Design dilemma for retro arcade machine

Chickenman

Hi everyone,

Hopefully this is in the right place. I'm new to Raspberry Pi and just got a hold of a RPi 3B. I have some old bits and pieces and wanted to build an old style arcade so my daughters (2 bio and 1 step), step son and I could play some games together. I have an old screen worked out, waiting on a power supply for the Pi and some controllers and misc stuff before serious play time begins.

My design dilemma comes in the form of input into RetroPi so I'll make an attempt at explaining what I'm trying to achieve and the design decision I have to make.

Background
I'll be using as classical controls as possible... going for a 3 or 4 stick, 6 fire button design with no specialty controls like trackballs etc. I wanted 3 or 4 sticks so we can all play TMNT, Gauntlet and Knights of the Round. This machine will be an upright classic arcade machine running only MAME games.

Each stick requires 4 buttons (up, down, left right) for a potential total button tally of 40 buttons (4 stick and 6 fire buttons per player) as well as system buttons (I estimate 9 system buttons: 2 insert coins, 4 player starts and a return to menu, please correct me if I am wrong here).

Design option 1
I have developed a sketch on the Arduino (easily portable) which has the ability to quickly read the state of multiple buttons:

Maximum of 72 buttons on the UNO (though for the UNO I would organise it to have at most 66 for logical layout of circuitry)
Maximum of 90 buttons on the Nano (logical layout turns this into 88 buttons)
Maximum of 1089 buttons on the Mega (but I would imagine it would be very latent if all buttons are used and this is way, way overkill)

The state of the buttons are sent to the serial port (USB) of the Arduino continuously (which can be changed to an on request thing/keycode delivery) as a series of 16 bit coded binary numbers with each bit set if the button is up and reset if the button is down. E.g. 0111111111111010 means that the 1st, 3rd and last buttons are pressed simultaneously.

Inexpensive circuitry is required to prevent ghosting/protect the Arduino in the form of a hand full of diodes (5 for a project like this) but the diodes do not effect performance.

Going this rout would require some sort of driver integrated into RetroPi which could read the USB stream (send request/process response) from the Arduino and inject input commands into the emulator. A potential disadvantage is that if the keycode option is taken, I believe a maximum of 6 keycodes can be sent at once which could break the system.

Design option 2
The next option would require the use of the RPi GPIO port utilising a similar circuit and program to the Arduino one outlined above. This approach would allow the use of 169 simultaneous buttons (more than enough). The big advantage of this rout is that the RPi would handle all the controls "natively" without the need for extra bits and the RPi is a lot quicker than any Arduino. Disadvantage of this rout is that I am unsure if the required voltage would be present to detect a button press given the forward bias of 0.7 V of the 1n914/1n4148 diodes I would use (I could switch to schottky diodes for their low forward voltage, but they have higher reverse current) as the high signal is only 3.3 V, not much wriggle room there.

I call on those who have been playing with the RPi and RetroPi longer than I have to assist with this dilemma. You can assume that I am very familiar with programming, micro-controllers, electronics, networking, operating systems etc... just not RPi and RetroPi. Is it easier to write a driver/module for reading from the Arduino or from the GPIO? Is there already a suitable solution for this design decision that I haven't considered (I reject the GPIO with the NES controller etc solution as I'm going authentic, keyboard hack is also rejected due to ghosting issues)? Is there anything else I need to be considering?

Thanks for reading. Responses appreciated.

ruckage

@chickenman

Why not just use a ready made solution such as the i-pac: https://www.ultimarc.com/ipac1.html

There are several versions to suit most needs and it doesn't have any ghosting.

dankcushions

@chickenman said in Design dilemma for retro arcade machine:

Each stick requires 4 buttons (up, down, left right) for a potential total button tally of 40 buttons (4 stick and 6 fire buttons per player) as well as system buttons (I estimate 9 system buttons: 2 insert coins, 4 player starts and a return to menu, please correct me if I am wrong here).

some games may need insert coins per player. you should check pictures of cabinets of the 3/4 player games you want to play and see how many they have.

plus of course, if you play any console games the 'insert coin' button is by default also the 'select' button, which is used in SNES, PSX, etc.

you may be able to get around both these issues via clever binding (eg, making player 2's insert coin bound to player 2's insert coin AND player 3 and 4's insert coin)... not sure.

Chickenman

@ruckage said in Design dilemma for retro arcade machine:

@chickenman

Why not just use a ready made solution such as the i-pac: https://www.ultimarc.com/ipac1.html

There are several versions to suit most needs and it doesn't have any ghosting.

Okay, this thing looks like exactly what I'm looking for! Thank you so much

Chickenman

@dankcushions said in Design dilemma for retro arcade machine:

plus of course, if you play any console games the 'insert coin' button is by default also the 'select' button, which is used in SNES, PSX, etc.

No plans to play any console games. I was always a C64/Amiga fan, but I emulate these on my PC 'cause it's a more suitable environment than a arcade machine. The one game I wouldn't mind from a console would be Alex the Kid from the Master System (I believe).

Thanks for your input