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

Sliver X

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.

alwaysotg

@Sliver-X I just installed this and wanted to say Thank You!
I do have a question. You did have the safe shutdown script preinstalled on the image correct?
I just installed it today from your drop box link. I have the switch turned on under the battery, but it seems like its not doing the safe shutdown. Is there a way for me to verify it is? Also if its not working, can I just install the script from the retroflag gpi site? or do you have any recommendations ?

Sliver X

@alwaysotg

You're welcome, I'm glad others are finding it useful.

Safe Shutdown is installed, and tied to a shell script in /opt/Retroflag that is a minimal, stripped down version of a script written by crcerror:
https://github.com/crcerror/ES-generic-shutdown/blob/master/multi_switch.sh

It's silent VS the original, and also gracefully shuts down EmulationStation and any running emulators so you don't lose metadata/save data. You can tell it's working if, when you flip the power switch, there is about a 2 second delay before the unit turns off. If it's not working, shutdown is instantaneous or doesn't happen at all, depending on why it wouldn't be working.

Installing the original Retroflag script would revert it back to the original behavior of simply initiating a reboot when the power switch is thrown (It does this instead of an actual shutdown: Since the power switch is off rebooting has the same effect, though I'm not really sure why they chose to do it that way?).

If it isn't working, the only thing I can think of is the one time I corrupted the filesystem testing CPU overclocks and it stopped working. A reflash would fix that if it's the case.

stsp

Thank you for sharing your work on this! This has saved me a lot of time.