Amiberry don't start after upgrading

[PARALAX1974]

Hello!

I can't start Amiberry any more after upgrading from Version 5.2 to 5.6.6 with Retropie 4.8.1 (with the "update package" script) on my Raspberry Pi 4b. After selecting the system and ADF files, I am thrown back to the menu every time. I have never updated the system since mid-2022 because it was not necessary. Do I perhaps need any other packages to make it work? Can I somehow start the emulator from the command line (pi@retropie) to be able to see the error message? This is not possible from the Emulationstation menu.

[midwan]

RetroPie usually handles their upgrades themselves, with their scripts taking care of any requirements. Did you upgrade the retropie-setup script first? If not, that should be your first step.

Meanwhile, Amiberry just got a new release a few days ago: 5.7.0 - but I don't believe that's included in RetroPie's scripts yet.
You could of course install it yourself if you wanted, but you'd have to compile it from source (by following the instructions in the Readme).

You can always start Amiberry from the command prompt, and see if it throws any errors. RetroPie installs it under this directory: /opt/retropie/emulators/amiberry - you'll need to "cd" into that first, before launching it (with any optional parameters, if you want).

[PARALAX1974]

Thanks for the quick reply. Since I haven't used my Raspberry Pi for a while, I had to google some basic Linux commands and command line functions. I have now found the log file and the following is displayed in the "dev\shm\runcommand.log":

Parameters:
Executing: /opt/retropie/emulators/amiberry/amiberry.sh "/home/pi/RetroPie/roms/amiga/Spiele - OCS/Agony - Disk 1.adf"
Unsupported archive: /home/pi/RetroPie/roms/amiga/Spiele - OCS/Agony - Disk 1.adf
Launching ...
./amiberry --model A500 -0 /home/pi/RetroPie/roms/amiga/Spiele - OCS/Agony - Disk 1.adf -1 /home/pi/RetroPie/roms/amiga/Spiele - OCS/Agony - Disk 2.adf -2 /home/pi/RetroPie/roms/amiga/Spiele - OCS/Agony - Disk 3.adf -3 /home/pi/RetroPie/roms/amiga/Spiele - OCS/Copy Protected/Agony - Disk 1.adf -G
./amiberry: error while loading shared libraries: libportmidi.so.0: cannot open shared object file: No such file or directory
~

So do I have to install "libportmidi" afterwards or update other packages? I hope that I don't have to update the whole system because of this, because so far everything else is working as usual and I don't have the time to set everything up again.

[solskogen]

that should do it, yes.

[PARALAX1974]

That worked and the emulator is starting again from Emulationstation!

Unfortunately, I cannot start the emulator from the command line, even if I am in the right directory. When I enter "amiberry" I always get the message "Command not found". What am I doing wrong? I am in the directory "pi@retropie:/opt/retropie/emulators/amiberry" and it still doesn't work, even though the file with exactly that name is in the folder.

And how can I update Amiberry to version 5.7.0, even if the Retropie binary script does not yet show me this version? Can I also install the package from the command line with "sudo apt install amiberry" or does it only work with the "Install from Source" function in the Retropie installation script?

[giantclambake]

The command you want is ./amiberry (note the dot forward-slash)

There are some instructions about upgrading here... https://github.com/BlitterStudio/amiberry/wiki/Upgrading-to-the-latest-version/e4b711ff20afe34f21268e72d7160045baf4ef23

HTH

[PARALAX1974]

Meanwhile Version 5.7.1 has been compiled and released as "Update from Source" in the Retropie Config Menu. But it don't seems to work at all. After starting Amigberry and putting a disk in drive, Aimiberry freezes completely. I only can reboot the system via SSH with "sudo reboot". When I try to delete the "amiberry.conf", it don't start at all. The Log file then shows:

malloc(): unsorted double linked list corrupted
/opt/retropie/emulators/amiberry/amiberry.sh: Zeile 107: 5852 Abgebrochen "$emulator" "${params[@]}"

It seems that it's a wrong compiled version or something or incompatible with my system. Or maybe another package missing?

[midwan]

RetroPie is a special case, as it still runs on Debian Buster (at the time of writing). They have their own deployment with patches, which when I tested it a few days ago, works as expected. Newer versions of Debian don't show that error and work normally, so I think it's related to older versions of libraries included in the distro (maybe glibc?).

[PARALAX1974]

I have now updated the system and all libraries with "sudo apt upgrade", but that is not the problem. I have now found out that the crashes are only caused by IPF disk images. If I select normal ADF images, the problem does not occur. This worked perfectly with the previous versions. Furthermore, the "VSync" option is a nice and long overdue improvement. Scrolling is now finally smooth, but unfortunately the emulator then runs much too fast, similar to NTSC games. However, that cannot be the case, as I only use PAL games for testing and the system is set up accordingly. It's a shame that so many new problems arise with every update. Apparently the Retropie team is not able to compile the versions properly. :-(

[giantclambake]

@PARALAX1974

Apparently the Retropie team is not able to compile the versions properly.

That doesn't mean a lot to me ~ in what way doesn't it compile "properly"? ... ie; as in fails to compile, or, compiles but the binary throws errors?

Do you have a link to that discussion?

TIA

[PARALAX1974]

No, unfortunately I don't. All I can say is that this version has more bugs than before and doesn't work properly. So I guess I'll just have to hope that the problems are fixed in the next version.

By the way, the game "Zarathrusta" still not works since several versions if the "Cycle Extact" options are activated. This affects not only the original version (Extended ADF file, IPF freeze Amiberry), but also the cracked versions. With version 5.2 everything was still working fine and apparently 100% OCS/ECS compatible, but perfect 50 fps scrolling was missing.

[giantclambake]

Okay, thanks for checking ... it was worth an ask =)

All I can say is that this version has more bugs than before and doesn't work properly.

I would disagree with that statement wrt to 'recent' debian releases... however.... I fully expect things to get progressively worse when the base system is built upon debian buster. With LTS support stopping for buster on June 30th, I expect this to get even more horrorshow ....I've said it before, and I'll say it again.... the retropie distro really needs to adopt debian bullseye (at least ;).

Wrt IPF support ...I don't typically use that media, and thus don't check it ~ now that I do, see #1367 .... I think the retropie team check their amiberry builds, but can you confirm for me whether or not capsimg.so is present?

I'll check the titles you mention here in due course ;)

[giantclambake]

//Only tested v5.7.1 release and git preview thus far on x86-64... I'll need retest v5.7.1 on the RPi4, given the results below ...just //how much can a Koala bear? =)

@PARALAX1974 ~ thank you for bringing this to my attention... Zarathrusta.ipf proved to be an interesting/useful test case indeed! Do of course read on, although I've mainly included it here for reference ;)

@midwan

Note: To workaround #1367 I did a git pull of master , and compiled capsimg.so in that tree. I then moved this library into the amiberry v5.7.1 tree (/plugins), which was compiled using /refs/tags/v5.7.1.tar.gz source tarball...this seems sane enough to me. Keep in mind, debian 12.5 amd64 / x11 / xfce4 ....

Test of: Zarathrusta.ipf

Using preview;

./amiberry Zarathrusta.ipf

Title starts & runs fine using the base builtin config, but horizontal scrolling text could be smoother.
F12 -> Display panel -> enable VSync checkbox --> Resume
The horizontal scrolling is now buttery smooth, but the music replay (I guess tracker.mod) is replaying too fast, and some samples are getting garbled in result.

Took some time, but I eventually found the trigger to be Sound panel -> Sound Buffer Size ...lowering this to a value of 4 helped considerably wrt the music playback. It didn't clear it up entirely, and still relayed too fast, but I discovered changing this value had the greatest effect on the accuracy of the playback, and a minimum of sound clicks/stutters .... that config.uae file attached.

Using amiberry v5.7.1;

./amiberry Zarathrusta.ipf

Pretty much the same results as above, and the same configuration approach somewhat fixes the music playback. still too fast.

-in both tests, music was sped up as a result of enabling VSync -- this could not be remedied by anything other than disabling VSync

Using either amiberry version;

./amiberry Zarathrusta_v1.2_1501.lha

Same result as above, music was sped up as a result of enabling VSync -- only way to fix this was to disable Vsync.

Using a different title, either version of amiberry....

./amiberry SoundsOfGnome.dms

Same result as above... ;^/

Me thinks something is broken here (I rarely use the VSync option ;)....this all helped uncover a couple of (cosmetic) GUI oddities as well...I'll hoist tickets on those. I want to look at this on the RPi4 before making more conclusions wrt VSync...

HTH

Zarathrusta.uae.gz

[giantclambake]

//same behavior on RPi4

Found it --> when VSync is enabled, default framerate is set to NTSC (60Hz)

That's incorrect ... we should follow the Chipset settings.... so this is a bug. This may also be related to Status Line (native) not working as expected....hoisting ticket ;)

[PARALAX1974]

To be honest, I don't think it's particularly bad that you're not always up to date, true to the motto: Never change a running system! It would be welcome if this emulator stayed that way and was based on Retropie and the system used there, even if it's still Debian 10 in 5-10 years. I don't believe in constant updates at all and have even deactivated my Windows updates completely since 2021 (except browser updates) since the first installation and prefer to use external programs for security monitoring. I'm still on the Windows version from over 3 years ago and am very happy with it, with no notable functional limitations and it will stay that way for me until I get a new PC. I only install and update manually what is absolutely necessary in order to be able to use certain programs (e.g. Net Framework components or drivers if required). Back in the 80s and 90s, you only had one operating system and got by with it for several years. Sounds old-fashioned, but that's just how I am! :-)

In any case, I'll stick with Retropie and will happily download the package updates with "sudo apt upgrade", but I won't install a new operating system that would mean I'd have to spend days to reconfigure and test everything. If necessary, I'll just do without newer Amiberry versions.

But back to the topic: I had almost thought that when the VSync function is activated, the system would run in NTSC mode and only properly and without sound dropouts if the "NTSC" option is activated in the chipset settings. Instead, the VSync option should run at 50 instead of 60 fps, as long as the chipset is not explicitly set to "NTSC", but unfortunately it doesn't. In other words: The PAL emulation is currently unusable with the VSync option activated.

And "Zarathrusta.ipf" doesn't even start for me with version 5.7.1, but crashes Amiberry completely. However, I didn't start the game using the command line environment, but rather with the help of an empty ADF disk that I created especially for Retropie. Then I called up the menu with F12, inserted the "Zarathrusta.ipf" disk and voila - crash! The ADF version does boot, but the game doesn't work as it should, because the spaceship is immediately destroyed when you fly around it. That was definitely not the case with version 5.2. The only way to fix this is to deactivate the "Cycle Exact" function under "Chipset". But this option was created precisely so that even difficult games and demos can run smoothly. And at least all of the games and demos I tested ran smoothly with version 5.2, but not since version 5.6 (or earlier).

[midwan]

Regarding VSync:
Amiberry always uses VSync internally, for showing updates to the display. The checkbox controls if this will be passed to the internal chipset emulation as well, or not. In the end however, it's the native resolution you have set for your device, that will determine the actual refresh rate for your monitor. If it's set to 50 or 60Hz, then refreshes will happen using Vsync either way.

That means that if you're emulating PAL, the ideal situation is to have your monitor set to 50Hz as well. Amiberry does not change the refresh rate of your monitor itself :)

Regarding Updates:
I understand that "if it's not broken, don't fix it" idea. But in this case, it is broken. Buster comes with a very old version of SDL2, which has several known bugs that have been fixed since. It's the same with several other system libraries as well, not to mention support for newer devices (like the RPI5). If you want to stick to the RPI3, that's fine. But you will most likely lose out on some of the newer stuff that comes out. After all, that's the reason newer versions of Amiberry also come out, to fix known issues, improve compatibility, add new features, etc.

Amiberry has been tested extensively on Debian-based distros, and the issues found above are not present there. Indeed, they are not present in RetroPie as well, if that's installed on a newer version of Linux, which indicates that the problem is probably in some of the libraries that come with it (SDL2, glibc, etc). And Debian Buster (which RetroPie is still based on) is out of support from it's LTS in a few days, so you probably won't be getting any new packages after that, either.

[PARALAX1974]

Regarding VSync: Amiberry always uses VSync internally, for showing updates to the display. The checkbox controls if this will be passed to the internal chipset emulation as well, or not. In the end however, it's the native resolution you have set for your device, that will determine the actual refresh rate for your monitor. If it's set to 50 or 60Hz, then refreshes will happen using Vsync either way.

That means that if you're emulating PAL, the ideal situation is to have your monitor set to 50Hz as well. Amiberry does not change the refresh rate of your monitor itself :)

Thanks for the explanation! Because I changed the link to the config file due to problems with the Retropie configuration in connection with my USB joystick adapter, it could be that Amiberry is now ignoring the display resolution I selected, because I had clearly set it to 50 Hz in the Retropie configuration. But it didn't help, no matter what I set there. In the end, I don't know which refresh rate is actually being used, but it seems to be 60 Hz. In any case, the Amiga no longer runs correctly with the VSync option and the sound cuts out. It might be advisable to build in an option that adjusts the refresh rate independently, just like it is possible with the joypad assignment - for people who simply can't (or don't want to) use the Retropie config.

By the way, I already use a 2 Ghz. (instead 1,8 Ghz.) overclocked Raspberry 4b with 8 GB, which is fast enough to run almost all current emulators at full speed, even PlayStation 1 or Nintendo 64.

I have also updated SDL2 and all other available drivers in the Retropie configuration. I simply cannot do more than that. I definitely do not want to install a new system that might cause problems with the other emulators or Retropie itself, which I also need for other presentation purposes. The areas of application are simply too important to me for that.

[giantclambake]

Back in the 80s and 90s, you only had one operating system and got by with it for several years. Sounds old-fashioned, but that's just how I am! :-)

You've no idea how much that made me smile =) This is exactly one rationale I consider, when asked the question "Why do you bother building your own linux systems, from scratch?" .... answer: I don't have to change or update anything. An example here, would very much be my 'AmiLFS' build based upon the LFS-11.3 book...it has all (and only) what's required, to turn a USFF machine like the Lenovo m93p into an Amiga emulation powerhouse running amiberry to achieve those ends. It's now about 2years old, and anytime soon debian unstable will catch up where the LFS-11.3 build has been for the past 2years - I'm older-fashioned than you ;)

@PARALAX1974 .... You haven't answered my question ~ is the capsimg.so library present, in the plugins directory of your amiberry tree? If it isn't, that would very much explain the crash you're seeing...

Wrt the Vsync issue .... little doubt we'll tease that out in the ticket, and as you'll note there, with the current implementation, the VSync option will not work on my (basic, generic, widescreen 16:9) display hardware, as it cannot do a v_refresh of 50Hz in any screenmode what-so-ever =) ...

....further, I just wandered into my house-mate's room, and his display unit (identifies as DH Print 24") doesn't offer a 50Hz v_refresh either (nouveau x11 driver)....and I immediately begin to wonder what the blazes is going on here? Do any modern widescreen display units offer a 50Hz v_refresh? I'll have a little sortie on that later....but no matter the result, we can't go and say "to use amiberry VSync option, requires you have a 50Hz capable display setup"...no? Is that a requirement for WinUAE VSync to work? If not, is it a limitation of something else foist upon us by the linux environment?

It is widely known, I have a particular abhorrence for running Amiga software titles, particularly games, on widescreen display units. At best, I consider it 'technically heretic'...these titles were intended for 4:3 aspect display hardware, and if I want to play such an Amiga title on modern displays, the only way it 'looks' correct to the ingrained mental pathways of my 66yo brain, is like this...

....because my brain is accustomed to a particular aspect ratio for these games. Yet, I know modern display hardware is going to need 2 vertical black bars left/right to achieve the same result, but I'd prefer that, and would never choose the stretch the Amiga game graphics, to fullscreen fill a widescreen display....it "doesn't look right" ...it's not honoring the historical aspect ratio. That's just my personal opinion/preference of course, but I feel it's...prudent... to point that out, because....

....I have 4:3 aspect displays here (19" LCD), all are capable of 50Hz v_refresh (although EDID puts 1280x1024@60Hz as optimal, 50Hz is also available). I will setup a test here, using the m93p/debian 12/amiberry v6.3.3 and one of these display units, and test what happens with the VSync option, with that host hardware. If it in any way works as expected, personally speaking I'd turn my back to all modern display units, and declare "There is no problem here, folks should be running with 4:3, 50Hz capable display units anyway"....lol... =)

It's not the answer of course, and perhaps old-fashioned...facts remain ; VSync not an option on display hardware incapable of 50Hz

Wrt Chipset->Cycle Exact.... I was over at Horace's place chatting about that, obviously about the XML and whdload handling, see HoraceAndTheSpider/Amiberry-XML-Builder#125 ...considering what could the XML could do to cover off that case that the default profile of amiberry v5.x has these options disabled (by design we think), as opposed to v6.x where these options are enabled by default. Upshot is, there might be a case for a CHIPSET option in the XML (would perhaps have the options of BOTH/EXACT/DMA), which would make sense for those titles, low powered arm devices...but we'll see ;)

If, like others I know in that part of the world, at the now most folks are observing the cultural tradition, of taking their summer holidays very seriously... and a doubt midwan is exempt ;) Holidays should be enjoyed to the fullest ~ free time is short =)

[PARALAX1974]

I let the Retropie script do the updates and assumed that all the necessary files would be installed automatically. I can check this again in a few days when I get back home. But I assume that this has all already happened.

[midwan]

The RetroPie script needs an update, it doesn't create/copy all the directories, doesn't copy capsimg.so in the plugins directory where it's expected, adds a whdboot-dist directory for no reason (not sure why), etc.

[giantclambake]

That'd explain it...

[PARALAX1974]

Which script is it exactly? The "Retropie Setup Script" or another one? I had actually updated all the scripts manually beforehand, but not all cores via the "Update Packages" menu, but rather via the "Manage Packages" menu, because I wanted to leave certain systems unchanged. Apparently the Retropie team is lagging behind with some scripts. Is there another way to install Amiberry manually from the command prompt and if so, with which command? I would then simply leave the currently used version 5.2 and not uninstall it, so that it still appears in the Retropie menu and I can start it with the previous setup for the refresh rate and then install the latest version manually by overwriting the current version. Maybe the corresponding folders will then be created and this trick will work. But then I would need the files compiled by Retropie, if necessary as a gzip file. I could also unpack it manually and then copy it to the folder "/opt/Retropie/Emulators/Amiberry" using "Midnight Commander". Unfortunately, I can't test this until I get back home.

[midwan]

the main setup script calls separate ones for each emulator. I'm referring to the one about Amiberry specifically.

[PARALAX1974]

I finally had time to look at the whole thing again using the current setup script provided by Retropie, which I was finally able to download and upgrade to the lastest version 4.8.8. Unfortunately, it didn't help. The directories are still created according to the old standard when Amiberry is installed. At least I was able to prevent the emulator from crashing with IPF-Files by manually creating the "plugin" folder and copying the "capsimg.so" into it. However, there are still instabilities with the "Cycle Exact" emulation, see my report on "Zarathrusta", which still doesn't work correctly (ship will be destroyed). The sync function also cannot be used with the 50 Hz setting in the Retropie launch menu, as the sound keeps cutting out. There is still a lot to be improved here. I'm giving up for now and will stick with version 5.2 until a newer and possibly corrected version (after 5.7.1) is available for Retropie.

[giantclambake]

I just had a check, and the capsimg part of the retropi scripting has been fix in RetroPie-Setup/blob/master/scriptmodules/emulators/amiberry.sh 5 days ago. That should work up to and including the current amiberry releases, but will need fixing again after the next amiberry releases (due to changes in the libcapsimg.so build process)....I'm not sure if retropi v4.8.8 is 'latest' wrt it's github repo.

The 50Hz VSync thing is largely my misunderstanding, here, but as said after teasing it out in the ticket, and finding it worked as expected on a 50Hz v_refresh capable display hardware, I closed the ticket accordingly ... we did manage to pick-out a small GUI enhancement from that, so it was a worthwhile question. As stated there after better understanding the problem, would be to create an opengl window... and run that at 50Hz for the emulator to display on. An analogy might be running glxgears from an xterm, and it will run synchronized to the vertical refresh rate...ie; 60Hz / 60FPS ... if however you invoke glxgears -swapinterval 2, it will still run synchronized to the vertical refresh rate, but at twice the swapinterval ..ie; 30Hz / 30FPS. That could lead to a possible solution, with a monitor capable of 100Hz v_refresh, to have an opengl window running at 50Hz...but I don't know how the emulation would hook to that...but that's kinda what you have to do ;)

The ADF version does boot, but the game doesn't work as it should, because the spaceship is immediately destroyed when you fly around it. That was definitely not the case with version 5.2. The only way to fix this is to deactivate the "Cycle Exact" function under "Chipset". But this option was created precisely so that even difficult games and demos can run smoothly. And at least all of the games and demos I tested ran smoothly with version 5.2, but not since version 5.6 (or earlier).

This has me a little bit confused, because afaik Cycle Exact is disabled by default wrt amiberry v5.7.x , ergo if it's enabled that's coming from somewhere else. This is made clear in the wiki...

Cycle Exact: These options allow you to enable Cycle Exact mode for the Chipset. This will increase compatibility, but also requires significantly more resources to emulate, so it's not enabled by default. For Amiberry version 5.x, it's only available for A500 emulation. This is different in the newer v6.x versions, where the option is enabled by default, when selecting a standard A500/A1200 configuration.

This option was created for those Amiga software titles, that require precise, 'tight' timings to run ~ for the (I think?) bigger majority of Amiga titles that don't require this to work properly, you leave it off to save emulation resources. As said though, you shouldn't have to deactivate it, as the default setting is off...

[PARALAX1974]

I think we're talking past each other. I usually have the "Cycle Exact" option enabled by default, which is why I get the error described in connection with the game and this affect other demos too like "World of Commodore '92" which crashes completely with this settings. In any case, the problem is not mine, as WinUAE works fine with exactly the same settings with the very same disk image. I use "Cycle Exact" in almost every A500 and A1200 environment, as long as no accelerator cards are used. And yes, the option is disabled by default with version 5.7.1, but I still use it because my Raspberry Pi 4b with 2 GHz (overclocked) has more than enough resources for it. I just wanted to point out that it's a bug that should perhaps be fixed next time.

[PARALAX1974]

If you press any joypad button after selecting the ROM within 5 Seconds, you will be taken to a selection menu in which you can select the corresponding core or emulator for the corresponding ROM (or disk), such as UAE4ALL or Amiberry. There you can also set the refresh rate for the selected emulator or the started ROM.

The TV used is a Philips 22PFL4208K/12.

[PARALAX1974]

I have now found a workaround that also works with the Philips TV, using "raspi-config". There you can simply force the screen resolution to 50 Hz. This will allow Amiberry to run smoothly on this screen too. It's a bit annoying, because you have to keep changing it back to "standard" after changing the screen if you don't want to stick with 50 Hz permanently, but it's better than nothing. In addition, the other emulators under Retropie can be set to 60 Hz independently. Unfortunately, I haven't found a tool that allows you to temporarily switch between 50 and 60 Hz in the command prompt without saving it in the system. If there is a way, I'd be happy to hear any tips.

I'll probably have to do without the "Cycle Exact" settings for now, but as long as the games and demos still run, it's fine. We'll see when and if I can find exceptions. What still remains unanswered, however, is the question of why this setting does the opposite of what it is actually supposed to do. Just because a certain game or demo does not need this function, it makes no sense to me why it would no longer work if this was supposed to improve compatibility. "Cycle Exact" should improve compatibility, not make it worse. For this reason, I assumed it was a bug.

[giantclambake]

M'kay... I think what you're seeing is some extrapolation of my rudimentary example above using glxgears, and the cmdline option -swapinterval N ...in the example, I used a value of 2 ... which is 60Hz/2=30FPS ....if I wanted (or it was capable) to get glxgears to render a 50FPS window, the cmdline would be glxgears -swapinterval 1.2 ... this is actually exposed in SDL as SDL_GL_SetSwapInterval, wherein you can choose whether or not window updates are sync'd with display vsync....

...I had a bit of a read through libretro-uae/tree/master/sources/src/gfx-sdl/sdlgfx.c, and it seems a lot of this stuff is exampled there...as best I understand it, you create a opengl surface of, for example, 640x480 with 16bpp, and use adaptive or immediate updates, instead of using the display v_refresh sync value... my best guess would be, 'the other emulators' you mention than can be set to change refresh rate, may be using opengl calls in similar fashion. Currently, the OpenGL build on amiberry needs a bit of TLC...although it does compile now, it's doing a black screen with vertex errors on this nvidia rig... ;^}

The answer your question, Cycle Exact is not doing the opposite -- the execution timing of the core emulation has improved to the point that particular setting is no longer required, and enabling it 'unnecessarily' may and can be detrimental, not beneficial. It's like...wasting emulation resources to achieve perfect timings, which you don't need -- those resources are put to better use inside the emulation engine, to make it run better in other respects. On low-powered platforms like the RPi boards, making best use of resources really matters ;)

[giantclambake]

@PARALAX1974 ...Toni confirmed he could recreate this Cycle Exact problem in WinUAE, but it looks like a real corner case ; he's rewriting the custom chipset code anyway to improve it, and these problematic titles need to be rechecked after that's done. If they're still having issues with Cycle Exact beyond that point, it may be related to something the titles are doing (there's only a few known to be affected at this time), and things would need more debugging...

...as such, I'm not going to hoist a ticket here, as it's a known upstream bug, with certain titles, in the WinUAE code that amiberry is based upon....and of course it's not a 'show stopper' ; there's an easy work-around =) He said "all the hacks and ugly special cases are gone" wrt to the rewrite itself, and then it dawned on me this sort of thing I'd been through before, wrt my time spent with WINE (when I was doing stuff for CodeWeavers' CrossOver product)....

....you can logic this out, if you take a step back... a real Amiga was cycle exact, that's the intrinsic nature of that hardware chipset. The very fact the emulation has these widgets, is indicative of the case the custom chipset code is not 'perfect' ...if it were, we wouldn't need these switches =) Now...likewise speaking... little hacks and ugly special case work-arounds, also patch around deficiencies that may exist in the custom chipset code, at the time they were included, and these things can/may be activated or not, by say the Cycle Exact widget... and time moves forward....

...back then, an Amiga title may indeed have required Cycle Exact to be enabled, as it relied perhaps on one of these hacks or special case work-arounds, to be able to run properly. Today, whatever that same title relied on with Cycle Exact = True, has (apparently) been fixed in the chipset code ...ie; it's now running cycle exact enough to meet this title's requirements, without the need of any tweaks Cycle Exact = True once provided....in fact, now, it's a bad idea to do that.. ;)

In effect, it's somewhat difficult to label this as a bug, as the cause may well be contained in code that's soon to be written out, it is what it is B)

[PARALAX1974]

The thing with "glxgears" doesn't work for me. If I enter the command in the command prompt, I only get "Error: Couldn't open display (null)" and if I enter "glxgears swapinterval 2" or something similar, I only get a "Usuage" list of the possible commands, including only "display, stereo, samples, fullscreen, info, geometry" and that's it. But none of these commands work either. But no matter, as I said, I found the solution via "raspi-config" and now set it to 50 Hz by default. I can then switch the emulators to 60 Hz for the corresponding NTSC ROMs using the "Runcommand" script. Nevertheless, thanks for the tip!

Regarding my "Zarathrusta.ipf" disk image (and possibly other games & demos, some of which I have already found), all I can say is that the claims regarding WinUAE are simply not true. I tested it with WinUAE 4.4.0, the basis on which the Amiberry core runs, as well as with the current version 5.3.0. Both versions run perfectly with my disk image and the two activated "Cycle Exact" options without any graphic or sound errors. I never had any problems with WinUAE or any of the games or demos when using these options. How Toni was able to reproduce the problem I described on the Raspberry Pi in the Windows version is a complete mystery to me. I can happily attach my config file again so that the people responsible can take a look at it.

But I stick to my statement and the fact is that it still worked with Amiberry 5.2, no matter how often someone here claims to refute it. By the way, I would like to refer to, which underlines my logical theory.
https://eab.abime.net/showpost.php?p=1694065&postcount=7

[PARALAX1974]

I have now received a few explicit tips from the Amiga scene about which demos are heavily dependent on the "Cycle Exact" emulation and compared them with WinUAE.

The result with WinUAE 4.4.0 & 5.3.0 with activated "Cycle Exact" emulation::

World of Commodore '92: Runs normally
Arte: Runs normally
Hologon: Runs normally

without "Cycle Exact" Emulation:

World of Commodore '92: Slowdowns in the first shadebobs part / bluish filled-circle-worms
Arte: Some slowdowns in the starfield part (Music & Animation)
Hologon: Distinct consistent glitches in the light-shaded textured cube parts

The result with Amiberry 5.7.1 (and probably also 5.7.3) on the Raspberry Pi with activated "Cycle Exact" emulation:

World of Commodore '92: Crashes immediately
Arte: Runs normally, no slowdowns
Hologon: Runs normally, no glitches

without Cycle Exact emulation:

WOC '92: Runs normally
Arte: Runs normally, slowdowns in the starfield part
Hologon: Runs normally, no glitches

In Amiberry 5.2, the "Hologan" demo has some graphical errors and slowdowns that no longer occur in the current version, even with the "Cycle Exact" option activated. They are just not as serious.

I saved myself further tests because the result is already clear based on WOC '92 and Zarathrusta.

The "Cycle Exact" emulation is therefore faulty and can only be used partially, not optionally as is the case with WinUAE. While there are improvements to some challenging demos, there are also new bugs in older software.

The results are clear, verifiable and indisputable. And there are people in the scene who have already confirmed it, see here:
https://eab.abime.net/showthread.php?t=117988

I can therefore only ask again that this bug (and that is all it is) be fixed and the faulty "Cycle Exact" emulation fixed so that it can be used permanently as an option again.

[giantclambake]

malloc(): unsorted double linked list corrupted
/opt/retropie/emulators/amiberry/amiberry.sh: Zeile 107: 5852 Abgebrochen "$emulator" "${params[@]}"

Twice I've seen this (once in Deutsch , once in English).... decided to track it down...

1. RetroPie-Setup/blob/master/scriptmodules/emulators/amiberry.sh applies patches to the amiberry build, from within RetroPie-Setup/tree/master/scriptmodules/emulators/amiberry/*.diff

2. RetroPie-Setup/blob/master/scriptmodules/emulators/amiberry.sh applies a sed script...

# copy shared uae4arm/amiberry launch script while setting is_amiberry=1
    sed "s/is_amiberry=0/is_amiberry=1/" "$md_data/../uae4arm/uae4arm.sh" >"$md_inst/amiberry.sh"
    chmod a+x "$md_inst/amiberry.sh"

3. At the end of RetroPie-Setup/blob/master/scriptmodules/emulators/uae4arm/uae4arm.sh ... (which becomes amiberry.sh)

# start directly into emulation if the first argument is set
[[ -n "$arg" ]] && params+=(-G)

echo "Launching ..."
echo "$emulator" "${params[@]}"

"$emulator" "${params[@]}"
archiveCleanup

popd

So it appears the error is spawn from here somewhere ~ perhaps a manual build omits the diffs, and that's why malloc() is flying off the rails? In any event, doesn't seem like amiberry is directly involved here AFAICT...

HTH

[PARALAX1974]

The funny thing is that this error message only appears in the corresponding log file if you try to start Amiberry with the config file that comes with Version 5.7.1 or if you don't use one at all. It only works with the old config file from version 5.2, which is the only way I can get version 5.7.1 to work. I hope that the Amiberry updates provided by Retropie in the future don't cause any such problems, but that's not in my control.