GPi Zero 2 v1.52 & GPi Zero v1.15(Retropie Images for Pi Zero/Zero2 + GPi Case 1 & GPi Case 2W)
-
I had this happen once when I was running an original Pi Zero and a much older version of Retropie: Turned out to be the pogo pins in the cartridge not making good contact. Reseating them resolved the issue, so that may be worth trying?
You may also want to try putting in Select/Start + left mode, the shutting down. If it still isn't working after powering it back on try Select/Start+up and do the same.
-
@sliver-x
Thanks for the quick response! Reseated the board a couple times but it didn't seem to correct the issue. I did Start+Left (select doesn't work on my GPi) and the light flashed purple after 8 seconds, restarted (safe shutdown mode), buttons still not responding. I also did Start+Up, purple light flashed, and restarted, same issue. After start up tried Start+Left, still no change. I also reimaged my SD card a few times just in case but still have the same problem. Fortunately, I'm able to SSH into it. Is there a script you would recommend trying? Thanks again for your help, much appreciated! -
I'm not sure what could be wrong: I've installed this on two units myself and the controls work on both...
If you have a bluetooth keyboard you could pair it via SSH and try to use it to navigate to the control config menu option in EmulationStation: That would at the very least show that the setup is detecting your controls.
Have you opened up the main chassis before? Is the ribbon cable that connects the two halves in ok?
-
@sliver-x
I cracked open the chassis and the ribbon cable looked fine. Detached and reattached them at both ends to be sure. I was able to pair a bluetooth keyboard that got me through the initial control setup. Is this is the setup you're referring to with "control config menu" (Start->Configure Input)? If so, the GPi controls still don't show up. If the control config menu is somewhere else, where would it be located? -
Yes, that's the menu.
Maybe try this?
sudo ~/RetroPie-Setup/retropie_setup.sh
Manage Packages -> Core Packages -> emulationstation -> Configuration or Configuration / Tools -> emulationstation and choose the option to Clear/Reset Emulation Station input configuration.
When you get back to the input config menu, it should say something like "One Gamepad Detected" Hold down a button until it loads the config wizard and hopefully it lets you set bindings on everything.
-
@sliver-x
Unfortunately, that didn't do the trick. I must have a bad unit.Even with RecalBox's new image specifically for the Zero2 and GPi case, the buttons will not work.
-
Sorry to hear that. You may want to try getting a replacement cartridge first rather than an entire unit (They run around $20 USD): There's a good chance it's something wrong with the pogo board or the usb cable that connects to the Pi Zero 2.
-
@sliver-x
Will do. Thanks again for your help. -
@sliver-x
Just got my replacement. Installed the same micro sd card, booted it up, held Start+Left until the purple light blinked and the controls worked! -
Awesome, I'm glad that was the issue.
-
@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!
-
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?
-
@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.
-
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.
-
-
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.
-
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.
-
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.
-
@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.
-
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)
-
@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.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.