Pi4 Retrofit into the 4-player Cocktail Cabinet

[caver01]

Hi everyone! It has been at least a couple of years (years?!?!) since I was very active on this forum, but I have never lost the passion for sharing, helping with documentation, or even seeking the help of anyone willing to assist. As the title of this post suggests, I started an uprgrade project with my main build project: https://retropie.org.uk/forum/topic/1904/roadcase-somewhat-portable-arcade

If you have not had the chance to review the link above this was my original post that chronicled the build of my roadcase-style 4-player arcade cabinet which was based on a Pi3, then a 3b+ or whatever the last one was before the Pi4 (which never owned until now). Last week, I opened up the cabinet and put in a Pi4 that I traded for a Macintosh SE.

From the first boot, I started running into challenges. Some are bigger than others, and a few had me contemplating switching back to the Pi3, but I think I am all-in at this point, so I thought I would document my progress and ask for help along the way.

<edit> I forgot to mention a standard prerequisite for anyone curious enough to offer help:
Pi4, 4GB (I think)
Fresh install using official RetroPie 4.8 image
Interface is all pushbuttons and joysticks via OLD IPAC4 keyboard interface, (USB)
Ultimarc Trackball (USB)
Two Spinners (TurboTwist2, USB)
Sony 19” LCD 1280x1024 via HDMI->DVI
temporary keyboard (USB)
Mausberry power circuit with transistor for shutdown
powered speakers on analog jack

[caver01]

So, right off the bat here are some challenges I ran into:

• USB-C power
• Mini (micro?) HDMI
• Heat Sinks
• Video upside-down
• No audio
• Mausberry circuit to configure (GPIO, soft shutdown)
• GPIO - dedicated volume buttons to configure

USB-C
Starting with an easy one, USB-C is getting handled using a micro-to-C plug adapter. This is working, but somewhat precariously mounted, as I also have the Mausberry circuit to contend with—more on that later.

HDMI cable
Fortunately, my friend gave me the appropriate HDMI cable, so I am good there. I have an HDMI- DVI adapter on my display, so we are good to go now.

Heat Sinks
Not a problem really, but the Pi4 came to me in a FLIRC case which is nice, but I need easier access to the GPIO and my mounting area is setup for PCB screw holes not an encased Pi. Not a big deal—I just added some sinks. Hope they help.

No Audio
Fixed by setting in Raspi-Config. I am using the analog jack for my speakers. No big deal.

More to come later. . .

[Thorr69]

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

[caver01]

Ok, moving right along. . .
Video upside-down
This is perhaps one of the stranger aspects of my build. Because my cabinet is a cocktail-style design, the screen sits flat like a tabletop. That puts the typical viewing angle at odds with the player 1 and 2 positions along the horizontal edge. It may not be obvious at first, but if you walk up to almost any 4:3 or 5:4 aspect ratio LCD screen from the past (they are almost all vintage displays at this point) you will find that seated at a desk is no problem. You can view the screen straight-on or from above, but not from below! The contrast of LCDs of this era is built in a way that even the best ones are not viewable when put into the cocktail cabinet—UNLESS you rotate them upside-down. In this orientation, they are fine!

SO, in the past, I had simply used the dislplay_rotate = 2. However, with the Buster image that does not work with the updated video driver. I had to add a special parameter to the kernel command in cmdline.txt.

Having solved that, it still boots upside down, but re-orieints before ES launches. It looks like RetroArch emulators respect this orientation, but Daphne does not! I wonder about other emulators as well.

My solution. . . Start using Hypseus instead of Daphne, and focus on the fact that this is an arcade setup. I won’t be worrying too much about other emulators as long as I can get what I need out of lr-MAME variants.

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