GPi Zero 2 v1.52 & GPi Zero v1.15(Retropie Images for Pi Zero/Zero2 + GPi Case 1 & GPi Case 2W)

ParadoxGBB

@sliver-x Thanks for this --- I've been messing with mine and scripting a few things too. I'm trying to see how you scripted a samba toggle, lots to learn in here.

I'm sure you're already on this, but there's some good work coming down the pike for an OSK for configuring WiFi (https://github.com/RetroPie/RetroPie-Setup/pull/3431). For me getting it work even with your image is rather tough since none of my dongle keyboards appear to work with the back USB port. I usually now drop a wifikeyfile.txt in \boot via another pi but with your image it complains when setting locale when I do so that it "can't communicate with wpa_supplicant". Am I missing something? I tried toggling wifi off and on again and that didn't help.

One thing I'm curious if you hit in your testing --- when I installed the safe shutdown script a while ago I started having wifi issues in the middle of transferring files. When I hit this state and tried to reboot, it appeared that the dhcpcd service hung. Since I uninstalled the dependent packages I haven't hit that since, so I was going to do more testing on that this week to see if that caused it. It seems like an odd correlation if so.

Also, not a bit deal but it seems like the safe shutdown script is mapped to the top power switch when I thought the intent of the case (at least with the original zero board) was to map it to the back switch in the battery compartment. If so the GPIO mappings might be different for this board. The reason why I'm interested in this is because I'm thinking about trying to map a script from that back switch to toggle between HDMI and LCD mode.

Thanks again!

Sliver X

@paradoxgbb

I'll have to test the issue with wifikeyfile.txt: I've been using wpa_supplicant.conf under /boot during the entire process of building this, and that's been working as expected.

I ran into the same issues you're encountering with WiFi/SSH as well, which is why I changed the Systemd timeout to 10 seconds so it could just shut down cleanly. It seems to happen a lot less now that I've set up ZRAM swap, though? I would be extremely curious as to what your testing results in regarding this problem. What all packages did you remove to alleviate the problem?

Yes, an OSK for putting in a PSK would be phenomenal. I'll look into it later today.

I'm not sure about the safe shutdown switch? I always thought that you had to enable it with the switch under the battery door, but its actual execution was controlled by the power switch on the top of the unit?

ParadoxGBB

@sliver-x Thanks for the reply, it's cool when you bump into someone doing similar stuff you're doing.

Your approach seems different than mine and more elegant --- I have a script that swaps files into different profiles and then I reboot the unit to enact those changes. For example, I have a different theme and config.txt when in LCD mode, and I try to keep the Pi3 defaults for HDMI mode. Yesterday I configured toggling off the arcade bezels for MAME on LCD mode because the resolution isn't good for those and they overlap, but they're cool over HDMI (and consistent with my other Pis).

Some of the stuff you did here regarding battery optimization is interesting because I'm planning to run some timelapse tests on rechargeable AAs sometime before the holidays, comparing it with my original real Gameboy just to see what it can do and so I know when I'm out.

I'll get back to you regarding the wifi soon, I have a few other things I'm working through first. When you hit this state, was there anything you could do to get out of it other than reboot? Did your wifi toggle help? I was hitting this very frequently when I was initially setting up the device and this was a non-starter for me because I want to stream video through this thing over Wifi. For fun I also ran some tests and I could even get reasonable performance over steamlink to play a few titles like Limbo, which is pretty amazing. If I could show up someplace and play jackbox games at a party over the holidays that would be a pretty neat trick.

Regarding the back switch I haven't had time to get too deep into it yet but in theory they should all map to GPIO so should be queryable via the same mechanism. I'm not sure what purpose setting up a switch with a separate switch would serve either, and the back says "safe shutdown" and not "safe shutdown setup", but maybe I'm being too literal.

Sliver X

@paradoxgbb

Running two cores, with no Avahi/Samba/BT/WiFi at half brightness using Eneloop Pro AAs I was able to get around 6 and a half hours of runtime out of Super Metroid playing its demo loop (Using Snex9x2005 in Retroarch). I ran a small script that dumped Uptime to a file every 60 seconds, then left it on and went to work. When I got home I examined the log once I got it powered back on to see when it died.

I only ran into the WiFi issue when transferring gigs of ROMs. I've spent hours in terminal sessions via SSH and never had a hiccup. I would ultimately have to power cycle the unit to get WiFi back once this occurred, but the default Systemd timeout was really long and would often exceed it. Once I set up ZRAM and freed up as much RAM as I could it started acting much better, lasting longer when transferring or not losing connection at all, though I'm not sure why: RAM or swap usage isn't really under pressure during such a transfer according to htop... Maybe it had more to do with the adjustments I made to Systemd? For example, I've been uploading my N64 set to the device via GFTP-GTK for the past 25 minutes and it's still going fine.

For the wifikey issue, I just realized, I removed all locales but en-us and en-us UTF-8. That may be causing your issue?

edit Oh, and to address something you said earlier: I've had great success with a powered USB hub chained into a USB OTG adapter being plugged into the back port to get things like a wireless keyboard running. The trick seems to be removing the batteries and turning the power switch on before connecting it, but the gamepad doesn't work. A bluetooth gamepad being connected can mitigate this.

ParadoxGBB

@sliver-x

Was able to transfer your toggle scripts to my image and they work very nicely. Have you considered submitting a pull request? I really believe the project as a whole would benefit from this --- handhelds are getting more popular on this platform and the recent release of this board is accelerating that trend. They may not take them as-is (opting to integrate them, for example, into the existing wifi and bluetooth menus) but they are so useful and don't look like it would break the bank to maintain. I'm not a bash expert but I don't know yet the difference between the .rp menu items and simply sticking in the .sh bash scripts.

As for the Wifi I noticed the same thing when I hit it, when doing intense copying (for me, over samba from a windows box). I'm trying to better understand a lr-scummvm issue I'm hitting today but early next week I want to look closer at the shutdown script, the tweaks you integrated that you found, and see if those wifi issues come back.

I'm not sure about your image though, I set up the timezone locale and the codepages were set to the default English (GB) one, not US. I had changed them to US UTF8, but I still was getting the wpa error on the wlan setting. Something's screwy there or I'm doing something wrong.

I said this on another thread but yeah, it's finicky on what batteries it'll take, but the lower capacity enloops I had around worked. Your post about pros encouraged me to take the plunge and get some despite the priciness.

As for the USB port I'm hoping I'll never really have use for it so that's lower on the queue.

Sliver X

@paradoxgbb

I'm glad you've found some of my stuff useful: I'm not really a programmer (Aside from some 6502 and z80 assembly I did ages ago for some ROM hacks) but I script a lot for my day job and hobbies.

The Eneloop Pros are totally worth it: I ran probably my last power test today (Progear for CPS2 running its attract mode until death) and got 5h:54m, with the unit averaging a 92% CPU load during the entire run. Combined with the NiMH charging circuit I've soldered into the unit (Allows the DC jack to charge the batteries when plugged in) I'm totally fine that Retroflag went with AAs instead of an inbuilt Lithium pack, now.

I cannot for the life of me get the OSK you linked to work, either using Git's functions or by even manually copying in the changed files for it over a stock Retropie_Setup pull (Just crashes the WiFi applet). I guess I'll wait until it's committed to the main branch before giving it a go again.

Sliver X

@sliver-x

Rather than wait until/if I do another release, here's a simple save data manager script I finished last night:

https://drive.google.com/file/d/1t-L5e5KPa2W-4LpJE1nHr78PcE_wWiQO

It does recursive backups of all SRM/STATE* files in all ROM directories, can restore them and allows deletion of unwanted sets. Eventually I'll work out a way to save/restore from a remote location such as an SSH server but for now it's purely local: Archive sets are located under ~/Save_Backups (tar.gz files) and can be copied to another location for off-device storage if desired.

Please let me know if any bugs slipped through.

fluxrez

@sliver-x Hi! I have the same issue as the guy above. The D-Pad does not work when I run this image. I did try re-seating everything, but that did not work. Then I decided to try another OS. I installed Recallbox on a new SD card and that worked fine. Maybe there is a different hardware version? For now I will use Recallbox but I would love to use your image as I absolutely love the retro look of it. Cheers.

Sliver X

@fluxrez

I have two units: Beside the negative battery terminal on the circuit board is printed "V 11" and the combination to change Dpad modes is Start+Up and Start+Left. The image works on both, but I'm aware there is another revision of the board that uses Select+Up and Select+Up. Is that the combination on yours?
I also had this happen once during development when I pulled the SD card too fast after the initial partition resize and had corrupted the filesystem: Nothing I did would let the controls work until I reflashed and tried again.

(I may need to set it to prompt for the controller config at first boot like a fresh ES install would do: I predefined them for convenience, but if it's causing problems with the other variant of this device I'll change it)

nandorrelentless

@sliver-x I'm having an odd issue with NES gamelist data not populating. I have my gamelist.xml file and am adding it to:

/opt/retropie/configs/all/emulationstation/gamelists/nes

None of the information in the gamelist.xml file updates to match the roms I've added. I can access the roms no issue, but the only game that maintains its data is Blade Buster. I've attempted to remove it from the roms folder and rebooted, but it still does not work.

Any suggestions to prevent the need to scrape on the GPi case would be appreciated.

Sliver X

@nandorrelentless

I store my rom folders as "modules" with the gamelist.xml and a subdirectory called images to hold the snapshots in the ROM folder itself along with the games (I also don't use the Retropie scraper: I wrote scripts to convert all my Advanced Emulator Launcher metadata from my Kodi HTPC setup for my GPi Case). So in the case of Blade Buster, I put the gamelist that defines it in /home/pi/RetroPie/roms/nes

I'm suspecting having a gamelist.xml in the ROM folder takes precedence over one in /opt/retropie/configs/all/emulationstation/gamelists/? Try deleting /home/pi/RetroPie/roms/nes/gamelist.xml: I think that'll fix the issue.

If this causes some kind of conflict with the scraper I'll move it to /opt in the next release.

nandorrelentless

@sliver-x thanks. That indeed did the trick. Was following instructions for a script to export from LaunchBox and it said to place the gamelist.xml in /opt. Replaced the one in /roms and all is well.
Thanks for this image! Certainly saved me some time!

Sliver X

@nandorrelentless

You're welcome: I'm glad others are getting some use of it.

I've updated the image to v1.18: This should fix the issue you encountered among other things.

ParadoxGBB

@sliver-x A few updates from me:

The OSK just got merged yesterday into the master branch. You don't need a version bump to grab it, just update and you should be good to go. It's pretty spiffy and the only real minor complaint I have is that there's no CAPS. I can deal with that no problem compared to the hoops you needed to go through before.

As for SafeShutdown, I reinstalled the scripts and I'm happy to report that on my image I was able to copy almost 15GB of movies over WiFi at one shot, averaging about 1.5 Mbps, with no reboots required. I'm not sure what was going on before. To uninstall it before I removed the python3-gpiozero package referenced in the install script.

As for our discussion on GPIO, I wrote a basic py script (using https://tutorials-raspberrypi.com/raspberry-pi-gpio-explanation-for-beginners-programming-part-2/) to query each port status but it's too invasive and I'm not sure if that pin is queryable yet. The original scripts look at pins 26 and 27, however think one is the led and one is that actual switch, not the switch in the back. However, I kind of missed that that point of the safe shutdown switch in the back isn't just to install the script but to toggle between safe shutdown mode and regular hard shutdown mode (I know, I've been really slow on this...). If you switch it to off and switch off power, no safe shutdown. That means in therory you could keep it on in the back and if you wanted to hook it up to the switch you could turn it off and back on to get a desired effect, but I'm thinking at this point that outside of it being interesting it may not be as useful as I thought. Current python code I got in case you're interested:

import RPi.GPIO as GPIO
import time

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(True)

for i in range(26):
	if i == 0 or i == 1 or i == 2 or i == 4 or  or i==14 or i==17 or i==18 or i==19 or i==22:
		continue
	status = None
	#print(str(i))
	GPIO.setup(i, GPIO.IN)
	status = GPIO.input(i)
	print(str(i) + ' [' + str(status) + ']')

 GPIO.cleanup()

Finally, the RetroFlag site mentions that the USB port in the back is for firmware updates, presumably for the case hardware, but so far I really haven't confirmed that if you wanted to plug hardware that's picked up by the broader OS that it'd work. You said you did? It's acting as if it's completely partitioned off.

Finally, starting a few days ago I'm getting really annoying random latency in my SSH sessions --- anyone hit this? Anyone know if there's something I can check to see if I screwed something up?

Sliver X

@paradoxgbb

The OSK is really nice, thanks for letting me know about it. Now if I can figure out why putting ssh on the boot partition doesn't enable SSH after doing it once and why the sound "card" the GPi case emulates over the gpio pins vanishes after doing an OS update I think I'll be close to having this image completely to the point where I'm happy with it.

mitu

@sliver-x said in GPi Zero 2 v1.18 (Retroflag GPi Image for Pi Zero 2 W):

Now if I can figure out why putting ssh on the boot partition doesn't enable SSH after doing it once.

That is handled by the sshswitch service. If you disabled/removed the service, then SSH won't be enabled.

Sliver X

@mitu

Thank you, yeah, I didn't realize I'd disabled that near the beginning of working on this: Enabling it makes it work (So now I can strip the SSH host keys/etc out of the image before distributing it).

Also, excellent work on the OSK you made recently : It makes using a device with no keyboard infinitely nicer to deal with.

ParadoxGBB

Yes, thanks so much @mitu! I've been hoping for this one for a while.

@Sliver-X here has some great scripts that further help with toggling control of Bluetooth, Samba, Wifi, cores, and logging. I took the lead and stole them and placed them into the RetroPie-Setup folder directly and they are picked up nicely by the UI.

As for the updates as I'm sure you know it's just the dpi24 file that you have to noermally replace and it might be hard for setup scripts to understand that it's customized and it doesn't even know the user has a RetroFlag Gpi case. It's super annoying but I'm not sure what can be done to streamline.

mitu

@paradoxgbb said in GPi Zero 2 v1.18 (Retroflag GPi Image for Pi Zero 2 W):

As for the updates as I'm sure you know it's just the dpi24 file that you have to noermally replace and it might be hard for setup scripts to understand that it's customized and it doesn't even know the user has a RetroFlag Gpi case. It's super annoying but I'm not sure what can be done to streamline.

The issue - I think - is that the .dtbo file used is using a filename already shipped with the Raspberry Pi OS kernel, so it's normal that's overwritten on upgrade. Rename the .dtbo file and update the config.txt accordingly, IF the overlays are not compatible.

Sliver X

<edit>
This post had dead links to obsolete files and has been removed.