OrangePI Club
Amiberry CPU turbo/fastest mode does not work properly - Printable Version

+- OrangePI Club (
+-- Forum: International (English) Forums (
+--- Forum: *nix Distro (
+---- Forum: RetrOrangePi v4.3 - go to (
+---- Thread: Amiberry CPU turbo/fastest mode does not work properly (/showthread.php?tid=3273)

Amiberry CPU turbo/fastest mode does not work properly - klaute - 10-27-2019


as mentioned here
The "fastest" / "turbo" CPU-speed option does not work properly in amiberry.
I have verified that some of the misbehavior described by the table shown at the link above, also happen in the RetrOrangePi version of amiberry.

Example configuration:
Amiga A4000
68040 CPU ("turbo" mode & FPU internal)
AGA chipset
2MB fast chip RAM + 8MB Z2 fast RAM

SysInfo results:
17633 Dhrystones (18.40 Mips)
CPU/MHz "68040 1" (I'm not sure about whats the meaning on the number 1 here)

My OrangePi One ARM CPU is mostly idling during the speed test,
I think the maximum emulation speed could be fixed by software.

I know it's already fast for a amiga system, but it looks like that a hardware accellerator like the Vampire 500 II+ are still faster.

I want to see if I can fix it. At the amibian distribution ( it semes to be working.

I tried to compile it from source, using on my Orange Pi One system,
but i can not install the required "-dev" armbian packages.

Please see screenshot [attachment=324]

Any suggestions? Has anyone of you noticed the same behavior?

Thank you!

RE: Amiberry CPU turbo/fastest mode does not work properly - klaute - 11-02-2019

In the Last days i tried to get amiberry compiled on my OrangPi one .

At first in updated and installed all the obviously required packages.
Second I set the PLATFORM variable to „orangepi-pc“, because there is no OrangePi one support implemented in the file.

After a while of try and error I got a OrangePi-pc binary, but it does not work. The commandline help „./amiberry —help“ shows the expected message but if I replace the original installed amiberry with my files, the emulator does not open. No error message, nothing. Not even a black screen. It crashes before it could open graphics.

After I rebooted my system the EmulationStation also got a problem, it won’t start anymore because of SDL problems opening a context. I updated and installed a lot if SDL related packages, no wonder about that...

Maybe there are more settings to be applied to get the emulator compilation to work. 
It‘s very interesting to figure out all the stuff by myself, but I want to spend time in fixing some amiberry bugs, and not into fix the build script and environment.

Does anybody know how amiberry got build correctly for the OrangePi-pc platform?

Thank you!

RE: Amiberry CPU turbo/fastest mode does not work properly - alexkidd - 11-03-2019

Things to do:

1. unhold a couple of packages (those packages are likely to break other stuff, be aware):
sudo apt-mark unhold libegl1-mesa-dev libgles2-mesa-dev

2. install a couple of packages:
sudo apt-get install libsdl2-ttf-dev libsdl2-image-dev

3. make sure SDL2 headers are found:

sudo cp -rv /usr/include/SDL2 /usr/local/include/

4. force platform amiberry retropie script:
sudo nano /home/pi/RetroPie-Setup/scriptmodules/emulators/

function build_amiberry() {

#    local amiberry_bin=$(_get_platform_bin_amiberry bin)
  local amiberry_bin=amiberry
#    local amiberry_platform=$(_get_platform_bin_amiberry platform)
  local amiberry_platform=orangepi-pc
  make clean
  CXXFLAGS="" make -j4 PLATFORM="$amiberry_platform"
  ln -sf "amiberry-$amiberry_bin" "amiberry"

5. install dependencies and fetch Amiberry sources

sudo ~/RetroPie-Setup/ amiberry depends
sudo ~/RetroPie-Setup/ amiberry sources

6. make your magic on Amiberry sources:
cd /home/pi/RetroPie-Setup/tmp/build/amiberry

7. compile amiberry

sudo ~/RetroPie-Setup/ amiberry build

8. copy result binary to Amiberry folder

sudo cp -v /home/pi/RetroPie-Setup/tmp/build/amiberry-orangepi-pc /opt/retropie/emulators/amiberry/

NOTE: tested on Orange Pi PC Plus, 1GB RAM.  I've had issues with 512MB boards before (with older UAE4ARM), so consider adding swap memory as RAM is probably an issue here