Amiberry - preparation for next release

[midwan]

The Amiberry BETA testing is going really well, and I'm planning a code freeze at this point. We should be able to get a new stable release really soon now - haven't set a fixed date yet, but I'll update you once that is done also. For now, it's a good opportunity to sync with the various package / distro managers regarding the upcoming changes, to ensure a smooth upgrade.

The version history (https://github.com/midwan/amiberry/wiki/Version-history) is fully updated with any new features and changes, of course. But here are some details that are more specific regarding building it from source, which might have an impact in the distro:

1. The Makefile has some targets updated, mostly for the RPI platforms. It will also now abort with an error if an invalid target is specified, with the PLATFORM= option.
2. All Amiberry versions use SDL2 now, the old SDL1 version is gone. The RPI1-RPI2-RPI3 platforms can even use SDL2 with the rpi back-end (e.g. the ones provided by the Raspbian repo), but unfortunately the RPI4 cannot. You'll need an SDL2 compiled from source for the RPI4, with the kmsdrm back-end enabled and the rpi back-end disabled (--enable-video-kmsdrm --disable-video-rpi).
3. The old SDL1+Dispmanx version is replaced with the new SDL2+Dispmanx version (the PLATFORM name is the same). This one uses Dispmanx for all graphical operations, GUI and emulation screen, and uses SDL2 for everything else (events, sound, game controller handling, etc.). You will need the libsdl2-dev libsdl2-ttf-dev libsdl2-image-dev libraries installed.
4. Some new options have been added in the amiberry.conf file, to control global defaults of the emulator. You can check the full documentation regarding that file here: https://github.com/midwan/amiberry/wiki/Amiberry.conf-options
5. The whdboot directory has been updated with a new WHDLoad booter (compared to the previous stable), so make sure you update that as well, when you do an "update from source". Not just the binary.
6. Regarding amiberry.conf, a default file is now included in the git repo, although this is regenerated when you click on Rescan ROMs from the Paths panel. It's mostly for people who haven't clicked on that and are wondering where the file is.
7. The compiled binary is now always named amiberry, regardless of what PLATFORM option was specified. It's up to the package / distro maintainers to rename it if necessary.

I think that is all for now, but I've forgotten anything I'll come back with more.

It would be great if you would start testing the integration of the BETA (currently sitting in the dev branch) with the distro, to catch any issues early. Ping me if you run into problems or have any questions, please!

[MichaIng]

@midwan
Many thanks for providing this info:

1. Makes sense, assuming RPi by default is no good behaviour due to the large amount of platforms supported meanwhile.
2. No issue with us since we use SDL2 in all cases. Jep, fkms (fake KMS) driver is default on RPi4 (Raspbian) since full KMS is not supported currently and legacy non-GL seems to not work fine as well. Since this was required/recommended for Amiberry and is used in our implementation anyway, no issue with that.
3. Same as 2)
4. Nice to know, although defaults seem to be fine. But use_sdl2_render_thread does not make sense with SDL2 KMSDRM, even if it works, since its multi-threaded there already, right?
5. Included in our install archive
6. We need to remove this step then on reinstalls: https://github.com/MichaIng/DietPi/blob/dev/dietpi/dietpi-software#L8400
   • Instead move existing config file as backup out of the way and include the default in our install archive to take place. Inform user about the backup, in case custom settings want to be migrated.
   • Since e.g. with v2.25 the old config file became incompatible, we should always move the default back in place on reinstall/update.
7. Makes sense, most probably what users expect when building from source and makes source build scripting easier as well.

---

With v6.27 I will as well test our new Buster SDL2 binaries on Stretch. If it fails due to outdated library packages, I will rebuild them for Stretch. This allows much more lightweight install since a bunch of unused libraries do not need to be installed, most importantly no Xserver is required. This quickly saves dozens of dependency packages from being installed and ~200 MiB disk space.

All new builds will be done and tested with the Amiberry beta then.

[midwan]

Awesome, thanks!
I'll also remove the default target from the Makefile, there are so many platforms nowadays it doesn't make sense to have a "default" one. ;-)

[MichaIng]

@midwan
Jep, at least not as long as there is no generic or auto-detection platform which does an always "working" build based on installed libraries/drivers, detected architecture and such.

[midwan]

How are you guys doing regarding this? Is everything set, do you need assistance with something, or do you need more time?
Just checking so I can plan for the release accordingly, I was hoping of going for it some time next week.

[MichaIng]

@midwan
Next week should be fine. Since we anyway host the binaries on our server, it will not break anything. I plan to release DietPi v6.27 relatively soon, more fixing some bugs and enhancing our error handler than implementing new features.

After you did the release, I will rebuild LibSDL2 and Amiberry for Stretch and Buster all together, probably including RockPro64. This should be done anyway better sooner than later, since currently our Odroid XU4 binary does not work. I was misinterpreting the comments it was blocked for pre-v6.26: The binary did not require Stretch to work, but it was build for Jessie and a new build obviously is required to be done against Stretch to work with the Stretch LibSDL2 binaries.

[MichaIng]

@midwan
How far are you with Armbian 2.26 release? I am doing last preparations for DietPi v6.27 beta, which is mostly a bugfix release with few new features. It would fit perfectly if I could compile and test it with Armbian 2.26 release, including SDL2 for Stretch and a working XU4 (Stretch) binary. I'll then create new DietPi v6.27 RPi images, pre-configured for automated Armbian 2.26 install and fast boot.

[midwan]

@MichaIng
We found some bugs that we have been fixing the last few days (reported by the RetroPie team), so the release got delayed until we have those fixed. As of yesterday, there are no more outstanding bugs to fix for this version, so I'm giving it a few more days just in case something comes up.

Otherwise, it's ready to go (and I've already started working on further updates in separate branches, to avoid messing anything up). :)

[MichaIng]

@midwan
Great, there is also at least one more issue I need to fix for DietPi v6.27, so sounds like the timing meets quite well.

[midwan]

@MichaIng
Amiberry v3.0 was released today :)

[MichaIng]

@midwan
I am currently running the compilations. Two questions:

• master branch is stable release branch, right? Because release page shows v3.0 as latest release but master branch is already on v3.0.3. I guess some childhood fixes due to the vast changes with v3.0 that we want to include in DietPi?
• Since there are no pre-compiled RPi binaries for v3.0.3, as long as the OS/package arch matches, one can run e.g. RPi4 build on RPi2 as well, right? I have an RPi2 only here, but run compilations in systemd-nspawn container (qemu emulated ARM) of fresh RPi DietPi image. For libSDL2* this worked very well, however just wanna be sure that Armbian compilation does not depend on actual ARM/GPU features that are present on the building system.

[midwan]

@MichaIng
Yes, v3.0.3 is currently the latest stable, but I have no binaries for it yet. The reason for that is that I'm working on one more bugfix (which will bring us to 3.0.4). I'll release binaries for it at that point. ;)

It's not a problem compiling the RPI4 version on an RPI2/3, as long as the OS is the same.

[MichaIng]

@midwan
A, okay, probably I should wait for v3.0.4 then?

Hah, now I see that Raspbian Buster ships KMSDRM-enabled libSDL2 already. But this is not true for Debian Buster, so all other SBCs, right? .... nope indeed not: https://buildd.debian.org/status/fetch.php?pkg=libsdl2&arch=armhf&ver=2.0.10%2Bdfsg1-1&stamp=1568932042&raw=0

SDL2 Configure Summary:
Building Shared Libraries
Building Static Libraries
Enabled modules : atomic audio video render events joystick haptic sensor power filesystem threads timers file loadso cpuinfo assembly
Assembly Math   :
Audio drivers   : disk dummy oss alsa pulse sndio(dynamic)
Video drivers   : dummy x11 opengl opengl_es2 vulkan wayland
X11 libraries   : xcursor xdbe xinerama xinput2 xinput2_multitouch xrandr xscrnsaver xshape xvidmode
Input drivers   : linuxev linuxkd
Using libsamplerate : YES
Using libudev       : YES
Using dbus          : YES
Using ime           : YES
Using ibus          : YES
Using fcitx         : YES

Okay I'll just stay with building the lightweight libSDL2* for all SBCs, also this means e.g. v2.0.10 instead of v2.0.9. Those will be packaged together with the Armbian files per-SBC/RPi model with Environment=LD_LIBRARY_PATH=/mnt/dietpi_userdata/amiberry/lib, so it cannot mess with any other, even custom compiled, libSDL2 version.

[midwan]

@MichaIng
Depends on how quick you want to release updates. :)
The current v3.0.3 includes some smalll but important bugfixes, including a performance related one (which usually triggers most users).

The thing I'm investigating has to do with Vsync refresh rate, when using Dispmanx (so, RPI only) if the monitor is also using the same refresh rate as the emulated one. It seems to "miss" one in two frames, so you get half of the expected FPS (e.g. 25 FPS in a 50Hz mode, 30 FPS in a 60Hz mode).

[midwan]

@MichaIng
And v3.0.4 was just pushed to the repo, fixing the following:

• Incorrect vsync calculation when using Dispmanx
• Added version information in -h command-line option

I'll prepare binaries this week. ;)

[MichaIng]

@midwan
Great, i'll run the builds later, as well for all RPi models. Will upload them with build log, so in theory you could use them as well.

I am thinking about GitHub Actions now. In theory, one should be able to use the Ubuntu VM, download current Raspbian, chroot it via systemd-nspawn + binfmt-misc + qemu-arm-static emulation and automate the builds 🤔.

[midwan]

Funny, I've been thinking about something similar since yesterday as well. :)
In my case, I think I'll just create some bash scripts to automate the compilation and packaging of new releases, perhaps even actually uploading them as a new release on Github as well. They can all run on my RPI4 which is fast enough to go through all of them in about 30 minutes or so (did that manually yesterday and timed it).

Then we can use something like https://github.com/github/hub to create/upload the release binaries.

[MichaIng]

Update implemented: https://github.com/MichaIng/DietPi/pull/3252/files
Reinstall is done automatically on dietpi-update to v6.27. I tested on RPi2 which worked very well, further testing should be done during beta phase.

I noticed that our autostart.uae, shipped with our Amiberry install on last versions, is invoked automatically, even when not defined via command argument, which is great. I thought that happens with default.uae named file only. However, I removed it from new download archives, since it contained a bunch of auto-generated and wrong entries, e.g. non-existing kickstart/floppy files etc. This should be created freshly by user on fresh installs. Reinstalls will however move all amiberry/{conf,kickstarts,savestates,screenshots} to the new instance.

[midwan]

@MichaIng
Good stuff!
Meanwhile, I've just bumped Amiberry to v3.0.8:

v3.0.8

• Synced with latest WinUAE updates
• Fix limit check in custom
• Fix CD32 CD boot after reset
• Generate better partition HDF default geometry if size is >= 1000MB
• More fixes for Documentation update for Samba #542: Some joysticks have no Axes or Buttons (e.g. Wii Remote IR), skip those

[MichaIng]

@midwan
Okay, I'll update our binaries then, besides the ones for RPi Buster that you provide compiled already. Yours are compiled on RPi Buster system, hence not compatible with Stretch libraries, right?

[midwan]

@MichaIng
Yes, that is correct. :)

There might be another update coming soon (in a week or less), btw.

[MichaIng]

@midwan
Jep that is no problem. Since our hosted archives do not contain any version info anymore, we can simply re-compile and repack with newest version at any time, same for SDL2 libs and capsimg.

Only issue: If we want to keep our users up-to-date, we'd need to check their Amiberry version. In theory we could simply check the binary timestamp and then either inform users via MOTD and/or on dietpi-update about available Amiberry update and the possibility to run dietpi-software reinstall 108 to apply it, or we run this automatically, at least on dietpi-update, since the install is now quite slim without additional dependency reinstalls (all SDL2 packaged into Amiberry archive).

Or can the amiberry binary be used to identify its version, a way that it does not require an attached screen, active TTY and such? Wiki page with cmd arguments/options would be nice btw 😉.

[midwan]

@MichaIng
v3.0.9 was just released! :)
https://github.com/midwan/amiberry/releases

[MichaIng]

@midwan
Great, binary updates on our server is in process, will be shipped with v6.27.

Little question: You recommend to start with a fresh amiberry.conf on updates, right?
I'll adjust reinstalls to simply overwrite files with the new archive but by this preserve any custom files and dirs that were created by users. As long as there are no deprecated files, this works, and I can keep track about possible deprecated data files whenever uploading updates, which will then be removed on next dietpi-update automatically.
I'm just thinking if new armbian.conf shall be better stored as "armbian.conf_new" or the old stored as "armbian.conf_bak" and new one copied in place instead.

[midwan]

@MichaIng
Most of the time it's fine to leave the previous one in place, but there are issues if you have a really old one and have invalid options in there. It's easier to just recreate that when troubleshooting, for example.

For the v3.x updates you don't have to overwrite it, as nothing breaking was introduced. Some new options are available and they are all documented in the relevant wiki, but they all have default values.