• Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login
RetroPie forum home
  • Recent
  • Tags
  • Popular
  • Home
  • Docs
  • Register
  • Login
Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

Amiberry broken on Pi 4/Buster

Scheduled Pinned Locked Moved Help and Support
amigaamiberrypi4buster
8 Posts 3 Posters 663 Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S
    sleve_mcdichael
    last edited by sleve_mcdichael 10 Mar 2024, 05:18 2 Oct 2024, 22:40

    Amiberry install from both source/binary, gives the error:

    malloc(): unsorted double linked list corrupted
    Aborted
    

    https://github.com/BlitterStudio/amiberry/issues/1366

    https://github.com/BlitterStudio/amiberry/discussions/1295

    Replacing amiberry binary with one extracted from the releases page, does work:

    https://github.com/BlitterStudio/amiberry/releases/tag/v5.7.1

    https://github.com/BlitterStudio/amiberry/releases/download/v5.7.1/amiberry-v5.7.1-debian-buster-armhf-rpi4.zip

    Discussions on github point to a missing capsimg.so library, which is accounted for in the RP scriptmodule, but absent from the package repository (from the 5.7.1 version used, anyway -- it is present in the current master branch.)

    E7ACE987-0E27-4580-A363-198650D6600D.jpeg

    It looks like it used to be a submodule, but then rolled the sources in manually?

    https://github.com/BlitterStudio/amiberry/pull/1374

    I don't know what to do with any of that. I've only just started to explore the amiga and its library, and hit this immediate roadblock.

    ETA: in the build log it looks like it's still cloning into the capsimg submodule but then something goes wrong and it don't get the output file in the end (L129):

    cp: cannot stat '*capsimg.so': No such file or directory
    

    https://pastebin.com/hJnFf84U

    M 1 Reply Last reply 3 Oct 2024, 04:50 Reply Quote 0
    • M
      mitu Global Moderator @sleve_mcdichael
      last edited by mitu 10 Mar 2024, 05:51 3 Oct 2024, 04:50

      [...]

      Discussions on github point to a missing capsimg.so library, which is accounted for in the RP scriptmodule, but absent from the package repository (from the 5.7.1 version used, anyway -- it is present in the current master branch.)

      The capsimg.so is indeed missing (binary or source install) and this should be fixed in the build script. However, I don't think that's the cause of the crash - even with the .so included it still crashes. The binary package from the Amiberry releases does indeed work, despite the fact that the .zip also doesn't have the capsimage.so file in the plugins folder.

      I'll try to see where the crash occurs and what's causing it.

      1 Reply Last reply Reply Quote 1
      • B
        BuZz administrators
        last edited by BuZz 10 Mar 2024, 09:20 3 Oct 2024, 08:19

        I noticed an error when building recently (relating to capsimg location). It's on my list to check.

        To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

        M 1 Reply Last reply 3 Oct 2024, 09:09 Reply Quote 0
        • M
          mitu Global Moderator @BuZz
          last edited by 3 Oct 2024, 09:09

          @BuZz Yes, the copying of the campsimg.so build artifact to $md_build/plugins is not working, but the error occurs whether that's fixed or not. I'm starting to suspect is configuration related, since the backtrace from the crash is pointing to a simple static var initialization - can't see how that triggers a SIGABRT.

          1 Reply Last reply Reply Quote 0
          • M
            mitu Global Moderator
            last edited by mitu 10 Mar 2024, 17:05 3 Oct 2024, 15:49

            Hm, after fixing the capsimg.so plugin installation and trying to compare our build to the one produced upstream, I can't reproduce the issue anymore.

            @sleve_mcdichael can you test to see if https://github.com/RetroPie/RetroPie-Setup/pull/3978 fixes the issue for you ? Make sure you have the necessary Kickstart files in $HOME/RetroPie/BIOS/amiga just to rule out any missing model KS files.

            EDIT: PR has been merged, so you can just update RetroPie-Setup then try a source update.

            S 1 Reply Last reply 4 Oct 2024, 00:42 Reply Quote 1
            • S
              sleve_mcdichael @mitu
              last edited by 4 Oct 2024, 00:42

              @mitu yes install from source works now, thanks.

              Re: kickstart roms -- I had a hard time figuring out which of the many different given filenames I was supposed to be using, but I think I've got it mostly sorted out, now.

              ...

              I've found that, using BrutalFootball_v1.21_CD32.lha for example, none of the following:

              kick40063.A600 #as distributed, "somewhere"
              kick40063.a600
              40063.A600
              40063.a600 #as named in the error message
              

              ...none of those work. The error shown is as:

              20241003_133417.png

              ...which appears to be looking for 40063.a600 even while that file is present, and does not work.

              However, that same file renamed as either of:

              Kickstart v3.1 rev 40.63 (1993)(Commodore)(A500-A600-A2000)[!].rom
              Kickstart v3.1 rev 40.063 (1993)(Commodore)(A500-A600-A2000)[!].rom
              

              (nb. .63 vs .063) ...both these does work.

              On the Amiberry github, I do see this filename format for several of the kickstarts, but I still don't know what to do with these last two remaining:

              42baa124    kick34005.CDTV     89da1838a24460e4b93f4f0c5d92d48d
              9e6ac152    kick39106.A4000    9b8bdd5a3fd32c2a5a6f5b1aefc799a5
              

              Maybe these just aren't used by Amiberry? I see the kick34005.CDTV listed only in the lr-puae section, and the other one doesn't seem to be mentioned anywhere...

              1 Reply Last reply Reply Quote 0
              • S
                sleve_mcdichael
                last edited by sleve_mcdichael 20 Dec 2024, 06:11

                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.

                S 1 Reply Last reply 20 Dec 2024, 19:52 Reply Quote 0
                • S
                  sleve_mcdichael @sleve_mcdichael
                  last edited by sleve_mcdichael 20 Dec 2024, 19:52

                  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.

                  1 Reply Last reply Reply Quote 0
                  • C craigbot referenced this topic on 1 Jan 2025, 13:41
                  • First post
                    Last post

                  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.

                    This community forum collects and processes your personal information.
                    consent.not_received