Search results

I created a repository with the source code of UAE4ARM on GitHub (https://github.com/PandTomB/uae4arm). There are all release and beta versions available and also contains new stuff for the RaspberryPi port. These changes will also become part of the Pyra port, when I get my device.

I updated UAE4ARM in Repo, not UAE4All. If there are no errors reported to the new build UAE4All, I will put it in Repo.

So here is the version compiled with GCC 7.2 and profiler.

You find the new build here: https://pyra-handheld.com/boards/threads/uae4all-2-0.67021/page-9#post-1421867

mamemanic wanted a version compiled with GCC 7.2. Here it is. If there are no problems with this version, I will compile one using the profiler for better performance.

I'll try...

There is a new version of UAE4ARM in Repo. The performance we lost by newer code from WinUAE was compensated by using GCC 7.2 with profiler. So the Pandora is still fast enough for this version. Changes since last release (2016-09-24): - Merged lot of changes from WinUAE 3.5.0 - Added panel...

Here is another beta of UAE4ARM. In this version, I merged lot of changes from WinUAE 3.5.0. Thanks to GCC 7.2 and the profiler, we have same or better performance than latest version in Repo. So after some more testing, I will create a new release version for the Pandora. Notes: - Statefiles...

To use controllers on Android, you have to ask the porter of uae4arm to Android to fix this. The core can handle any controller provided by the host specific code. I can´t do any changes on the Android specific code to fix your problem. Sorry.

I don't have any controller I can connect to the Pandora. So i can't see what happens and figure out what to do to fix it.

I don´t expect any performance difference between the last two versions.

Here is a new version with following changes: - Fixed loading new config (now using same method like WinUAE) - Display message instead of crash in some situations - More cleanup of threads/pipes/mutex Regards, TomB

In WinUAE, at each display line, several variables are checked and updated to get the first and last output of the line. With these values, center_image() in display.cpp does the centering and somewhere else is the automatic screen mode change.

I never heard about this. Maybe I find some time to look at it.

Using the automatic size and center mode of WinUAE will slowdown emulation. This is the why it's not part of UAE4ARM. I will merge the code of the raspberry-pi version and android version into this code. It's already on my list.

Here is a new beta version of UAE4ARM. My first intention was to get closer to WinUAE as a preparation for a new version for the Pyra. The Pyra has more cpu power, so I can add more features from WinUAE and all stuff is still fast enough. Now I have a version which is about 10% slower than the...

I used crosstool-ng (http://crosstool-ng.org/) to setup my environment on Ubuntu. I can post my configuration file, a few patch files and a short description how I used this to create my toolchain with GCC 6.1 when I'm back home again.

We need cycle exact blitter and cpu emulation for this game. If you select immediate blitter, the flickering is gone, but the animations are too fast.

The Pyra will have a 1.5 GHz dual core CPU compared to a single core 1.0 GHz CPU in the Pandora. So there is more CPU power available and we will get more features from WinUAE in UAE4ARM. I don't know what exactly will be possible, so I can't promise anything. When I get my Pyra, I continue to...

There is a new version in Repo. Changes since last release: - Merged lot of changes from WinUAE 2.8.1 - Fixed graphic glitches caused by borderblank - Fixed bug in navigation through quit button - Keys V and W were switched - Compiled with gcc 6.2 Maybe this is the last version for the...