@sugarfree That makes sense. I could have thought of this earlier. Big thanks!

malloc(): unsorted double linked list corrupted Aborted

Not sure this is really fixed, after all. I am now getting this same error again when re-installing Amiberry. As before, no error when using binary from github release page, but does error when using RetroPie version (built from source or precompiled. RPi4.)

Investigating, it seems related to amiberry.conf:

Using github binary, works with or without amiberry.conf; is created if not present.

using RetroPie binary, does not work without. However, if amiberry.conf exist with a defined rom_path= to the kickstarts, then RP binary does work, and conf is populated with remaining values.

oddly, it also still works if conf contains only floppy_sounds_dir=/opt/retropie/emulators/amiberry/data/floppy_sounds/

...so it's just these two?

Seems yes: if both rom_path and floppy_sounds_dir are removed from the working conf, then RP version aborts with error; but if either one is present (even as the only entry), then it works fine, and fills in remaining values, including whichever of these two was left out.

This COULD be work-around by pre-populate conf with rom_path value, but it don't explain why github version still work fine with no conf at all.

# set various media paths to the 'amiga' rom folder - if [ -f "$md_inst/conf/amiberry.conf" ]; then iniConfig "=" "" "$md_inst/conf/amiberry.conf" + iniSet "rom_path" "$biosdir/amiga" iniSet "floppy_path" "$romdir/amiga" iniSet "harddrive_path" "$romdir/amiga" iniSet "cdrom_path" "$romdir/amiga" iniSet "lha_path" "$romdir/amiga" - fi + chown "$__user":"$__group" "$md_inst/conf/amiberry.conf"

Current script module does set some paths in conf, but the behavior confuse me. Since the conf file is not exist on clean install, these values are not set at first. Defaults are then used ($md_inst) for some time until (optional) if user chooses to reinstall/update amiberry. Only at that time, file DOES exist, and so paths are now CHANGE to use $romdir instead of $md_inst like they had been using. Is this really the intended way, and if so then why?

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.

@mitu Okay - I see...I am using the "normal" vice, because it was often mentioned to use this one instead of the "lr".
So I will try this and will report
Thanxalot

@Scraperdude said in Skyscraper stuck on version 3.7.7 for Raspberry pi 5.:

Should I then abandon the Pi5 and get a Pi4 instead?

Not yet.

When I update it defaults to 3.7.7. I see the latest version is 3.9.

Not sure what version of RetroPie-Setup you're on, but the latest version of RetroPie-Setup will install the 3.14 version of Skyscraper (latest, at this time). So, make sure you're fully updated before attempting the installation/update again.

@Jezzer said in Compiling drivers for Deskpi:

I tried to install cmake from buildessentials but it appears that you need buster / bookworm / whatever it's called. I wasn't sure what I should be installing here... Anyone know how to do this?

cmake is already installed on the RetroPie image for the Pi4 and the buildessential metapackage is installed aswell, so compiling shoudn't be an issue. Did you try compiling and got an error - if so, can you post the actual error message here so that we can help fix it ? Do you have a link to the instructions/documentation of the drivers where the installation/compilation is explained ?

You can try adding the mali flag to your system flags, but if your system has the gles2/gles3 flags and the installed libMali also adds the proper symlinks to the default GLES library names, then it shouldn't be an issue. More details with what system/os/modifications added to RetroPie-Setup would be helpful to solve this.

----- SOLUTION FOUND -----
Posting a solution here for any CTRL+F heroes

Retroarch Quick Menu > Core Options > HLE BIOS = ON

I don't know what the setting even does, I'm just glad autoload actually works now.
Gonna put some tags below for search engines to pick up on:

lr-flycast, flycast, autoload, auto-load, auto load, crash, savestate, black screen, saves, saving, loading, loads

@JimmyFromTheBay There is a pure c version of raine on it's github, that theoretically should be able to compile, but, someone with a bit more c,ompile-fu than me will have to look at it, i get an error on linking the executable.

I'll include the error context just in case someone can point me in the right direction.

/usr/bin/ld: linux-gnu-sdl2/object/sdl/sasound.o: in function `my_callback': sasound.c:(.text+0x134c): undefined reference to `ProfileStop' /usr/bin/ld: sasound.c:(.text+0x137c): undefined reference to `ProfileStart' collect2: error: ld returned 1 exit status make: *** [makefile:1498: raine] Error 1

Use an X11/Wayland desktop session and rotate the display via xrandr/wlrandr.

@mitu No, not about something else. This game ran with a simple n64 controller, but it did also have support for another. I am only talking about running this through my xbox controller.

Older devices (GL2/OpenGLES2) cannot use glcore, since it needs at least GL3/OpenGL3 to work.

Can you elaborate on that sentence above, though?

Some cores need a specific OpenGL and/or Vulkan version to work and if the front-end driver (i.e. RetroArch's) does not support that version, the core won't work.
For instance, Flycast can be compiled for Vulkan and when started will request a Vulkan context from RetroArch. But if RetroArch doesn't support Vulkan, the core cannot start and the emulation stops.