Pi4 Retrofit into the 4-player Cocktail Cabinet

caver01

@mitu OMG I think you just saved me a big headache! THANK YOU!

I have not tried this yet but I will in the morning. For the life of me I could not figure out why, but amixer in Python via rc.local has HDMI as the simple controller whereas I can send commands in a bash shell to change Headphone all day long. The pi vs. root user makes sense. Wow.

mitu

@caver01 You could also try running the script out of autostart.sh instead of /etc/rc.local, assuming the script has enough permissions to do stuff as the pi user.

Lolonois

@caver01 @Thorr69 if you need the display_rotate switch on an Rpi4 you can revert to an 4.19.118 (or .97) kernel and accompanied firmware.

caver01

@mitu I tried both ideas— launching my switch.py script after copying the .asoundrc file to /root and that worked. I also tried using autostart.sh which also worked. For a few minutes I thought it was going to fail but realized I had not capitalized “Headphone” in the process of re-instating my original amixer command. (this was NOT the issue all along though!). so THANKS AGAIN for this execution user insight.

Might be interesting to note that it was failing also when I commented out the script at startup and launched it manually (exiting ES, launching my script at the command prompt, and trying it). That makes me think it is succeeding both ways now because of the .asoundrc file, and that for whatever reason, Python alway uses the root sound config.

I left it running out of rc.local, as I seem to remember an attempt to avoid using autostart.sh for soft shutdown in the past because it was thought that a future update might overwrite this script each time. Not sure if that is valid, but glad to be past this!

caver01

@Lolonois said in Pi4 Retrofit into the 4-player Cocktail Cabinet:

@caver01 @Thorr69 if you need the display_rotate switch on an Rpi4 you can revert to an 4.19.118 (or .97) kernel and accompanied firmware.

I am OK for now—until I decide I need an arcade emu that does not respect the 180 rotation I have working at this point.

One thing I did try though based on some initial notes from the pi foundation forums was disabling the new video drivers in config.txt. Doing so apparently reverts to the old and the display_rotate command works again. However, doing this, ES failed to launch. I suspect this image now has some built-in dependencies on the updated video setup in Buster for the Pi4.

mitu

@caver01 said in Pi4 Retrofit into the 4-player Cocktail Cabinet:

I suspect this image now has some built-in dependencies on the updated video setup in Buster for the Pi4.

Not only that, but there are no accelerated GPU drivers when disabling the (F)KMS overlay - the Pi4 does not have the same GPU drivers as previous models.

EDIT:

it was thought that a future update might overwrite this script each time. Not sure if that is valid, but glad to be past this!

autostart.sh is not overwritten on updates, it's considered a user config script so it should be safe to add your own commands to it.

caver01

autostart.sh is not overwritten on updates, it's considered a user config script so it should be safe to add your own commands to it.

Ohh that’s a good bit to remember.

caver01

Progress Update:

Emulator Testing mouse index and keymapping
I have been making my way through my “favorites” Arcade titles on the Pi4 rebuild. Everything is working great. Some games that ran slower on the Pi3 are now running at optimal speed, especially with the z-fast or Pi-CRT shaders which I really like. This was the whole point of updating to the Pi4, so I am pleased with performance.

Things to note include a renewed emphasis on lr-mame2003-plus for vector, and setting the correct mouse index for my cabinet, which has both a trackball AND two spinners. Depending on the game, getting these working just right per title is tedious given that I used to run vector games and games with multiple analog controls mostly through AdvanceMAME under the Pi3. I don’t see a need for that in most cases anymore, but that means I have to tweak the .cfg files per ROM so that I ensure any deviations from the default config are applied. Most notably, I am talking about the removal of scanlines for vector games. I don’t like the look of this shader for monochromatic vectors, or games that included gel/color overlays. For true multi-color vectors, original hardware did have a shadow mask which I could approximate nicely with advmame in the past—but here, the tradeoff is worth the performance and consistent configuration using lr-mame2003-plus.

caver01

In addition to ensuring the vector games look good again, and that I can take advantage of Cocktail mode whenever appropriate for vertical games, there are a few key mapping changes that I sometimes need to apply and I typically just handle this within the MAME menu. One interesting example is Gauntlet and Gauntlet II.

For the first time since I built my cabinet, I noticed something about these games that I hadn’t in the past—the Gauntlet titles’ audio is in stereo and coin drops are localized to the player position!

I recognize that my cabinet build and the 4-player control panel is unique—I have only ever seen a handful of cabinet builders taking on a 4-player cocktail style design. The benefit for me with this design is the ability to play side-by-side games (fighters etc.) along the horizontal side, and for old-school verticals to have players seated across from one another on the vertical ends (Cocktail mode). However, another huge plus is support for 3 and 4 player games. Titles like X-men, Simpsons, or even sports games like Stone Ball—and of course, Gauntlet, are really fun with 4 player action.

Regarding Gauntlet, getting the right players mapped to each position is key if you want to line up the audio. I only just realized this yesterday, so I went through the confusing challenge of re-mapping the controls to each position to get this working. To understand the results, it helps to show a visual of how my panel is arranged:


         +—————————+
         |         |
Player 3 | display | Player 4
         +—————————+
     Player 1   Player 2

So, this is how the controls are setup, and these player positions correspond to the switch inputs on my IPAC-4. For vertical games, Players 3 and 4 remap to P1 and P2 respectively.

But for Gauntlet, if you just map them 1-1, 2-2, etc, sure, you get 4 players and it works fine, but when you drop a coin in one position, the sound of that coin going in is in the wrong, stereo location, if that makes sense.

I don’t know who else this will help, but if you have your physical controls setup like I do above, here are the mappings in MAME that I came up with:

The format is Game/Mame Player shown ==> Control Panel Player

P1 ==> P2
P2 ==> P4
P3 ==> P1
P4 ==> P3

Another point of reference is that the coin button in MAME for P3 should be “5” and P3 Start is “1” if that makes sense.

Anyway, for the first time in more than a decade, my 4-player build as the “correct” positions (from an aural perspective) for a 4-player Gauntlet (II) game! Yay!

caver01

Update: After a pause to address some other stuff around the house I was finally able to rebuilt some of the internals of the Roadcase Cocktail Cabinet. The most recent work items included:

Remove USB Hub, replaced by. . .
Mount Meanwell 5v PSU
Reroute all USB connections (make longer USB cables) for arcade controls direct to Pi4.
Rewire audio and LEDs directly to PSU (instead of USB hub) for power
Rewire the mains AC to incorporate a split—Power the Pi transformer and a GPIO-triggered relay
Mount and wire the relay in a project box to power the display and PSU (which in turn powers the audio and the LEDs.
Remount audio amp, reroute speaker wires.
Update my Python script to trigger the relay on another GPIO pin.

It was a lot, but I had to keep it all straight and do everything at once. Before this step, I had a USB hub tying the spinners and trackball controls to the Pi, but also providing power. This was not necessary with a small and cheap PSU. It cleared up some of the bulky power transformers and removed some hardware, but replaced it with other stuff. In the end, this is a bit more complex, but the controls are now plugged in directly to the Pi and I have a relay turning on and off the display.