EDIT: i maybe didn't test enough -- the "remaining values are filled" in the .conf, only when run the +Start Amiberry.sh. When launch by one of the .lha roms instead, no values are filled, but the game still seem to work. They load and play anyway, did not test saving. But it's late and I've shut down for the night. Will test saving tomorrow.

Yes, saving works:

pi@retropie:/opt/retropie/configs/amiga/amiberry $ cat conf/amiberry.conf rom_path=/home/pi/RetroPie/BIOS/amiga floppy_path=/home/pi/RetroPie/roms/amiga harddrive_path=/home/pi/RetroPie/roms/amiga cdrom_path=/home/pi/RetroPie/roms/amiga lha_path=/home/pi/RetroPie/roms/amiga pi@retropie:/opt/retropie/configs/amiga/amiberry $ ls -l whdboot/save-data/Savegames/ItCameFromTheDesert/ total 16 -rwxr----- 1 pi pi 12444 Dec 20 11:36 ICFTD pi@retropie:/opt/retropie/configs/amiga/amiberry $ file whdboot/save-data/Savegames/ItCameFromTheDesert/ICFTD whdboot/save-data/Savegames/ItCameFromTheDesert/ICFTD: data

...save file exist, and I can quit and restart amiberry, then re-load the save in-game.

It's the same with either github/retropie version binary: no values are written (and file NOT created) when loading from .lha rom, saves still work at default location. Values are written (and file is created, with github version) when launch from +Start Amiberry.sh.

Edit: Launch from .lha rom, then open amiberry config and change eg. Rom path: all values are written to file (for both RP version with minimal conf, or github version with no conf.) But, if open config then quit with no change == no write values.

@akamming

These development images are automatically built and have not been tested. I have tried these images to experiment with a few things, and they were working okay, but there are no guarantees. Of course, I don't recommend using them as a stable system. Additionally, they are missing some features for now, like the splash screen

For Donations : https://retropie.org.uk/donate/

https://www.raspberrypi.com/news/bookworm-the-new-version-of-raspberry-pi-os/

Bookworm PiOS came out in October

@mitu Thanks, and sorry. Will try to find a guide for this then.

Everything is working fine again, i believe that my internet connection had some issue for a period time.

No idea, since I'm not familiar with the installer/script you're using.

for the record, mini-usb cable was defective.

Before I found the cable is a problem I was trying to solve that by copying the BT pairing data from /var/lib/bluetooth/* from my functional Retropie installation @ RPI3, but it seems those files are not enough.

Upgrading the OS is not supported by Raspbian nor RetroPie. You probably have found some instructions on how to upgrade using apt and updating its configuration files in /etc/apt, but it's not a recommended process, especially for a beginner.

If you wish to use an up-to-date/current version, use the image from http://retropie.org.uk/download. We don't support 3rd party image, as outlined in https://retropie.org.uk/forum/topic/3/read-this-first.

@viragored said in USB Audio almost working – what am I missing?:

The pop-up window box still reports "On-board audio disabled etc..." but basically it's all working :-)

That's ok, the Audio menu is meant to configure only the on-board audio, hence the message. External (USB/GPIO) sound cards are not supported.

Ok, so having spent quite a bit of time on this, I would have to downgrade my assessment to semi-successful - ha! I ended up having to install alot of emulators that I thought would still be on there as they were on my old build, and nearly all the other emulators had binary updates for me to run.

My RetroPie build is very basic really, with the only tweaks being those detailed in the official docs, so looking back I think if I was to do this process again, I would just start completely clean and go through each system one by one to check all is working correctly and updating/tweaking as appropriate. At least then I would know what needed to be done, rather than finding some things had copied over and other bits hadn't. This is most definitely due to errors on my part I'm sure.

On the plus side, on my 4.4 build my Sega CD and ZX Spectrum games wouldn't work (Sega CD would jump back to ES, and ZX Spectrum would crash the Pi) but now they do, so not sure what happened there but it's all good now - ha!

@masinad said in 8bitdo bluetooth controller and ROMs slowly loading:

Or where to look for information?

Seems like this issue. Try pairing the controller in Switch/Android mode instead of Xinput mode.

@posti85
the workaround is to check you gcc version on your setup for example mine is 9.3
in CLi type
gcc --version

then in the scriptmodule as @mitu advised initially find the 2 entries pointing gcc-6 lines 20 and 32 (im having 4.7.2 rpie setup script) and in my case i added gcc-9 fo example
save, start or restart rpi setup and should compile ok
BUT again as @mitu
i d recommend lr-mgba which is better for gba

Got it all sorted out.
Fruitbox running smoothly on a Jessie-based RetroPie image, straight from the EmulationStation main menu.
And I wrote a how-to, so you can too.
https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=188723&start=1594
Thanks much for the input @zerojay , it got me pointed in the right direction!

@mitu said in Trouble with RetroPie after updating from Stretch to Buster:

@keks24 said in Trouble with RetroPie after updating from Stretch to Buster:

Could you elaborate this and provide some references, please?

I think every new Raspberry Pi OS (was Raspbian once) mentions this in their release notes. For instance, for the Buster release:

We do not recommend upgrading an existing Stretch (or earlier) system to Buster – we can’t know what changes everyone has made to their system, and so have no idea what may break when you move to Buster. However, we have tested the following procedure for upgrading, and it works on a clean version of the last Stretch image we released. That does not guarantee it will work on your system, and we cannot provide support (or be held responsible) for any problems that arise if you try it.

Ah, thank you for the link!

In my opinion, they are making it a little bit easy on themselves here, but I guess, that they do not want to let the (normal) user go through the entire partitioning resizing process of /boot/ here.

They also increased the partition of their official images, due to the large kernel files of Debian Buster:

$ fdisk --list * | grep "Device\|img1" | column -t Device Boot Start End Sectors Size Id Type 2020-12-02-raspios-buster-armhf-full.img1 8192 532479 524288 256M c W95 FAT32 (LBA) Device Boot Start End Sectors Size Id Type 2020-12-02-raspios-buster-armhf.img1 8192 532479 524288 256M c W95 FAT32 (LBA) Device Boot Start End Sectors Size Id Type 2020-12-02-raspios-buster-armhf-lite.img1 8192 532479 524288 256M c W95 FAT32 (LBA) (retropie) $ df --human-readable /boot Filesystem Size Used Avail Use% Mounted on /dev/mmcblk0p1 512M 47M 466M 10% /boot

@mitu I've tried both .bin and .zip, the hash file for astrocde says .bin files as well as all the BIOS files zipped in the roms directory as well as being in the main BIOS directory. Still no dice.

@mitu Ok, thanks for all the fast help!

Ah, so that was it, thanks! I tried to update it without removing the older version first.