DietPi-Software | Amiberry: Add support for Buster and RPi4

[TuKo1982]

Can't install AmiBerry package on latest DietPi Buster (Pi4)

Installer complains that libsndio6.1 has no installation candidate and exits with error code 100.

[MichaIng]

@TuKo1982
Many thanks for reporting.

Will have a look and in case update the pre-req package to a Buster-matching version.

---

Okay, I updated the library package for Buster support: 4886c55 (Changelog: 80c710c)
But support for RPi4 is still outstanding, since we need to compile an SDL2 + DispmanX binary for it. See:

• https://github.com/midwan/amiberry#using-sdl2--dispmanx
• https://github.com/midwan/amiberry/wiki/First-Installation
• https://github.com/midwan/amiberry/wiki/Compile-SDL2-from-source

[MichaIng]

@midwan
Or do you plan to ship a release with pre-compiled RPi4 SDL2 + DispmanX binary anyway or have one that you can send us?

I just don't have an RPi4 here, but otherwise will ask @Fourdee .

Another unimportant question:
Do you prefer "AmiBerry" or "Amiberry"? 😃
I'm aligning naming + capitalisation where required, in case of Amiberry I am just not sure whether to follow the logo with capital B or the text/docs etc with non-capital b.

[midwan]

@MichaIng
I'm currently testing a (rather big) update of Amiberry for the next release, but I've updated the Makefile in master to include an RPI4 target. So that can already be used, and I could send you binaries if you like.

Of course, you'd still need SDL2 in the system as well as the other dependencies (they haven't changed, but SDL2 has seen several updates with bugfixes). SDL2 still needs to be compiled from source if you want to get KMSDRM support, for launching things full screen from the console. DispmanX is still there in Buster, and the FKMS driver is used by default, so there's no issue.

Regarding the naming: I'd prefer "Amiberry", even though the logo doesn't indicate that. The logo was designed in the early days of the project, and is due for an update however. :)

[MichaIng]

@midwan

I'm currently testing a (rather big) update of Amiberry for the next release

That sounds great 👍.

So that can already be used, and I could send you binaries if you like.

Would be very kind. Just send to: micha_at_dietpi.com

Of course, you'd still need SDL2 in the system as well as the other dependencies (they haven't changed, but SDL2 has seen several updates with bugfixes).

We have some pre-compiled SDL2 package for x86_64, ARMv6+7, that we install together with Amyberry + dependencies of course. Although it sounds like they should be re-compiled by times as well. Will do that for x86_64 and ARMv7 at least.

Regarding the naming: I'd prefer "Amiberry", even though the logo doesn't indicate that. The logo was designed in the early days of the project, and is due for an update however. :)

I though so, so the guess/change with last commit was correct then.

[midwan]

I've updated the ZIP archive over at https://github.com/midwan/amiberry/releases/tag/v2.25 to include RPI4 binaries as well now.

The rest of the package remains the same, until the new beta is ready for release - then we'll merge from dev to master and provide new binaries as well.

[MichaIng]

I added the binary to our archive as well, however CloudFlare caching leads to currently the download still serves the old archive.
Made some other minor enhancements, e.g. removing the obsolete adfdir.conf as well as amiberry.conf if existent (reinstall), to allow Amiberry recreating it as recommended, and removing non-required binaries and capsimg.so files to keep the dir slim and clean.
Also updated autostart and online docs to match Amiberry (non-capital "b") and some other minor wording.

Commit DietPi-Software: b129182#diff-d92a6ee04e02fd2a2dc23d5bec3e6a98L8474-R8381
DietPi-Autostart: 0359ada
Online docs: https://dietpi.com/phpbb/viewtopic.php?p=64#p64

And I recognised now that our Amiberry RPi image is actually not really pre-installed. It only has Amiberry marked for automated install on first boot + related fast boot autostart option (via dietpi.txt). Otherwise it is a standard RPi image. This makes it very easy to update based on current RPi4-capable Buster + DietPi v6.25 image.

@midwan
https://blitterstudio.com/amiberry/ requires a tiny update then for the new Buster archive and since we have changed how WiFi must be configured for first boot:

• https://github.com/MichaIng/DietPi/blob/dev/dietpi.txt#L24
• https://github.com/MichaIng/DietPi/blob/dev/dietpi/func/dietpi-wifidb#L176-L194
• https://dietpi.com/phpbb/viewtopic.php?p=9#p9

But I need to test our SDL2 on Buster first. EDIT: Installs fine, binaries execute fine. Nevertheless updated binaries make sense by times.

[midwan]

@MichaIng
Thanks for the update!
Regarding the file cleanup: capsimg.so is actually required if you want to be able to load *.ipf files in the emulator, so it's best to leave it in place. :)

One more thing to look for, since we're doing this:
BlitterStudio/amiberry#514

Perhaps this can be fixed with the new Buster-based image?

[MichaIng]

@midwan

Regarding the file cleanup: capsimg.so is actually required if you want to be able to load *.ipf files in the emulator, so it's best to leave it in place. :)

It is left in place. We ship three of them, for RPi, for Asus TB and for Odroid XU4. The matching one is moved/renamed, the other ones are removed. Same for the binaries:

# $amiberry_filename e.g. matches amiberry-rpi4-sdl2-dispmanx
mv "$G_FP_DIETPI_USERDATA/amiberry/$amiberry_filename" $G_FP_DIETPI_USERDATA/amiberry/amiberry
# $capsimg_filename e.g. matches capsimg-rpi.so
mv "$G_FP_DIETPI_USERDATA/amiberry/$capsimg_filename" $G_FP_DIETPI_USERDATA/amiberry/capsimg.so
# Only amiberry-* and capsimg-* (with dash) are removed
rm $G_FP_DIETPI_USERDATA/amiberry/{amiberry,capsimg}-*

One more thing to look for, since we're doing this:
BlitterStudio/amiberry#514

Could be: #2718
However this was resolved with v6.23 already. However further debug over there 🙂.

[TuKo1982]

Ok, package is now installing correctly with 6.26. Amiberry binary needs probably a recompile against new libsndio7 and autostart script might also need some love.

[MichaIng]

@TuKo1982
Many thanks for testing!

binary needs probably a recompile against new libsndio7

It would make things too complicated (and too much effort) if we created different binaries for each distro version (<< different libsndio versions), IMO.

and autostart script might also need some love.

What you suggest?

The service that is started in every case:

[Unit]
Description=Amiberry Amiga Emulator (DietPi)

[Service]
#StandardOutput=tty
#StandardInput=tty
#TTYPath=/dev/tty1
#TTYReset=yes
#TTYVHangup=yes
WorkingDirectory=$G_FP_DIETPI_USERDATA/amiberry
ExecStart=$xinit_start$G_FP_DIETPI_USERDATA/amiberry/amiberry -f $G_FP_DIETPI_USERDATA/amiberry/conf/autostart.uae

[Install]
WantedBy=local-fs.target

• Not sure about the TTY ideas, however running it on the default TTY makes sense to me, a reset/clearing is done automatically by the login prompt, when exiting Amiberry from fast boot mode and I would not do this actively e.g. to keep error logs present in case of failure.
• Some permissions/restrictions and/or even a non-root run user could be used to satisfy usual security standards.

The autostart.uae:

config_description=UAE default configuration
config_hardware=true
config_host=true
config_version=3.6.0
amiberry.cd_path=/mnt/dietpi_userdata/amiberry/cd32/
amiberry.hardfile_path=/mnt/dietpi_userdata/amiberry/
amiberry.floppy_path=/mnt/dietpi_userdata/amiberry/disks/
amiberry.rom_path=/mnt/dietpi_userdata/amiberry/kickstarts/
;
; *** Controller/Input Configuration
;
joyport0=mouse
joyport0_autofire=none
joyport0_friendlyname=Mouse
joyport0_name=MOUSE0
;
joyport1=joy0
joyport1_autofire=none
joyport1_friendlyname=Keyboard as Joystick [Default]
joyport1_name=JOY0
;
;
;
input.joymouse_speed_analog=2
input.joymouse_speed_digital=10
input.joymouse_deadzone=33
input.joystick_deadzone=33
input.analog_joystick_multiplier=15
input.analog_joystick_offset=-1
input.mouse_speed=100
input.autofire_speed=0
kbd_lang=us
;
; *** Host-Specific
;
amiberry.vertical_offset=0
amiberry.hide_idle_led=0
amiberry.gfx_correct_aspect=1
amiberry.kbd_led_num=-1
amiberry.kbd_led_scr=-1
amiberry.scaling_method=-1
amiberry.use_analogue_remap=false
amiberry.use_retroarch_quit=true
amiberry.use_retroarch_menu=true
amiberry.use_retroarch_reset=false
;
; *** Common / Paths
;
use_gui=yes
kickstart_rom_file=/mnt/dietpi_userdata/amiberry/kickstarts/ru/Kickstart v2.04 rev 37.175 (1991)(Commodore)(A500+).rom
kickstart_rom_file_id=C3BDB240,KS ROM v2.04 (A500+)
kickstart_ext_rom_file=
flash_file=
cart_file=
;
; *** Floppy Drives
;
floppy0=/mnt/dietpi_userdata/amiberry/floppy_images/Frontier - Elite II_Disk1.adf
floppy1=
floppy2=
floppy3=
nr_floppies=2
floppy_speed=800
;
; *** Hard Drives
;
;
; *** CD / CD32
;
cd_speed=100
;
; *** Display / Screen Setup
;
gfx_framerate=0
gfx_width=640
gfx_height=256
gfx_refreshrate=50
gfx_refreshrate_rtg=50
gfx_lores=false
gfx_resolution=hires
gfx_linemode=none
gfx_fullscreen_amiga=true
gfx_fullscreen_picasso=true
ntsc=false
;
; *** CPU options
;
cpu_speed=max
cpu_type=68000
cpu_model=68000
cpu_compatible=true
cpu_24bit_addressing=true
fpu_no_unimplemented=true
fpu_strict=false
compfpu=true
cachesize=0
;
; *** Memory
;
chipmem_size=2
z3mapping=real
fastmem_size=4
a3000mem_size=0
mbresmem_size=0
z3mem_size=0
z3mem_start=0x40000000
bogomem_size=0
rtg_modes=0x502
;
; *** Chipset
;
chipset=ecs
chipset_refreshrate=50.000000
collision_level=playfields
chipset_compatible=A500+
rtc=MSM6242B
cia_todbug=true
immediate_blits=false
waiting_blits=automatic
fast_copper=false
;
; *** Sound Options
;
sound_output=exact
sound_channels=stereo
sound_stereo_separation=7
sound_stereo_mixing_delay=0
sound_frequency=44100
sound_interpol=none
sound_filter=off
sound_filter_type=standard
sound_volume_cd=0
;
; *** Misc. Options
;
bsdsocket_emu=false

• It looks a bid strange to me to define CPU type and things like that here, since this is used across SBCs with different CPUs.
• However AFAIK this is based on some default file and we only added/edited the files paths to /mnt/dietpi_userdata/amiberry?

I am open for suggestions, since I don't actively use Amiberry, I have not much experience or knowledge about what works well and has which effect here 😉.
I will also ask @Fourdee do to some review when he finds time.

[MichaIng]

Still an issue on Debian/Raspbian Buster: The binaries (or SDL2) need to be compiled against libsndio7.0 indeed, otherwise fail to start. Will see if we install the old libsndio6.1 package hosted on our server for now, otherwise a doubled set of pre-compiled binaries is required.

[midwan]

@MichaIng
Why not just re-compile for Buster anyway, instead of keeping older libs around? It seems the most sane option going forward to me... :)

[MichaIng]

@midwan
Okay, I actually wanted to postpone this to get v6.26 released as soon as possible, but maybe it makes sense to get this fully finished now.

So SDL2 needs to be recompiled, once for ARMv7 and once for the RPi1/Zero armv6hf. We allow SDL2 install via dietpi-software as well for x86_64, however this is easiest and the way I re-validate dependencies, build process etc. first anyway.

I will not touch the Stretch versions anymore, since those are still working and we will not offer Stretch images anymore, besides for XU4 currently, but not for long.

I just revisited your SDL2 compilation Wiki and the one from libsdl.org, and I am wondering why we actually compiled it with libsndio? DietPi comes by default with ALSA (libasound2) when audio is enabled, which is done as well when installing Amiberry. Are you aware of any reason why SDL2 should be compiled with sndio support when using ALSA for audio? So far I would compile it with --enable-alsa and --enable-video-kmsdrm only, disabling everything else actively or have it skipped by not installing the related library-dev packages. This version of SDL2 is for Amiberry on DietPi only, for everything else, one can simply install the repo packages. So no need to add any extra support that is not used by our setup.

[midwan]

@MichaIng
Hm, I'm not sure, I personally never had to enable/disable anything else besides the options specified in our wiki also: https://github.com/midwan/amiberry/wiki/Compile-SDL2-from-source

Basically the only reason we need to compile from source and not use the repo provided binaries, is the option --enable-video-kmsdrm. Otherwise it comes with --enable-video-rpi and with KMSDRM disabled, by default.

[MichaIng]

@midwan
Jep these two options would be sufficient of course, but disabling other unused features should reduce the dependencies/libraries (like libsndio) the binary needs to start.
I found some older SDL2 binaries that are not installed anymore (https://dietpi.com/downloads/binaries/rpi/sdl2_rpi.7z) which contain as well SDL2 mixer and net packages, probably the compile-time options and dependency libraries were based on this earlier build. However I will play around a bid.

One other question: Did you ever try to build Amiberry on x86_64? Would make general testing much easier when not always an SBC + SDcard needs to be prepared. E.g. hacking a new platform into the Makefile like:

USE_SDL2 = 1
CPPFLAGS += -D_FILE_OFFSET_BITS=64 -DUSE_SDL2 -DUSE_RENDER_THREAD -DFASTERCYCLES

• The architecture should be estimated automatically? At least e.g. Odroid N1 platform as well leaves CFLAGS empty. But I am a total build noob 😅.

[midwan]

@MichaIng
Let me know if you need any help with compiling SDL2, we've done it so many times I could practically do it with my eyes closed nowadays. :D

Amiberry doesn't run on x86 platforms yet, as there's ARM-specific code (e.g. inline assembly) in certain areas for optimization purposes. There is a plan to make an x86 version of it eventually, but since it's a one-man-show for now, it will probably take a while. There are other things I'm trying to fix and update first. :)

[MichaIng]

@midwan
Minimal build:

Enabled modules : atomic audio video render events joystick haptic sensor power filesystem threads timers file loadso cpuinfo assembly
Assembly Math   : mmx 3dnow sse sse2 sse3
Audio drivers   : alsa(dynamic)
Video drivers   : kmsdrm(dynamic)
Input drivers   : linuxev linuxkd
Using libsamplerate : NO
Using libudev       : YES
Using dbus          : NO
Using ime           : YES
Using ibus          : NO
Using fcitx         : NO

• GLES video driver is required additionally to KMSDRM, so missing above, right?
• ime is for some Japanese character/input support if I understood it right?
• You list liblzma-dev and libfreetype6-dev in your minimal requirements but I could not find any use of them in configure.ac. Probably not required anymore?
  Also when installing them, the configure result is just the same.
• There is one configure error due to missing /usr/bin/file, being called in configure script. Not sure if its important, but could be added to the minimal requirements.
• pkg-config was required on my x86_64 VM to allow PKG_CHECK_MODULES find the libraries correctly. Otherwies libdrm and libgdm were never found.

So with GLES:

Enabled modules : atomic audio video render events joystick haptic sensor power filesystem threads timers file loadso cpuinfo assembly
Assembly Math   : mmx 3dnow sse sse2 sse3
Audio drivers   : alsa(dynamic)
Video drivers   : kmsdrm(dynamic) opengl_es2
Input drivers   : linuxev linuxkd
Using libsamplerate : NO
Using libudev       : YES
Using dbus          : NO
Using ime           : YES
Using ibus          : NO
Using fcitx         : NO

• Anything missing?

[midwan]

It looks OK for a minimal build.
If anything's missing, it should show right away after running Amiberry on that, in which case we could go back and re-configure/compile SDL2 accordingly. But I think it should be fine.

[MichaIng]

Finally only these files/links are sufficient to place into /usr/local/lib:

lrwxrwxrwx 1 root root   21 Sep 19 20:49 libSDL2-2.0.so.0 -> libSDL2-2.0.so.0.10.0
-rwxr-xr-x 1 root root 7.7M Sep 19 20:49 libSDL2-2.0.so.0.10.0
lrwxrwxrwx 1 root root   21 Sep 19 20:49 libSDL2.so -> libSDL2-2.0.so.0.10.0

• Fourdee created a package, but it contains the sources, sdl2-config etc as well, so actually look more like the -dev package instead of the compiled libraries only, and the Debian repo package as well contains the library file + symlinks only: https://packages.debian.org/buster/amd64/libsdl2-2.0-0/filelist

Btw sorry to be a bid verbose here. I am as said compiling noob, so documenting my steps here serves as well myself at a later time 😉.

Next the image and ttf, ah probably those require the additional packages liblzma-dev and libfreetype6-dev, lets see.

[midwan]

No problem at all.
But in order to compile Amiberry from source, you WILL need the -dev packages of those libs. :)
They are not necessary to run Amiberry of course, unless you want to do an upgrade from source (with a new compile from source).

[MichaIng]

@midwan

But in order to compile Amiberry from source, you WILL need the -dev packages of those libs. :)

Jep, for the compilation make install installs those, the above is only what is sufficient for end user.

---

libsdl2-image compilation:

configure: WARNING: *** Unable to find JPEG library (http://www.ijg.org/)
configure: WARNING: JPG image loading disabled
...
configure: WARNING: *** Unable to find PNG library (http://www.libpng.org/pub/png/libpng.html)
configure: WARNING: PNG image loading disabled
...
configure: WARNING: *** Unable to find Tiff library (http://www.remotesensing.org/libtiff/)
configure: WARNING: TIF image loading disabled
...
configure: WARNING: *** Unable to find WEBP library (http://code.google.com/intl/en-US/speed/webp/index.html)
configure: WARNING: WEBP Pimage loading disabled

• Any of those required? Since you don't mention it in the docs, I guess not?

---

libsdl2-ttf compilation:

configure: error: *** Unable to find FreeType2 library (http://www.freetype.org/)

• There libfreetype6-dev is required 👍.

[midwan]

libpng is definitely required, as we have some PNG icons to load in the GUI. ;)

[MichaIng]

@midwan
Okay, probably something to add to the docs then :).
EDIT: Ah not, it is pulled as dependency of libfreetype6-dev https://packages.debian.org/buster/libfreetype6-dev

[MichaIng]

@midwan
Okay SDL2 libraries compiled and ready for testing: https://dietpi.com/downloads/binaries/buster/

I finally managed to compile it on x86_64 VM by chrooting/systemd-nspawn via qemu-arm-static into an RPi respectively Asus TB image. This allows me compiling without the need to spin up or even own a related SBC and keep a build environment.
QEMU does not have support for this special armv6hf that RPi1 and RPi Zero versions are, it shows armv7 there as well, but AFAIK this doesn't matter as long as all libraries and build tools are pulled from Raspbian repo, which always supports RPi1/Zero then.

One more question:

• Does Amiberry/the binaries as well use libraries from within its working dir, respectively the dir of the binary itself? Or is there a way to achieve this?
• Since these are special Amiberry SDL2 libraries, it would make sense to not install them as shared libraries into the system but simply ship them together with the Amiberry archive.
• I will anyway run a test tomorrow on RPi2 and will try it, however in case would be nice.

[midwan]

@MichaIng
Regarding your questions:

• Amiberry doesn't look for libraries in any specific path, it depends on the system for that. Specifically, for SDL2 it will use the sdl2-config tool to discover the installed location for SDL2 includes and libs (using sdl2-config --cflags --libs will give you that). This happens in the Makefile when compiling, when it runs it just expects the libs to be available in the system "somewhere".
• There's no reason not to have them as shared libs IMHO, as long as you have them compiled with all the necessary flags. If you want, you could only enable KMSDRM for example, and leave everything else to their defaults.

[MichaIng]

@midwan

There's no reason not to have them as shared libs IMHO, as long as you have them compiled with all the necessary flags. If you want, you could only enable KMSDRM for example, and leave everything else to their defaults.

To keep the install slim (and as tailored for Amiberry as possible), I like to compile SDL2 with as least libraries/dependencies as possible. This also minimises future issues like the initial one with libstdio6.1/7.0 as reported originally, it allows me to remove X11 dependency from our code as well, which I find strange to have, since the idea is explicitly to run it outside of X11 and we do not even ship an X11 binary.

But this as well limits the use for SDL2 for other things, e.g. running stuff from desktop or via OpenGL etc. This is fine IMO since at least within DietPi-Software Amiberry is the only software title where we pull SDL2 for and even created the related separate SDL2 install title for, I guess. However it might cause problems if users install SDL2 via DietPi-Software for other use cases and just find it not working to start things from/within X11 session, with PulseAudio, OpenGL or other things that one usually expects. So in such case I prefer users to install the official package from Raspbian/Debian repo to avoid confusion. Our SDL2 build should then either be not shared, or if so, it should be clear that it is a KMSDRM-only +ALSA-only build, tailored for Amiberry.

[midwan]

Yeap, OK. Makes sense then. :)

[MichaIng]

First commit to remove SDL2 as separate install option: 1df744c

However some things to do:

• Asus TB build was done with X11. Does it not support KMSDRM? Could be tested with the new drivers from Buster repo that require testing anyway: Asus Tinker Board | GPU acceleration drivers #3094
• Without GPU support, I guess Amiberry for ATB does not make much sense and we should only ship both together (Amiberry only with GPU acceleration enabled and hopefully KMSDRM support)?
• Our previous ARMv6 SDL2 build seems to have been without KMSDRM but --enable-video-rpi instead. Any reason or known that RPi1/Zero does not support it? Damn thing that I have non here for testing...

[midwan]

• Yes, the ATB also supports KMSDRM normally. We have instructions on how to build SDL2 and everything for it on a dedicated wiki page (https://github.com/midwan/amiberry/wiki/Compiling-for-the-Tinker-Board). It's based on the Armbian distro there, but the SDL2 steps are identical.
• Without GPU support, it will be terribly slow I'm afraid. That's why we used the Armbian distro there, with some manual steps. I believe it requires both a kernel and the extra drivers to get it to work.
• It should also work there, perhaps it was missed? I have a few Zero devices lying around to test with, but it will probably take me some time to get something ready to test on my side (have a few things planned this week, including a trip).

[MichaIng]

@midwan
Fantastic to have this official RockChip maintained packages, which work for Stretch as well. Never saw this GitHub repo. I am wondering if/which are the differences between them and the ones from the Debian Buster repo https://packages.debian.org/buster/mali-t76x-fbdev-driver and also if the different versions (fbdev, x11, wayland) exclude each others use purpose: https://packages.debian.org/buster/libgles2
A closer look reveals that the RockChip-provided packages include libgbm => libMali symlinks, while on Debian Buster these are only provided by the wayland-specific driver package: https://packages.debian.org/buster/armhf/mali-t76x-wayland-driver/filelist
This matches that those are the only ones which provide the (thus fulfil dependencies on) libgbm: https://packages.debian.org/buster/libgbm1

If those drivers indeed work well on Stretch and Buster (which can be derived from the Stretch-specific commits done), actually I tend use them throughout our Rockchip boards. The general issue is the same for all of them that on Stretch special drivers need to be found/compiled and on Buster support is limited and provided only through above linked three different packages (each chip) that seem to not support all use-cases (fbdev vs X11 vs wayland).

Our ATB image is based on the same ARMbian image btw, so kernel should be fine.

[midwan]

@MichaIng
Not sure if this is the best place to mention this, so let me know if I should move it into a new issue?

I'm planning a code freeze for the current BETA version, and moving towards the final stage before the next stable release. Namely the sync with the various distro maintainers to ensure a smooth upgrade.

I have a list of things that you should be aware of, should I post them here or in a new issue instead?

[MichaIng]

@midwan
New issue would be good, as I want to release v6.26 probably tonight and close all related issues.