Amiberry: Amiberry Android & UAE files

[ransom1122]

Hi

The big question on everyone's lips is...

1. Does anyone know when the android port of Amiberry will be released? Who is working on it?

2. Wil UAE files from older version of Amiberry on Raspberry Pi or UAE4ARM (Android) work on the new version of Amiberry on Android?

If not... Would it be possible to batch edit uae config files from a previous Amiberry version with a text editor for compatibility with the (when released) Amiberry for Android.

Thanks for your time...
Ransom

[midwan]

@ransom1122
There is an Android target already in the Makefile, both for SDL1 and SDL2. I tested compiling it all the way to an .apk and wrote a guide about that, but I haven't run more tests with it yet.
This is certainly something that needs a bit more attention, before the next release (the aim is to release binaries as well, so they should be working as expected).

Regarding the config files, older configs will work in general (some options no longer exist though, so those will be reverted to their defaults), though I'd be happier if we test this area more, before the release. Samples of config files that cause problems (if they do) are welcome, so we can study them and provide a solution.

[thatman84]

FYI I know it's a bit early for an Amiberry compatibility sheet but I am preparing one in readiness as there is plenty to fill out in the mean time for Hyperspin related stuff. It would be a Shield TV focussed sheet but I can test on an S7 also.

It would be awesome to collaborate and have maybe a second page for the Pi compatibility also. Keep everything in one place.

No pressure here UAE4arm and UA WHDLoad is doing a good job right now

[midwan]

I have a Shield TV and a few Android platforms to test with here, as well.

[thatman84]

I recently started to learn a bit of Android Studio when an OpenBOR issue popped up.

I intend to continue learning Android development in the futire for emulator purposes but all the guides and stuff are geared at making new apps :(

What build environment do you use for this project?

[ransom1122]

Can we test out the alpha apk on our Shields at all? Possibly testing out the transition of raspberry pi configs to android?

Where is this guide you wrote about?

There are more then enough people to help test out this alpha apk and submit issues for you if required..

[midwan]

I'll post the guide to a page in the Wiki, where it belongs :)

I used a Linux VM (Ubuntu-based, 64-bit) to install the JDK and Android Studio, then compile the emulator and use Android Studio to build the apk...

[ghost]

I'm also interested in this Android version mainly because of the huge speed advantage and it can be made portable to some extent. I know the "old" Android version had a basic built-in keyboard, I assume this will no longer be a feature ?

[midwan]

@blinkydoos All of the extra features from Lubomyr's version are included actually. :)

[ghost]

That's great to here. It would be even better if the built in keyboard had the same keys and layout as a real Amiga because I remember there being a lot of keys that weren't even needed and you had to hunt out the exclusives like 'Help' and the 'Amiga' keys but this is way into the future !

[ransom1122]

@midwan
Thanks for the reply you have many people excited for the release. All the best..

[thatman84]

Great stuff @midwan

Hope the release goes smooth for you.

So VM is next on my hit list for tinkering :)

[midwan]

Sorry this is taking longer than expected :)

I have been checking the different ways of doing it, so we can document the preferred/best way depending on complexity, ease of use, etc.

The "classic" approach of using the instructions from Lubomyr's repo, does work with his source code.
There are other ways to do it also:

• Using just the command line on a Linux VM, following SDL2's Wiki official instructions (https://wiki.libsdl.org/Android)
• Using Android Studio, following a guide found here: http://lazyfoo.net/tutorials/SDL/52_hello_mobile/index.php
• Using Visual Studio, following a guide found here: http://trederia.blogspot.de/2017/03/building-sdl2-for-android-with-visual.html

I didn't have enough time to test all of the above yet, making sure it works from start to end. I did test the Android Studio approach up to the point of generating an APK from a C++ "hello world" application, but I wanted to see how we handle external dependencies beyond that (e.g. libraries besides SDL itself).

Probably the Android Studio approach will be the most attractive one, because it's multi-platform. Personally I'm more experienced in Visual Studio, so I'll give that a try as well (no harm in having more than one way of doing things). The plan is to document the approach in a Wiki article, so anyone can follow it and set it up.

If anyone wants to go ahead and start documenting something in the meantime, feel free to do so. It's a collaborative effort anyway, we can help each other :)

Also, I expect that some code changes might be needed, I've ported the Android specific stuff from Lubomyr's repo into Amiberry, but haven't really tested it in real-life yet. ;)

[thatman84]

Thanks for the update and no need to apologise it's good to know the Android side is coming along.

I am quickly realising I have a lot to learn!

3 evenings trying to get the java path to stick may give you an insight to my skill level!

I will try your other linked solutions but I expect I will need a specific Amiberry guide in the end.

Once something is fleshed out I will be a good dummy tester and help make the wiki well dummy proof :)

[ransom1122]

If Android Studio is most appealing & Visual Studio is where your most experience then its probably best you stick with only these two for now to avoid complexing things.

Thanks for the update midwan. Things are definitely looking positive going forward.

There is so much excitement in the air about this release. You should be one proud man. 👍

[ransom1122]

@midwan
I read on facebook page that the emulation core has been updated to winuae 3.6.0 core which is amazing.
Does this mean that the Android port of Amiberry will include this as well when released?

[midwan]

@ransom1122
Yes, of course. The codebase is the same across all targets ;-)

[ransom1122]

@midwan
Amazing.... Can't wait exciting times ahead... 🤗

[ransom1122]

@midwan With the recent addition of the ASUS Tinker Board will this delay the release of the Android port at all?

[midwan]

@ransom1122
No! :)
The Tinker port is done by another person, although I am helping along.
I'll try to do another test with Android Studio today and see where we are with external dependencies.

[ransom1122]

@midwan excellent work 👌

With the Nvidia Shield being way more powerful then a raspberry pi 3. Do you think new version of Amiberry on Android will have better performance over pi on games that require higher cpu performance?

[midwan]

@ransom1122
I am sure of it, and that's something I'm eager to test. :)
As I also have an Nvidia Shield at home, I'll probably be the first to test it on it...

[ransom1122]

@midwan..

Cool keep us updated..

[thatman84]

Sorry for this stupid question but it affects how I spend my evenings.

Just wondered if you could give a conservative guess at the time frame for a test apk?

If you think it could be a month or 2 I will probably find other things to work on as I could not learn enough to help out. But if its more like 6 months i could probably get somewhere with it.

I know its a how long is a piece of string question but any clue will help me plan out my free time.

[midwan]

@thatman84
Obviously it's not easy to give a proper time estimation, but if I had to guess, I'd say certainly less than 6 months ;-)
It's a slow process mostly because there's not enough free time per day. If I could spend a week of 8-hour-per-day on it, we'd be done already... But we're getting there.

[thatman84]

Thanks @midwan yeah I knew its a tough one. So many things to do and so little time :) thanks for the stab. Certainly getting there....keep it up. 👍

[ghost]

@midwan Hi, just a quick question, will the new Android version be released at the same time as the Raspberry Pi version ?

[midwan]

@ZappaUtopia probably not, unless we delay the release more.
The android version is not ready yet...

[midwan]

Now that the new version is out, I can finally focus on the Android version properly. :)

[ransom1122]

Hooray. Thanks for the announcment 😎

[thatman84]

:) :)

[Honosuseri]

Congrats on the release Midwan. I was very happy to inform my friends the day we had long been waiting for, had finally come this weekend! Thank you for all the hard work you put into this project.

We are very excited about the Android version of Amiberry. The Amiga is one of the most viewed topics in the Android section of the Hyperspin (frontend) forum. We are doing our best to do the Amiga justice on the Shield TV & show our love for the system with appropriate visual flair.

We are thankful for all the work that was done on UAE4ARM however it limits us in many ways. For example it's beta version gave us launch intent, so we can use it with frontends to showcase and launch our games. Although it's fussy how the uae's are named. Not allowing spaces in the name has confused many people, ultimately they gave up trying to use the emulator which is a shame. Least of your problems I'm sure but I wanted to bring it to your attention.

When we have Amiberry available on Android, we sincerely hope our little project will get even more people excited and bring attention to what you do. We'd like to think that maybe one day you might even use it yourself on your own Shield TV :)

Wishing you all the best

[ghost]

Gongrats on the release and another +1 for the Android version ! This will be a great portable Amiga that I can use on my GPD XD handheld when on travels. On the current Android version there is some dodgy mouse movement especially when using a joypad, it sort of gets stuck and stutters. I think this is due to SDL on Android though as it also happens a bit on SCUMMVM. I don't think SDL get's updated unfortunately (well they've yet to fix the stuttery mouse movement). Keep up the great work @midwan !!

[midwan]

It's a start at least... :)

[ransom1122]

That's just teasing now.... 😉

[midwan]

@ransom1122 that's the point...

[ransom1122]

@midwan As long as you get a smile then thats alright. 😁

[bspinner]

@midwan FYI: One thing to be considered when developing close to metal for mobile CPUs is the possibility of different cache sizes of cpu cores in big.LITTLE arch.
The Mono/Xamarin Team had a lot of fun due to this.. :)
http://www.mono-project.com/news/2016/09/12/arm64-icache/

At that point we were using our own version of this function, so we instrumented it to print the cache line size as returned by the CPU and, lo and behold, it printed both 128 and 64. We double verified that this was indeed the case. So we went to see that particular CPU manual and it turns out that the big core has a 128 bytes cache line but on the LITTLE core it is only 64 bytes for the instruction cache.

[midwan]

@bspinner holy sh*t! That's really messed up if you get into it...

[ransom1122]

@midwan

Hi.. Understand your life must be busy as hell... Thought I might ask how progress is going on the Android port at the moment of any?

[midwan]

@ransom1122
Got stuck currently, on getting everything to work properly.
I spent a few weeks of afternoons and a few weekends trying to find a solution, but didn't get too far.

[ransom1122]

I assume you haven't given up?

[midwan]

No, of course not! :)
Just taking a break from it to keep my sanity (and hair), while @bspinner is also working on it in the meantime.

[ransom1122]

Ok Thanks for the reply.👍

[bspinner]

@ransom1122 Please don't hold your breath while waiting for this. I'm invested in two other projects I'll need for my wedding, so the hair pulling adventure of setting up a Android NDK project isn't my top priority currently.

[ransom1122]

@bspinner @midwan Fully aware of how long things can take. Not a problem at all, we all just hope that this project doesn't die at any stage. All the best. 👍

[ghost]

Lubomyr has just updated the Android version with all TomB's updates (and yours). http://eab.abime.net/showpost.php?p=1230071&postcount=431 Haven't tried it yet so don't know what exactly was added. @midwan He said he disabled the JIT FPU because it crashes the app, maybe this is why you can't get the Amiberry version working ?

[midwan]

@ZappaUtopia
Thanks for the notification. I'll check it out...

[ghost]

I gave it a quick try, it seems buggy, I opened the on-screen keyboard and closed it and it locked up the app. Visually it still looks like UAE4Arm, there are no Amiberry GUI changes like the Correct Aspect feature or the Custom Controls page, but the Android version always had working custom controls so no need for that part.
On his Github page there is a part in the code about a choice of keyboard layout, Amiga, Commodore 64 and Atari 800.

[ransom1122]

Any progress or updates at all?

[ransom1122]

@Midwan

4 months have passed...without any word on Amiberry Android version...

Is there still any hope we see Amiberry on Android anytime soon?

We're all holding our breath in despair..

😑😑😑

[midwan]

@ransom1122
Don't hold your breath, this will happen eventually, but it's not top priority.

[thatman84]

That makes me sad :(

Please let me know in here when it gets a look, I get the email notifications and as I dont have a Pi or xu4 I dont really keep up with Amiberry other than facebook posts.

I really hope the other priorities get to a good enough state to drop below an Android port.

[ransom1122]

Android is one of my most use devices with my Shield TV. It is a pitty it's going to take so long.

Anyway there's 2018 knocked out of the park... Let's hope for early 2019.

[ransom1122]

@Midwan

Has the been any progress with the android port at all?

[midwan]

@ransom1122
Not yet, sorry.
I'm re-visiting this from time to time to check on the state of the tooling and environments, but I haven't really had enough time to spend on it yet.

[ransom1122]

Ok no worries. Thanks for replying

[kemppe]

Any progress with the android port? I miss playing Amiga on my Nvidia Shield now that UEA4ARM doesn´t work anymore.

[midwan]

@kemppe
I'd love to get it running on my Shield as well. :)

The main issue is lack of time to spend on this at the moment, since all my earlier attempts to do it "the right way" (i.e. using SDL2, following the official documentation) have been met with persistent refusal to work. And to clarify: the issue wasn't getting Amiberry to work, but getting the requirements for it in place (specifically, the SDL2 and other external libs).

Amiberry itself should work once those are in place, since I've already integrated lubomyr's changes some time ago.

And considering there are still a few remaining bugs I need to figure out and fix, I prefer to prioritize those when I have some time, so we can get a new stable release out. Once that is done, I can revisit this. :)

[midwan]

I managed to get the SDL2 components building correctly, which was one of the show-stoppers earlier. But there is still work to be done (the rest of the dependencies need to be added, and finally Amiberry itself). Progress is slow due to the limited available time, but it is happening.

[thatman84]

Thanks for the update 😀

[ransom1122]

We're counting on you... Thanks...

[03stevensmi]

Your doing great work midwan! We are all thankful for your time and effort! Hopefully we will get to see this soon, good luck! ;)

[thatman84]

Just checking in, been playing with my Shield again recently, UAE4arm is pretty buggy these days. Fingers crossed midwan gets some time on this.

[bspinner]

@midwan Feel free to share your current WIP state on a branch. Maybe someone can help out.

[ransom1122]

Am I correct in saying Amiberry for Android is dead?

[midwan]

@ransom1122
No, that's not correct.
The latest Android SDK requires a 64-bit binary, and Amiberry didn't have that until now.
The work being done with the latest dev brings among other things, a 64-bit version. This was a necessary step in getting the Android version moving forward.

[ransom1122]

You announced Android development well over a year ago now. Was all that time wasted as now you have moved onto the 64bit dev version?

Hopefully we can hear and see some progress soon. All the best

[midwan]

@ransom1122
It was through all the efforts made during all this time that we reached this point. So I certainly wouldn't say it was wasted. But it does require work and lots of spare time, which is hard to get if you have to balance things between work, family, and your own sanity.

[midwan]

Small update: I've got almost all of the dependency libraries compiling to an APK now, using Android SDK 26 (the minimum required from Google nowadays, for the Play Store).

So we have the following ready so far:

• SDL2
• SDL2-image
• SDL2-ttf
• flac
• ogg
• mpeg2
• xml2

Currently mpg123 does not fully compile yet, as it complains about some NEON functions. I'll need some time to get that working, and then we can add Amiberry in the mix.
The good thing is that Amiberry's code is already prepared for that, as I've merged all the changes Lubomyr had done in Uae4Arm. So I don't expect major problems when we reach that point.

More news, once I get more time to move this further. :)

[bspinner]

@midwan starting from 1st November api level 28 will be required target api.
Are those changes already on a branch?

Edit: and thanks for your ongoing efforts!

[ransom1122]

Awesome mate

[midwan]

@bspinner The code changes in Amiberry are already integrated in the dev branch, and master already had most of them. The rest of the environment is being prepared in a separate repo, but not everything is pushed up yet (only the SDL2 libs so far) until I get libmpg123 working: https://github.com/midwan/sdl2vs

Moving to SDK 28 shouldn't be a problem with this setup, so I'll do that sooner rather than later.

[midwan]

I've updated the repo with a few changes:

• Moved SDK up to 28
• Included some extra libraries (flac, mpeg2, mpg123, ogg, xml2)

libmpg123 doesn't compile properly for ARM yet, it complains about some undefined NEON specific functions. The rest of them however do compile and we can get an apk with a basic main application.

[5schatten]

@midwan
mpg123 buildlog for RPi2
https://pastebin.com/S27RYGHH

Maybe this helps? The package builds fine here with the LibreELEC toolchain.

[midwan]

@5schatten Thanks, I'll take a look.

[midwan]

Update: I've updated several things and took a new approach (compiling with Android Studio instead).
I have an APK for both 32/64-bit, targeting Android SDK 29 (Android Q). It launches, but has issues specific to Android at this point (e.g. accessing the filesystem).

Uae4Arm used some custom Java classes from pelya's commandergenius build environment, which were handling such things - but I believe those were designed for SDL1.

Need more time to work this out. :)

[ransom1122]

Hopefully things improve in your journey into Android ;)

[thatman84]

Great to see some updates over the last week or 2. Much appreciated:)

On Sat, 26 Oct 2019 at 11:21, ransom1122 [e-mail] wrote:

Hopefully things improve in your journey into Android ;)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/midwan/amiberry/issues/206?email_source=notifications&email_token=AGH47UACZUOFSYW4TAKVZFDQQQKZJA5CNFSM4ELVRVK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECKE4HY#issuecomment-546590239,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGH47UELH2HVAPWFJYESL63QQQKZJANCNFSM4ELVRVKQ
.

[bspinner]

@midwan
Are you willing to share your current state of the android stuff?
I'd like to tinker around with it and see if I can be of any help. :)

[midwan]

@bspinner
The current state is already in the Amiberry code - I don't have anything hidden away :)

I just use a standard project in Android Studio, including all the dependency libraries and Amiberry, starting from the default SDL2 Android project template.

But like I mentioned above, although this creates an APK successfully, it will fail as it starts up (e.g. when trying to access the filesystem on startup). We need Java code to "glue" this to the Android system, similar to what uae4arm uses (which unfortunately, is SDL1 only).

[bspinner]

@midwan

Thanks. I was able to create an android project yesterday and do some investigations today.
I think it might be smart do handle some stuff in Java/Kotlin instead of C++. Especially thinking of #241 :)

I'll try to come up with some solutions.

[bspinner]

@ransom1122 Feel free to create an issue related to "Import of existing UAE configurations" here https://github.com/bspinner/amiberry-android :)

[midwan]

I think we should close this issue since the project is alive on a separate repo now...

Until we have a stable version out, all Android related issues should be opened at https://github.com/bspinner/amiberry-android