Help building AmiBerry - the Amiga emulator for ARM

[nexus4]

Hey good people,

Could someone please help build https://github.com/BlitterStudio/amiberry for SFOS? It only has a few dependencies (SDL2, flac mpg123 libmpeg2-4) and I’ve successfully built it on “normal” Linux systems (raspberry os, ubuntu, etc) where a simple make command did it all, but I just don’t know how to build it in Sailfish SDK…

Could someone please be kind enough to post a step-by-step guide for such a Salfish OS newbie as myself to go though this SDK maze and build this kind of project? It would also be a great tutorial helping to build such stuff myself in the future…

Amiberry is a great Amiga emulator, very fast and highly optimized for ARM. There are no other emulators available for SFOS and the Android ones all are more or less flawed…

Thank you!

[nephros]

Well, I’ll try

https://build.merproject.org/project/show/home:nephros:devel:games:amiga

Just a note in advance: SDL apps usually do run and display something on SFOS, but generally require modifications to deal with the Lipstick/Wayland situation, and the way UI/input is done on SFOS.

I am not equipped to do anything but maybe getting it to compile, someone else will need to pick up from there.

Speaking of which: in case anyone is in the mood, I have built two other nice things successfully, both run fine but they are not really usable on SFOS without SDL-related tweaks (mainly reolution/scaling and fullscreen/orientation for wayland), and perhaps an UI:

• Dune Legacy, remake of the original TBS game (careful when trying that one, if you close it it will happily continue to run in the background, even outputing sound, and eat your battery. kill it with kill -9.)
• GemRB, engine to play Baldur’s Gate and friends.

Sorry for the shameless plug, but both kinda fit the Amiga topic

[nephros]

Well, that wasn’t too hard. It compiles, RPMs should be available soon.

In the mean time, y’all can start dumping kickstart ROM files from your original Amigas so you can legally run this…

[Inte]

That’s amazing! Rick dangerous calling:)

[nephros]

I tried to build xrick as well but failed I do have a xrick sound theme though

(I won’t publish it though, as ownership/copyright of the game assets is unclear.)

[wetab73]

Wow, amazing! I am a former long-time Amiga user, so I’ll love to have this on my SFOS phones, even just to watch from time to time some of those fantastic Amiga demos

I’ve just installed it (for this I needed to find and manually install some other libmpeg2 version containing mpeg2convert.so that the amiberry binary was demanding) and it does start, but unfortunately the GUI opens in portrait (and apparently with a hardcoded 800x600 resolution) which makes it so tiny that it is completely illegible even on the XA2 Ultra’s huge screen, and also there seems to be a problem with touch recognition (maybe resulting from that wrong hardcoded screen mode) as the GUI reacts to touch in a different place than tapped (few of the upper menu options can be selected by tapping half of the window lower, and the lower ones as well as the buttons on the bottom are not reachable at all).

If started without GUI by feeding the necessary options (model and kickstart 1.3 location) from the command line, it only opens a black screen whereas there should be a white “hand with disk” screen shown… But maybe it takes giving it the correct screen mode to use via the -O command line option.

So it needs some tweaking when it comes to screen modes it uses. Sadly, I know absolutely nothing about SDL. Hopefully someone will be able to do it as it would be really neat to have Amiberry on SFOS!

[nephros]

@wetab73

(for this I needed to find and manually install some other libmpeg2 version

You can use the one just beside the amiberry build here: Show home:nephros:devel:games:amiga / libmpeg2 - SailfishOS Open Build Service

@wetab73

but unfortunately the GUI opens in portrait (and apparently with a hardcoded 800x600 resolution) which makes it so tiny that it is completely illegible even on the XA2 Ultra’s huge screen, and also there seems to be a problem with touch recognition

… which is precisely what I meant by my comment above. Most (all?) SDL programs have this or similar problems.

Also, they almost all expect proper input devices (buttons, keyboards) so are usually only usable with an external keyboard and maybe even mouse.

But hey, it’s a first step!

[nephros]

I’m tinkering a bit with the packaging, trying to set some of the options so you may see updated RPMs you might want to check out.

The newer RPMs install all the data into /usr/share/amiberry, but will be configured to use $XDG_CONFIG_HOME/amiberry ( $HOME/.config/amiberry) for config and $XDG_DATA_HOME/amiberry ($HOME/.local/share/amiberry) for the other files, with recordings and screenshotes in ~/Music and ~/Pictures.

But all this is not finalized, things will change around a bit.

[nephros]

@wetab73

If started without GUI by feeding the necessary options (model and kickstart 1.3 location) from the command line, it only opens a black screen whereas there should be a white “hand with disk” screen shown… But maybe it takes giving it the correct screen mode to use via the -O command line option

For now I use this to launch it:

/usr/share/amiberry/amiberry -r $PWD/KS-ROMs/'Kickstart v1.2 rev 33.180 (1986)(Commodore)(A500-A1000-A2000).rom' -model a500 -o rotation_angle=270 -o default_line_mode=2 -o default_fullscreen_mode=2 -o write_logfile=yes -o logfile_path=/run/activeuser/amiberry.log  data_dir=/usr/share/amiberry/data/ -G -0 ~/Arkanoid.adf

-G skips the GUI, and the rotation and fullscreen options put it into landscape fullscreen mode. It’s fun, didn’t try any interaction though.

===
EDIT:

Okay, build amiberry-5.4-1.25.1 (and above) looks decent now.

/usr/bin/amiberry is my wrapper script which you can look at here. If you want to launch pure amiberry, call it from /usr/share/amiberry/amiberry.

With the wrapper, a call like this works for me:

amiberry -r '/home/nemo/.local/share/amiberry/kickstarts/KS-ROMs/Kickstart v1.2 rev 33.180 (1986)(Commodore)(A500-A1000-A2000).rom' -model a500 -0 '/home/nemo/Downloads/amiga/demos/1000 Wasted Dreams (1991-10-19)(Panic).adf'

Take good care about quoting, use full path names and avoid shell characters (e.g. ~) for best results.

[poetaster]

GitHub - sailfishos/sdk-sdl-project-example: Example project for building an SDL2 application in Sailfish SDK (Qt Creator) might be helpful, too.

Just a quick note, take a look at input handling in the code. It’s very likely not going to deal with touch input in a reliable way, if at all. @sashikknox has some experience in this domain.

[nexus4]

Thank you! Could you describe how to build it in the SDK?

[nephros]

I can’t because I’ve never used it. There’s Jolla docs about this though.

[poetaster]

That’s the link to the example from jolla that I posted above. It’s not trivial though since you have to use custom build/clean/run steps. I’ve also just tried it (it did work in 4.3) and the opengl example doesn’t render.

[poetaster]

@nephros

GemRB, engine to play Baldur’s Gate and friends.

Just saw that you have the rotation patches and touch position patches in place. Do they work?

[wetab73]

@poetaster

It’s very likely not going to deal with touch input in a reliable way

I’ve just installed some Amiga emulators for Android from Google Play store and at least two of them (Uae4All2 and Uae4Arm) are also SDL2-based. Both have an SDL2-based GUI (and Uae4Arm GUI is identical as in Amiberry) and their SDL GUIs are working OK, i.e. good screen mode, autorotating and can be normally controlled with touch.

The emulation itself also has the right screen mode (autorotates, fills the display in landscape) and even touch works ALMOST fine - i.e. the pointer on Amiga Workbench can be controlled via touch screen, it’s just that there is a large discrepancy when it comes to coordinates - the pointer moves much faster than the finger, so I guess it needs some tweaking. But other than that, even click and double click work OK to the point that even in Workbench you can click icons, open folders, etc.

The following are screenshots from Uae4All and Uae4Arm for Android running on the 10 III.

So maybe both being SDL based and working almost OK, they could be helpful in tweaking Amiberry GUI and touch control?

GitHub - lubomyr/uae4arm: amiga emulator (android port)

GitHub - lubomyr/uae4all2: A fast and optimized Amiga Emulator

[poetaster]

Ah, thanks, that’s great to know. I just noted some odd behaviour in the sdk example I posted about (really delayed input handling) and @nephros appears to have patches, but I’m pretty sure that godot uses SDL2 for input and, albeit odd, I’ve gotten accurate (well, finger dependant!) position info in godot. I’ll go have a look at those android ports. Thanks!

[nephros]

Nope unfortunately not.

I think the coordinates one actually messes things up, as I was able to interact with the demo at one point but can’t in the current build.

[wetab73]

Having played with both those Android Amiga emulators some more, I’d say that when it comes to screen mode and touch control they are ALMOST OK, the only problem being the inaccurate touch coordinates (the distance of the finger movement is translated into a much bigger distance of pointer movement). Other than that they’re OK if we don’t count some Android-related glitches like for example no access to folders outside of android_storage (I guess that Android permission to access external storage is missing) and things like that.

When it comes to speed, I launched SysInfo in Android’s Uae4All2 running on 10 III with 030 CPU, JIT and “fastest possible” options and I got 26 times the speed of Amiga 4000

However, when it comes to actual performance under load (e.g. when running demos fully utilizing the Amiga chipset - simultaneous graphics, music, etc.) while on the 10 III it is sufficient (relatively smooth), on the XA2 Ultra in horizontal mode (when the screen fills the entire display) it’s jerky and sound stutters a lot and only gets OK if switched to portrait where the emulated display is small.

So I guess that native Amiberry might deliver a much better performance given its advanced ARM optimizations.

[poetaster]

@wetab73

(the distance of the finger movement is translated into a much bigger distance of pointer movement).

I had to jump through quite some hoops to translate coordinate reading from mouse to touch based input in godot. I’m going to do some tests with Decker and the old sdk sdl example to see if I can find a good method in ‘plain’ sdl.

@wetab73

26 times the speed of Amiga 4000

I’m so old now, I can barely keep up with my mac classic Sadly, I’m going to have to fix it first (was working the beginning of last year!). So, for now, being slow is not a disadvantage

@wetab73

it’s jerky and sound stutters a lot and only gets OK if switched to portrait

These things can be fixed but it’s quite a bit of tweaking. off to debug.

EDIT: Thanks for sharing!

[poetaster]

Just a note: sdk-sdl-project-example/common.cpp at master · sailfishos/sdk-sdl-project-example · GitHub

produces (some code in the sdltest.cpp iteself) accurate touch input feedback. BUT, it uses opengl so that’s not really appropriate for the general case. Sadlly, it no longer renders any thing.