Latest Release 5.7.2 - missing buster assets?

[NoobieMaks]

@midwan
Would it be possible to share also the buster versions, I would especially need the sequel to "v5.7.1-debian-buster-armhf-rpi3.zip"

[midwan]

Starting with this version, Buster is no longer supported - Debian itself declared it's EOL from the beginning of next month as well, and there were issues with the older libraries there that held things back.

You can still try to compile it yourself if you'd like, of course - the build should still work there, but some things might not work perfectly (mostly related to KMSDRM).

[NoobieMaks]

This is really a sad message for me.
5.7.1 would have been absolutly perfect (for me) if it would not had the config-xml-bug.
So this improved 5.7.2 would have everything I need.

The official Retropie downloads are still only for buster.

How does compiling work? I have no experience.
Could I take the amiberry-file of another rpi3-asset?

Could you move your Buster Support End one more version - please - the config issue would be really a good reason for this last time?
Fingers crossed

[cmitu]

5.7.1 would have been absolutly perfect (for me) if it would not had the config-xml-bug.
So this improved 5.7.2 would have everything I need.

The RetroPie package has 5.7.1 with the bugfixes that are part of 5.7.2 and should still work on Buster.

[NoobieMaks]

OK, since when is this? I made an install from source and from binary last week, and both were 5.6.6.

[cmitu]

Since last Friday - RetroPie/RetroPie-Setup#3931.

[NoobieMaks]

Hey guys, thanks a lot, it took me a little time but now I was able to update Amiberry via RetroPie-Setup to 5.7.1+
@midwan Many thanks for developing Amiberry to 5.7.2!
@cmitu Thank you for integrating the main parts of 5.7.2 to 5.7.1+ of the Retropie-Setup.

[NoobieMaks]

@midwan @cmitu
I'm sorry to bother you but my first tests with 5.7.1+ on my RetroPie 4.8.7 - buster are not logical for me.

Positiv is that BattleIsle does now start when I have the WHDLoad-Custom-Line C1=3 manually edited (#1343).
I think this was the reason for 5.7.2 (= 5.7.1plus on RetroPie = 5.7.1 + manual edits;
see amiberry: upgrade to 5.7.2; handle dispmanx deprecation #3931; RetroPie/RetroPie-Setup@a233272)

But it seems to me that now the existing uae-files are not recognized in terms of custom controls.
Easy test:
Open a game -> go into GUI -> change in Custom controls for exmple the East button from None to Joy2 Up (should be a Jump in a Jump'n Run Game) -> save the file -> go back to the game and enjoy jumping per button. Quit the game.
Then open the game again -> go into the GUI again -> take a look on the Custom controls and you will see that the change of before is not shown, and it also does not work in the game.
When I check the the uae-file I see it has the right entry but it's not shown and working in the GUI and game.

I tried these things again under 5.7.0. There everything works as it should be, uae-file changes are shown and active at the next start. Only the BattleIsle-Issue is under 5.7.0 worse with the addition of the WHDLoad panel, under 5.6.8 it was still possible to start it with the manual uae-line trick.

@midwan : Could it be that there went something wrong in the bugfix or even there was not really a bug before but now?
@cmitu : Could it be that your manual bugfix edit of 5.7.2 on top of the locked 5.7.1 went wrong?

By the way:
Would it be possible to make "default sound" to a part of the amiberry.conf-file.
My try of "default_soundcard_default=true" did not work.

[NoobieMaks]

@cmitu Meanwhile I also tested 5.7.1 - it also does not recognize the custom controls from the uae-file, so the question above for you is obsolete.

[midwan]

@NoobieMaks this should really be a separate issue - moving it there.

[midwan]

@NoobieMaks / @cmitu
The new release(s) are out today, and as an exception, I've added Buster binaries for rpi3 and rpi4 this time (since it helps with the bugfixes about these recent issues). No Dispmanx version of course, but they still might be useful.

Keep in mind that these updated versions use a different gfx code, where we have 2 windows behind the scenes (one for the GUI, one for the emulation screen). When using KMSDRM as you'll be doing when running from the console, these open up as full-window screens anyway. The older code used only one window, which got resized when you switched from one to the other.

[cmitu]

@midwan thank you for the heads up.