Pi4 Retrofit into the 4-player Cocktail Cabinet

[caver01]

Next comes my GPIO setup and this is a current area of work.

Mausberry
The first part of this is the Mausberry. This circuit, in conjunction with script(s) running on the Pi enables soft shutdown through a momentary buttonpress. It also enables startup with the same button. Previously, I had this working by using a combination of @cyperghost’s multiswitch script, as well as @meleu’s killes.service—both of which are installed again and appear to be working OK, though I have not looked at any recent updates I might need to make since I had them working a couple years ago. Both services are being called by an idling python script I wrote which watches GPIO pins as triggers. For some reason, I was hell-bent on solving this using Python and “edge” detection rather than just a BASH script. It works.

[caver01]

Volume via dedicated buttons via GPIO
Having solved the soft shutdown using Python, I incorporated similar edge detection on GPIO pins triggered by dedicated Volume UP/DOWN buttons on my panel. This is working, but it brings me to my first question for anyone reading along:

Why are my volume commands not working?

Here are the details:

On a booted system, I can control the volume of the analog output jack easily using these commands at the command line:

amixer -q -M sset Headphone 2dB+
amixer -q -M sset Headphone 2dB-

This works great from the command prompt for volume up or down respectively. It also works fine if remote in via SSH and do it when audio is playing. Previously, I had to use “PCM” in place of Headphone, but this is basically the same idea. However, if I try do do this from my python script, it does not work. It tells me it cannot find the simple controller Headphone,0

My switch monitoring python script is started via rc.local, and the commands get issues using:

os.system('/usr/bin/amixer -q -M sset Headphone 2dB+')

And just for reference, the buttons are working on the panel. GPIO triggers are getting picked up nicely, but this volume command only works if typed in directly.

So, why does this command work fine via SSH or when I back out of ES, but it simultaneously fails when issued from the idling python script? Does anyone know? This was working before Buster.

[caver01]

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

So, why does this command work fine via SSH or when I back out of ES, but it simultaneously fails when issued from the idling python script?

I might have found my own answer with the right google search. I think all I need to do is use quotation marks in a better way like this:

os.system("/usr/bin/amixer -q -M sset 'Headphone' 2dB+")

Going to try that now.

[caver01]

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

@caver01 I believe you are going to run into problems rotating the screen. The Pi4 doesn't handle rotation the same way as Pi3 and has some limitations. I kept a Pi3 in my vertical cabinet for this reason.

Here is my cmdline.txt so far:

console=serial0,115200 console=tty1 root=PARTUUID=28482aa7-02 rootfstype=ext4 fsck.repair=yes rootwait loglevel=3 consoleblank=0 plymouth.enable=0 video=HDMI-A-1:1280x1024M@60,rotate=180

That video= portion was the bit that adds the rotation. It does not get picked up until partway through the boot process, so I will need to setup an upside-down splashscreen, but it works with ES, lr-mame, Hypseus and others. I will change it to 90 and see what happens. . .

[caver01]

This post is deleted!

[caver01]

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

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

So, why does this command work fine via SSH or when I back out of ES, but it simultaneously fails when issued from the idling python script?

I might have found my own answer with the right google search. I think all I need to do is use quotation marks in a better way like this:

os.system("/usr/bin/amixer -q -M sset 'Headphone' 2dB+")

Going to try that now.

That did not work at all. Same errors, like the system has no idea what I am trying to do via python. Silly, considering it works fine for the shutdown routine.

[caver01]

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

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

@caver01 I believe you are going to run into problems rotating the screen. The Pi4 doesn't handle rotation the same way as Pi3 and has some limitations. I kept a Pi3 in my vertical cabinet for this reason.

@Thorr69 I tried my setup with 90 rotation in the command above instead of 180. While ES did not change, the console is definitely flipped, so things like Runcommand screens and the CLI are definitely rotated. Of course, emulation rotation is a mixed bag for my setup because I have configs designed to rotate into player 3/4 on the vertical ends already, or NOT rotate when the game is a side-by-side coop. Still, it seems maybe a little promising for you maybe?

[Thorr69]

@caver01 If I am forced out of my Pi3 then it will definitely be helpful. I don't have any need for more computing power in that setup, so it's no problem to stay at Pi3 for as long as possible. I would be curious to see if you run into performance issues with ES, though. That's been the gateway that has kept me from committing to Pi4. It probably won't be an issue if your theme is basic. But if your theme is taxing then the rotation may affect the performance thresholds. Hopefully you don't encounter any issues.

[mitu]

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

This works great from the command prompt for volume up or down respectively. It also works fine if remote in via SSH and do it when audio is playing. Previously, I had to use “PCM” in place of Headphone, but this is basically the same idea. However, if I try do do this from my python script, it does not work. It tells me it cannot find the simple controller Headphone,0

My guess is because your default audio card is set to Heaphones for the pi user, whereas your Python script is run as root and the default audio card is not Headphones. Try copying the /home/pi/.asoundrc to /root and see if amixer works from the python script.

[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.