@ase1981 If I understand correctly, this forum should help: GPi Zero 2 v1.52 & GPi Zero v1.15(Retropie Images for Pi Zero/Zero2 + GPi Case 1 & GPi Case 2W)

@raspberry79 is there a question here or just a continuation of your previous topic from https://retropie.org.uk/forum/topic/35170/ ?

I tried to reproduced the issue but it wasn't possible, I tested a h264 movie 1080p resolution in a RPi3b+ with RetroPie Buster.

Please add more info : https://retropie.org.uk/forum/topic/3/read-this-first
What resolution did you use? Do you have the official PSU? Do you have this issues with all media files?

Remove the .cfg file you're trying to edit.
If you have copied the correct BIOS files in-place, the configuration file will be re-created with the right paths to the BIOS file(s) on the emulator's first run.
I don't have access to atari800 right not to check its behavior, but I don't recall using the keyboard being this 'jumpy'. Just for good measure, run an update for RetroPie and the system to make sure you're on the lastest version.

@MortalWombat said in Tips on insuring that RetroPie will save battery games & Metadata changes?:

Is there anyway to search the results?? Hopefully by searching just "autosave" or "interval"??

You can use ctrl-w to search within the document while it's open in nano.

Thank you! Worked for me

Mame2010 appears to have savestate = false in their config, so maybe the 'cannot save' message is normal. Other MAME cores do have 'savestate = true' though (MAME2003, MAME2003+, MAME).

@abj it was pretty bad before turning off 4k. Now it's at least playable.

Please post the contents of the .cue file - you can open it as text, since it's just text. Did you also checked the BIOS files that @abj mentioned - are they present in the BIOS folder ?

@sleve_mcdichael I like the idea, for what I'm doing I think I want to kill any previously running processes vs letting them continue. Only the newest process will be the relevant process

I might make the script kill any previous processes
then wait
then either be killed by a newer process or update the marquee

I'll give this a try tonight and see how it works. I just home emulationstation doesn't hang waiting for sleep to finish.

process=$(pgrep -f $(basename $0)) for i in $process do if i!=$$ then sudo kill $i fi done sleep .5 ...do stuff

A standard keyboard is ok

Quasi88 (standalone or Libretro core) should be able to emulate it. Probably MAME also.

I've taken a look at this and it seems the issue is the Bluez updates due to CVE-2023-45866 (as I said initially).
This will likely affect any (old) gamepad which doesn't encrypt the comunication with the host. The workaround is suggested in the linked Ubuntu bug report:

Set ClassicBondedOnly=false in /etc/bluetooth/input.conf
Run sudo systemctl restart bluetooth or reboot

Possibly other gamepads affected - the Wii U Pro Controller (haven't tested it yet).

NB: this issue is not restricted to Raspberry Pi, it affects any platform where Bluez was patched for CVE-2023-45866.

@Robinson You don't need a bios for 2600, see : https://retropie.org.uk/docs/Atari-2600/

Apologies for bumping an old topic, but partial support for this has been added into Retroarch 1.17:-

https://www.libretro.com/index.php/retroarch-1-17-new-netplay-features/

This will only work with a handful of games that supported the GBA Wireless Adapter, so for example no Mario Kart Super Circuit.

However, apparently it works well with Mario Golf and Pokemon Emerald/Fire Red/Leaf Green (https://www.davidgf.net/2024/01/13/gba-wireless-adapter/)

@notthesame I can't believe that worked, you are a godsend. I'd also like to add a few details:

After pressing Start and Y, the LEDs start to rotate from left to right. After that, you hold pair for 2 seconds, the LEDs go off for a second, and then they start to rotate again.

At this point you need to go through the Bluetooth pairing process again (and if your controller is already paired, you should un-pair it before you re-pair it) but you do NOT need to set up the udev rule. All you need to do is reboot and configure the input like normal.

I think this should be added to the documentation.

@mitu Well ... looks like you are right. :D

Edit:
Fixed! ;)