Amiberry: a WinUAE-derived Amiga emulator with its own JIT

What Amiberry keeps from WinUAE and what it adds

Amiberry describes itself as an optimized multi-platform Amiga emulator, and the README places it firmly in the WinUAE lineage: it is built on the WinUAE emulation core. That inheritance is the point of the project, not a limitation to apologise for. Core compatibility work for a machine like the Amiga is enormous, and starting from an existing core means the effort goes into the parts a user actually feels, which are speed, interface and packaging. The project describes full Amiga compatibility across ARM, x86, RISC-V and LoongArch64 hardware, from a Raspberry Pi to a desktop workstation. The additions listed on top of that core are concrete: a custom JIT compiler for ARM64 and x86-64, WHDLoad support that launches hard disk titles with automatic configuration, custom monitor bezels and GLSL shaders, a Dear ImGui interface, drag and drop of disk images, an update checker that verifies downloads with SHA256, and controller mapping that suits RetroArch setups.

A JIT written for ARM64 and x86-64 specifically

The custom just-in-time compilation is what separates Amiberry from a straight build of the upstream core, and it is aimed at the two architectures that matter most in practice: ARM64 and x86-64. On a Raspberry Pi, a phone or an ARM workstation, the emulator is translating 68k instructions rather than running native code, so a compiler that produces tight ARM64 output is the difference between an emulator that stutters and one that does not. The same reasoning applies to x86-64 desktops, and the coverage extends beyond those two: builds exist for RISC-V and LoongArch64 as well, even though the JIT work is described specifically for ARM64 and x86-64. The AppImage naming makes the hardware split visible in the file names themselves, with separate builds for Intel and AMD and for 64-bit ARM.

Dear ImGui, drag and drop, and controllers that suit RetroArch

The interface is a modern Dear ImGui one, and the README makes a point that matters to a lot of people: it is navigable by mouse or gamepad. An emulator whose settings can only be reached with a mouse is awkward on a television, and the gamepad support is what makes a couch setup bearable. Files can be dropped straight onto the running emulator, and the drag and drop covers floppy images, hard files and configuration files rather than only disk images. The RetroArch angle is separate but related. The repository carries a libretro directory, and RetroArch ready controller mapping is listed as a feature, which means the same emulator can be driven from a frontend that already handles controllers, saving on a second configuration job. A user with a controller already mapped in RetroArch has a reason to prefer that route over running the standalone GUI.

Bezels and GLSL shaders for a period-correct look

Two of the more distinctive features sit in the presentation layer. Custom bezels put a CRT style monitor frame around the emulated screen, and shader support adds GLSL effects to the same output. They are not the reason to install an emulator, and the README presents them as part of the experience rather than as a technical centrepiece. They matter, though, for anyone who grew up with a CRT and wants the geometry of that display rather than a flat rectangle. The combination is a presentation layer that lives in the same process as the emulation, so a shader can be applied to the output without a separate capture and re-encode step. The screenshots in the project documentation show a CRT shader paired with a monitor bezel, which is the combination the feature set is built around.

Linux installs: script, repositories, Flatpak and AppImage

Linux is the platform with the widest set of choices, and the quickest route is a shell script that adds the project repository. The README gives the install as a two step command, and the second line is an ordinary package install:

curl -fsSL https://packages.amiberry.com/install.sh | sudo sh
sudo apt install amiberry

Beyond that, the project publishes a PPA for Ubuntu, a COPR for Fedora, a Flatpak, an AUR entry, and .deb and .rpm files on the releases page. If you would rather install nothing at all, each release ships an AppImage, and the naming tells you which CPU it is for:

chmod +x Amiberry-<version>-x86_64.AppImage
./Amiberry-<version>-x86_64.AppImage

There is a floor under that option: the AppImage needs glibc 2.35 or newer, so Ubuntu 22.04 or later, and the project documents a way to run it without FUSE, keep data beside the image and manage updates.

macOS, Windows and the portable marker on Windows

macOS installs through Homebrew as a cask:

brew install --cask amiberry

Windows users pick between an installer and a portable ZIP, and both x64 and ARM64 builds are published, the latter covering Windows on ARM machines such as Snapdragon X hardware. The portable ZIP carries a marker file named amiberry.portable, and its only job is to tell the emulator where to write: writable paths stay next to Amiberry.exe with no extra configuration. One documented failure mode deserves a mention. Running the ARM64 build inside a VMware Fusion, Parallels or Hyper-V guest usually fails at startup, because the guest has no OpenGL ICD and the GL initialisation dies. Dropping the Mesa3D opengl32.dll, from the mesa-llvmpipe-arm64 build, next to Amiberry.exe supplies software OpenGL 3.3 and the interface comes up. Native Windows on ARM hardware does not need that workaround.

FreeBSD packages, and the Android release that is not public yet

FreeBSD is served from the package repository with a single command:

pkg install amiberry

Each release also ships versioned packages for FreeBSD 14 and 15 on both amd64 and aarch64, and those can be newer than the ports tree, so a specific file is installed directly:

pkg install ./amiberry-v8.4.2-freebsd15-amd64.pkg

Those packages are built against the quarterly branch, which is the FreeBSD default; on a system tracking latest, a dependency can have moved to a newer library version, and the ports package is the fallback. Building from source is a ports tree operation:

git clone --depth 1 https://github.com/freebsd/freebsd-ports /usr/ports
cd /usr/ports/emulators/amiberry
make install

Android is the platform where the release process is still incomplete. The app is in Closed Testing on Google Play for Ko-fi members, who receive a 100% discount code that also covers the final release. Open Testing is planned after the next release, and a public paid release on Google Play comes after that. The Android build covers AArch64 and x86_64 with full ARM64 JIT support.

One maintainer, signed binaries and a sponsorship model

The README is unusually direct about the project's structure: Amiberry is maintained by a single developer, and the features and platforms exist because of community and corporate support. For a user that means a different risk profile than a project with a broad contributor base, and it is also why the project asks that anyone shipping a commercial product, a paid subscription service or a hardware bundle with Amiberry in it support the project financially. The sponsorship tiers run from named supporter status to partner status with early release access and a certified partner badge. Release binaries are signed through SignPath, and the code signing policy covers signing scope, release approval roles and privacy notes, which is the part a distributor building an image or a bundle needs to look at.

Editorial conclusion

Amiberry fits an Amiga owner who wants a native build with real JIT on a Raspberry Pi or a modern desktop, and who values a GUI, shaders and packaged updates more than the smallest binary. It does not fit a macOS or ARM64-on-Windows user who expects zero setup, and the Android route is closed to anyone outside the Ko-fi cohort for now. Before you install, check the release assets for your CPU and OS, and on a Windows ARM64 virtual machine plan on dropping the Mesa3D opengl32.dll next to Amiberry.exe.

Frequently asked questions

Official sources

1. BlitterStudio/amiberry on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases