There is a particular satisfaction in booting an old PC, plugging in a controller, and watching it become a fully functional arcade cabinet within sixty seconds -- no driver hunting, no configuration files to wrestle with, no desktop environment standing between you and the game. That is the promise of Batocera.linux, and it is one the project delivers on more reliably than nearly any alternative.
But Batocera is more interesting than its elevator pitch suggests. Underneath the polished EmulationStation frontend and the plug-and-play controller mapping sits a carefully constructed embedded Linux system, a decade of engineering decisions, and an active open-source community that ships updates at a pace that would embarrass some commercial projects. This article covers all of it. If you want a broader picture of where Batocera sits within the wider ecosystem first, our gaming on Linux state of the union covers the full landscape from native titles to emulation.
What Is Batocera.linux?
Batocera.linux is an open-source, completely free retro gaming Linux distribution designed to be written to a USB stick or SD card and booted directly on a target machine -- permanently or temporarily -- without requiring any modification to the host system.
What distinguishes it from simply installing RetroArch on Ubuntu is the philosophy of the entire system. Batocera is not a set of emulators you install on top of a general-purpose OS. It is the OS, purpose-built from the ground up for one task: running games. There is no desktop environment, no package manager meant for end users, no layers of abstraction that were designed for something else. The kernel boots, EmulationStationBatocera's graphical frontend. Organizes your game library by system, handles scraping artwork, and launches emulators. Batocera maintains its own fork with deeper system integration than the upstream project. launches, and you are already playing.
Batocera does not distribute ROMs or BIOS files, and it explicitly asks users to own the games they play. The project itself is entirely legal -- it ships emulators, not game data.
Origin and History
Batocera's lineage is traceable. According to HandWiki's software archive, Batocera.linux was originally forked from Recalbox in 2015 by the original development team. It was initially developed under the name "recalbox.remix" before the project established its own identity. The first official release shipped on December 26th, 2016, supporting only x86_64 architectures, Raspberry Pis, and a handful of Odroid single-board computers.
That first release was modest in scope. What happened next was not. Over the years following that initial launch, the project expanded hardware support to more than 45 distinct architectures, absorbed community contributions from developers worldwide, and built out a wiki and Discord server that now serve as the primary support and documentation infrastructure. By the time version 40 arrived in August 2024, Batocera was supporting handheld gaming consoles like the Anbernic RG series, ARM boards, Android TV boxes, and the Steam Deck alongside traditional x86 PCs.
The GitHub repository captures the core intent plainly: Batocera is an open-source, free retro gaming distribution designed to be copied to a USB stick or SD card, turning any compatible computer into a gaming console without requiring any modification to the host system.
How It Is Built: The Buildroot Foundation
Understanding Batocera properly means understanding BuildrootA build system that cross-compiles an entire Linux system — kernel, libraries, utilities, and applications — for a specific target architecture, producing a compact self-contained image. Used by Batocera to produce every architecture image from a single codebase.. The official Batocera architecture documentation describes this directly: Batocera.linux is based on Buildroot, which should be understood as a minimal Linux distribution that maintains base packages with a focus on firmware for embedded systems. Buildroot cross-compiles an entire Linux system -- kernel, libraries, utilities, and applications -- for a target architecture, producing a compact, self-contained image.
This is a deliberate and consequential choice. Batocera is not Ubuntu with emulators installed. It is not Debian with a custom shell script. It is a from-scratch embedded Linux build that includes exactly what it needs and nothing more. The result is a system that boots in seconds, has minimal attack surface, and behaves identically across every installation.
batocera-emulationstation on GitHub — adding per-system emulator switching, RetroAchievements integration at the OS level, Batocera Store access, and tighter control over the controller-first navigation model. It is the only process the user directly interacts with; emulators launch as child processes and return control to it on exit.The Batocera source repository on GitHub reflects this structure clearly. The project separates its components into distinct directories: buildroot (the cross-compilation toolchain), package (the "meat and potatoes" -- emulator data, config generators, core packages, and system utilities, handled primarily in Python and Makefile), configs (build flags per architecture), board (platform-specific patches), and scripts (external tooling for the compatibility reporting system and Bezel Project).
Partition Layout
When Batocera writes to a drive, it creates two partitions. The boot partition is formatted as FAT32A filesystem format readable by Windows, macOS, and Linux without additional drivers. Using FAT32 for the boot partition means any machine can read the Batocera drive and it is compatible with both legacy BIOS and UEFI boot firmware. -- readable by Windows, macOS, and Linux alike. The three critical files on this partition are the Linux kernel, the initrd (initial RAM disk), and the squashfsA compressed, read-only filesystem format. The entire Batocera OS lives in one squashfs image (~2GB). Read-only means no running process can accidentally modify the system. Upgrading Batocera means replacing this single file. root filesystem image. Upgrading Batocera means replacing these three files, which is why system updates are atomic and reliable.
The second partition, called userdata (also referred to as share), holds everything that belongs to the user. This separation is architecturally significant -- the userdata partition is portable across Batocera versions and even across different architectures, meaning a user can upgrade the system partition while their game library and settings remain untouched.
- › Linux kernel
- › initrd (RAM disk)
- › batocera (squashfs OS image)
- › batocera-boot.conf
- › EFI bootloader
- › roms/ (organized by system name)
- › bios/ (PS1, PS2, Saturn, etc.)
- › saves/ · savestates/ · screenshots/
- › system/batocera.conf
- › themes/ · bezels/ · cheats/
- › Flatpak apps + runtimes
- › Wine prefixes (windows games)
Because the userdata partition is a regular filesystem, you can access it from another computer via the Samba share (browse to \\batocera from Windows, or smb://batocera from macOS) or by mounting the drive directly. ROMs go into /userdata/roms/[system-name]/. No special software required.
Installing to an Internal Drive
Batocera is most commonly used from a USB stick or SD card, but it can be installed permanently to an internal SSD or hard drive. The installer is built into Batocera itself: boot from a USB stick, go to Main Menu > System Settings > Install Batocera on a New Disk, and select the target internal drive. Batocera writes the boot partition and creates the userdata partition on the target disk, then boots from it on the next start.
Installing Batocera to an internal drive erases the target drive entirely. If the internal drive currently holds Windows or another OS, that data will be gone. The installer does not offer a dual-boot configuration. If you want to keep an existing OS, install Batocera to a dedicated separate drive.
An internal NVMe or SATA SSD dramatically improves ROM load times for disc-based systems (PS2 ISOs, GameCube images) compared to a USB stick. For users building a dedicated arcade or living room machine, internal installation is the standard approach. The read-only system partition model means an internal install is no more fragile than a USB-based one — updates are still atomic squashfs replacements, and the userdata partition remains untouched.
Saves and Save States
Batocera distinguishes between two types of game progress storage, and the difference matters. In-game saves use the emulator's emulated save mechanism — the same SRAM, memory card, or save file the original hardware used. These are stored under /userdata/saves/[system]/ and are as durable as anything on the userdata partition: they survive Batocera updates, they survive hardware swaps (move the drive to another machine and your saves come with it), and they can be copied off the drive via the Samba share for backup.
Save states are snapshots of the entire emulator state at a specific moment — not just the game's save data, but the exact CPU registers, memory contents, and graphics state at the instant you pressed the save state hotkey. They are stored under /userdata/savestates/[system]/. Save states are version-sensitive: a save state created by one version of a core may not load correctly in a newer version of that same core if the core's internal state structure changed. In-game saves do not have this limitation and are the safer long-term storage method.
Both save types are stored exclusively in the userdata partition and are never touched by system updates. The Batocera update process replaces only the files on the boot partition (kernel, initrd, squashfs image) — the userdata partition is not modified.
EmulationStation: The Face of the System
The interface users interact with is a Batocera-maintained fork of EmulationStation, an open-source frontend originally designed for RetroPie. Batocera maintains its own branch -- the batocera-emulationstation repository on GitHub -- adding functionality and integration points that upstream EmulationStation does not have.
EmulationStation organizes games by system. Each system appears as a visual category; selecting it reveals the game list for that platform, complete with scraped artwork, metadata, ratings, and video previews where available. The frontend is controller-first -- it is navigated entirely with a gamepad. A keyboard is useful for initial WiFi configuration and SSH access, but the intended day-to-day experience requires nothing beyond a controller.
The visual theming system is extensive. Additional themes for EmulationStation can be installed directly through the Batocera Store (accessible from within the frontend), and the community has produced dozens of themes ranging from minimalist grid layouts to detailed recreations of vintage console menus. For additional visual context during gameplay, Batocera supports bezels -- decorative overlays that frame 4:3 ratio game screens on widescreen displays, often styled after the physical arcade cabinets or console TVs of the era.
Controller Configuration
Controller setup is one of the areas where Batocera earns its plug-and-play reputation. When a USB or Bluetooth gamepad is connected, Batocera checks it against an internal database of known controllers. If a match is found — and the database covers an enormous range of Xbox, PlayStation, 8BitDo, and generic USB pads — the controller is mapped automatically and works in every emulator without further configuration.
If the controller is not recognized automatically, EmulationStation presents a visual mapping wizard that walks through each button press one at a time. The resulting mapping is written to the controller's profile and applied globally. From that point, per-emulator input translation is handled internally — you configure the controller once in ES, and every emulator receives it as a correctly mapped gamepad without any per-emulator configuration file editing.
Per-game and per-system overrides are available for cases where a specific emulator has unusual button layouts or where a game uses unconventional controls. These are set from the game's options menu within EmulationStation and stored in the userdata partition, so they survive system updates.
Bluetooth pairing is handled from within the EmulationStation menus under Controller & Bluetooth Settings. The system supports standard BT HID devices. For controllers that use proprietary wireless dongles — many 8BitDo receivers, the Xbox Wireless Adapter — plug the dongle in before booting and Batocera recognizes it as a standard wired controller.
RetroAchievements Integration
One feature that separates Batocera from a simple "put emulators on a USB stick" solution is its native RetroAchievements support. RetroAchievements is a community platform that adds achievement systems to classic games -- think Xbox Achievements, but for SNES and Genesis games. Batocera integrates this at the system level, allowing users to log in with their RetroAchievements account and earn achievements across thousands of supported titles without any per-emulator configuration.
Scraping: Box Art and Metadata
Scraping is the process of fetching box art, screenshots, descriptions, release dates, and video previews for your ROM collection and displaying them inside EmulationStation. Batocera bundles ScreenScraper and TheGamesDB as its two primary scraping sources. ScreenScraper is the more comprehensive of the two — it covers regional variants, disc label art, and fan-made images for a large range of systems — but it requires a free account and rate-limits guest scraping.
Scraping is triggered from within EmulationStation via Main Menu > Scraper. You can scrape the entire collection at once or scrape a single game from its context menu. Batocera matches ROMs to database entries by filename and file hash, so renamed ROM files may need manual matching. Scraped assets are stored in the userdata partition under /userdata/roms/[system]/media/ and survive system updates.
The ScreenScraper integration in v43 added options for selecting which image source, box source, logo source, and whether to scrape video previews — giving users explicit control over what gets downloaded rather than downloading everything by default.
What It Emulates
The official Batocera website states that the distribution provides access to 200+ systems. That number is accurate if you count every variant, regional release, and sub-system -- the Batocera wiki lists systems spanning the entire history of home gaming, from the Fairchild Channel F (1976) through PlayStation 3 and Nintendo 3DS titles that were released well into the 2010s.
The emulator selection itself is curated, not exhaustive. The project's unofficial motto is "Only Cores That Matter" -- Batocera ships the emulators and libretro coreslibretro is an API that standardizes how emulator "cores" are built and loaded by a frontend. RetroArch is the primary libretro frontend. Batocera uses libretro cores for many systems so emulators can be swapped without changing the frontend layer. that deliver the best compatibility and performance for each system, rather than bundling every option available. For many systems, multiple emulator backends are available and can be switched per-game from within the EmulationStation interface.
The following explorer covers what makes each generation technically interesting to emulate -- not just which systems are supported, but why some are harder than others:
8-bit hardware is well-understood and cycle-accurate emulation is achievable on hardware from the early 2000s. The engineering challenge has shifted from performance to accuracy: modern 8-bit cores like Mesen (NES) and SameBoy (Game Boy) prioritize sub-frame accuracy over speed, reproducing hardware quirks that games relied on without knowing the hardware would break. Batocera ships multiple NES cores — cycle-accurate Mesen alongside faster options — letting users choose the tradeoff.
16-bit systems introduced co-processors and custom chips that are individually straightforward but interact in ways that required years to reverse-engineer fully. The SNES SuperFX chip (used in Star Fox and Yoshi's Island) and the SA-1 (used in later Mario and Kirby titles) each required dedicated emulation paths. Bsnes/Ares delivers near-perfect SNES accuracy but is CPU-intensive for its generation. For Genesis/Mega Drive, Blastem achieves accuracy comparable to hardware measurements. Batocera ships the accurate cores alongside the faster Genesis Plus GX for lower-end hardware.
This generation introduced 3D rendering and hardware that was deliberately obscure. The Sega Saturn used two SH2 processors in tandem — a design so unusual that accurate emulation took decades. Mednafen PSX achieves near-perfect PS1 accuracy. N64 emulation remains imperfect: the RDP (the N64's rendering chip) was never fully documented, and while Ares and ParaLLEl-RDP have made dramatic improvements using low-level emulation and Vulkan, some games still have visual glitches. Dreamcast emulation via Flycast is generally excellent but still benefits from hardware-accurate SH4 emulation modes that increase CPU demand.
PS2 emulation via PCSX2 has matured significantly with the Qt-based rewrite and Vulkan renderer. The PS2's Emotion Engine and Vector Units are now emulated with high accuracy on modern mid-range CPUs. GameCube and Wii emulation via Dolphin is exceptionally accurate — Dolphin's development rigor is notable even by emulator standards — and performance on any reasonably modern CPU is strong. Xbox emulation via Xemu is functional for a wide library but the original Xbox GPU (a modified NV2A) has gaps in accuracy that affect some titles. These systems benefit from hardware that supports Vulkan 1.3 or newer.
This generation sits at the frontier of practical emulation. RPCS3 (PS3) is one of the most technically impressive open-source emulation projects — emulating the Cell Broadband Engine's SPU architecture in software requires sequential per-core workloads that heavily penalize slow single-core clock speeds. RPCS3 benefits from CPUs with high single-core throughput above all else. Xenia (Xbox 360) has different characteristics: it is primarily GPU-bound, benefiting from a modern discrete GPU with strong Vulkan support. Wii U emulation via Cemu, now open-source, is in a different class from the others — it runs many titles at full speed and accuracy on modern hardware. All three require x86_64 Batocera builds.
What to configure differently in Batocera for this generation: RPCS3 performance is significantly affected by the SPU decoder setting (ASMJIT vs. LLVM — LLVM produces better code but compiles slower on first launch, producing the shader compilation stutter many PS3 players encounter). The shader cache warms over time and stores in the userdata partition, persisting across updates. For Xenia, enabling GPU-based texture cache and selecting Vulkan as the backend (not D3D12, which does not apply under Linux) are the primary performance levers. Cemu on Batocera benefits from the Vulkan async shader compilation option to reduce stutter on first traversal of new areas.
ShadPS4 is the first PS4 emulator to achieve meaningful playability on a growing library of titles. The PS4's architecture — a custom AMD GCN GPU and x86-64 CPU — is more familiar to PC hardware than the Cell architecture of the PS3, which has accelerated early development. Compatibility is partial and improving rapidly; simpler and older PS4 titles, particularly games from the PS4's first two years of release and titles that are not GPU-intensive, tend to run better than complex recent ones. ShadPS4 in Batocera v42 is limited to x86_64 builds.
The practical Batocera-specific context: ShadPS4 uses Vulkan and performs best on AMD GPUs under Linux due to the RADV driver's maturity with GCN-era shader translation. Nvidia via NVK (the open-source Vulkan driver) is functional but less mature. Proprietary Nvidia drivers are not compatible with the ShadPS4 Vulkan path on the Wayland image. For users specifically evaluating PS4 emulation, an AMD GPU is the correct choice in a Batocera build at this stage of ShadPS4's development.
Arcade emulation spans the widest range of hardware complexity of any category. MAME (Multiple Arcade Machine Emulator) prioritizes documentation and accuracy over performance -- it emulates thousands of arcade boards with a focus on preservation. FinalBurn Neo prioritizes performance for the most popular systems (CPS1/CPS2/Neo Geo) and is the better choice for casual play. Batocera also supports the Naomi, Naomi 2, Atomiswave, Triforce, and Model 2 boards as separate systems, each with specialized cores. Getting arcade games to run requires matching the correct MAME ROM set version to the core — a mismatch in set versions is the most common source of non-working arcade games.
The inclusion of Wine-TKG and Steam client support is worth noting. Batocera is not strictly limited to retro gaming -- it can run a meaningful subset of modern Windows titles and Steam games, which makes it a surprisingly capable media PC OS for users who want a single-purpose gaming machine without a full desktop Linux setup. For a broader look at the current state of gaming on Linux across all platforms and approaches, that article covers the full landscape.
Shaders and Visual Upscaling
Batocera ships the full RetroArch shader library, giving access to hundreds of post-processing filters that can be applied to any game running through a libretro core. The practical categories are: CRT simulation shaders (such as CRT-Royale and CRT-Geom) that add scanlines, phosphor glow, and mask patterns to recreate the look of period-accurate CRT displays; and upscaling filters (xBRZ, HQx, Super-xBRZ) that smooth pixel art intelligently by detecting edges and diagonal lines rather than blurring everything uniformly.
Shaders are applied per-core or per-game and are configured from within the RetroArch quick menu (opened with the hotkey while a game is running). Saved shader presets are stored in userdata and persist across updates. For standalone emulators like Dolphin and PCSX2-QT, shaders are managed within those emulators' own settings rather than through RetroArch — Dolphin's internal upscaling (2x, 3x, 4x native resolution) and PCSX2's upscaling options are accessible from their respective per-game menus inside Batocera.
Hardware Support
Hardware support is where Batocera has expanded most aggressively since its early releases. Version 40 (August 2024) added support for the Lenovo Legion Go, Ayaneo 2S, Ayaneo Air Plus 6800U, Radxa Rock 5c, OrangePi Zero 3, Banana Pi BPI-M7, and the Pironman 5 case for Raspberry Pi 5, among others. Version 41 (January 2025) extended compatibility to the Retroid Pocket family of handhelds.
On the GPU side, Batocera maintains support for both modern and legacy Nvidia drivers simultaneously -- a technically demanding commitment that the project explicitly makes so that older hardware running a GTX 600-series card can still run Batocera without being left behind. AMD Radeon RX cards and Intel integrated graphics are also well-supported through Mesa3D, which version 42 updated to 25.1.9.
For Raspberry Pi users specifically, Batocera maintains a separate kernel track: Raspberry Pi firmware and kernel are pinned to a 6.12.x LTS release to match the upstream Pi firmware release cycle, while the main x86_64 image tracks a more recent non-LTS kernel series. The exact kernel version shipped with each Batocera release is listed in the changelog for that version.
Minimum System Requirements
Batocera will boot and run the EmulationStation frontend on very modest hardware, but practical usefulness depends on what you plan to emulate. The absolute floor for booting the x86_64 image is roughly 1 GB of RAM and a CPU capable of running a 64-bit OS — but at that level you are limited to 8-bit and 16-bit systems only. For anything beyond Game Boy Advance and SNES, 4 GB of RAM is the practical minimum. 8 GB is the recommended baseline for users who intend to run PS2 or GameCube titles.
Storage is a separate question from RAM. The Batocera system image itself requires approximately 6 GB on the boot partition. The userdata partition that holds your ROMs, saves, and BIOS files can be any size — a 16 GB drive gives you room for a modest collection, while serious multi-system libraries benefit from 128 GB or more. Batocera can also be pointed at external drives for ROM storage, keeping the boot drive small.
Boot: Any 64-bit CPU, 1 GB RAM, 16 GB USB drive or SD card — EmulationStation loads, 8/16-bit systems work.
Practical: 4 GB RAM, dual-core CPU from 2013 or later — PS1, N64, and most 5th-gen systems run well.
Recommended: 8 GB RAM, quad-core CPU with 3 GHz+ single-core, discrete GPU — PS2, GameCube, Dreamcast at full speed.
PS3/Xbox 360: 16 GB RAM, modern high-single-core CPU (Ryzen 5 5600 class or better) required for reliable performance.
Release History: v41 Through v43 Glasswing
Batocera ships major releases roughly every six to nine months, with each version named after a butterfly species. The timeline below traces the project's evolution from fork to current stable — click any release to expand its significance:
Version 41, "Golden-rayed Blue," released on January 6, 2025, introduced improved Wine support enabling a broader library of Windows titles, optimized multi-screen management for arcade cabinet builds (pinball cabinets in particular benefit from dual-display support), and expanded handheld hardware support including the Retroid Pocket.
GamingOnLinux covered the release, noting that the changelog also included initial Blamcon light gun support, additional gamepad and steering wheel support, and numerous emulator updates. The light gun support in particular reflects an ongoing push to support physical peripherals that many general-purpose Linux distributions handle poorly or not at all.
Version 42, "Papilio Ulysses," released October 12, 2025, was a significant system-level upgrade. The headline infrastructure change was the completion of the Wayland and Sway (version 1.11) migration for x86_64 systems -- Wayland had been rolling out incrementally since version 36 for single-board computers, and v42 brought the x86 platform fully into alignment, with XWayland retained for compatibility. The version 42 changelog documents:
- Vulkan stack updated to 1.4.304
- VKD3D-Proton updated to 2.14.1
- Wine-TKG updated to 10.7 and Wine Proton to 10.0-4
- Nvidia production drivers updated to 575.64
- Mesa3D updated to 25.1.9
- SDL3 added at version 3.3.6 (alongside retained SDL2 support)
- RPCS3 updated to v0.0.37
- ScummVM updated to v2.9.1
- Xemu (original Xbox emulation) updated to v0.8.96
- ShadPS4 added -- initial PlayStation 4 emulation support for x86_64
- Xbox 360 emulators Xenia and Xenia-Canary moved to VKD3D (D3D12 to Vulkan) by default, replacing native Vulkan as the default renderer; previous native Vulkan remains available as an option
- Removal of Future Pinball in favor of Visual Pinball, which runs natively on Linux
The Sega CD / Mega CD ROM folder was also renamed from segacd to megacd in version 42, continuing the project's effort to standardize naming conventions across the system directory tree (consistent with megadrive rather than genesis).
The addition of ShadPS4 in v42 marks Batocera's first step into PlayStation 4 emulation. ShadPS4 is an open-source PS4 emulator under active development — the official ShadPS4 GitHub repository confirms it can run titles including Bloodborne, Dark Souls Remastered, and Red Dead Redemption as of 2026. It is limited to x86_64 builds of Batocera, requires a CPU with AVX2 support and a GPU with Vulkan 1.3, and requires system firmware modules dumped from a legally owned PS4. Compatibility is expanding but the Batocera wiki accurately describes it as experimental.
Version 43: Glasswing (Current Stable)
Version 43, "Glasswing," released March 19, 2026, is the current stable release as of this writing. The most consequential change in v43 is the removal of the legacy Nvidia 340.xx and 390.xx drivers, which could no longer be maintained against the current kernel. Going forward, supported Nvidia driver tracks in Batocera are: legacy 470.xx (GeForce 600/700 series cards), 580.xx, and the current 590.xx production driver. Users on hardware that depends on the older 340 or 390 drivers will need to remain on v42. For context on what the current Nvidia Linux driver landscape looks like outside of Batocera, including open module status and firmware architecture, see our guide to Nvidia Linux drivers.
v43 also introduces a compositor split on x86_64. Handheld devices with AMD and Intel graphics now use the x86-64-v3 image, which runs Wayland with the LabWC compositor. Desktop builds with Nvidia GPUs should continue to use the standard x86-64 image with Xorg, as Nvidia support on the Wayland image is currently marked experimental. This reflects a deliberate separation between the handheld use case and the traditional desktop/HTPC use case rather than a single-image compromise.
The 3DS emulation backend also changed in v43: Azahar Plus was replaced by the upstream Azahar project, and 3DS ROMs must now be fully decrypted before use. The custom.sh scripting method is deprecated in v43 -- existing scripts are automatically converted to a service at first boot, and the wiki now recommends the services system for all future scripting. The Nintendo controller driver migrated to the mainline Linux kernel driver, which may require controller reconfiguration at first boot for both wired and Bluetooth Nintendo controllers. SM8250 and SM8550 mobile SoC devices (used in several ARM handheld builds) moved to a unified image with device selection at the bootloader level, requiring an Android Bootloader (ABL) upgrade when migrating from v42.
Two emulators were removed in v43. The Drastic Nintendo DS emulator was dropped because it is closed-source and is no longer compatible with Batocera's current OS base. Nintendo DS emulation continues via the open-source melonDS (updated to 1.1 in v43) and DeSmuME cores. The separate Dolphin-Triforce emulator — a specialized branch of Dolphin for emulating Nintendo's Triforce arcade platform — was also removed because the main Dolphin-Emu build now natively supports Triforce. This is a meaningful improvement: the old Dolphin-Triforce branch had not been updated in years and had severe compatibility issues with several titles. Users migrating from v42 who had Triforce game saves must move them from /userdata/saves/dolphin-triforce/ to /userdata/saves/dolphin/.
v43 delivers significant emulator version updates across the board. RPCS3 advances to v0.0.40 (up from v0.0.37 in v42), which includes SPU emulation refinements and compatibility improvements for a wider PS3 library. PCSX2 advances to v2.6.3 (up from 2.4.0 in v42). RetroArch advances to 1.22.2. melonDS advances to 1.1. Dolphin-Emu is at the 2603a build, which notably adds Wii RetroAchievements support. BigPEmu — the Atari Jaguar emulator — is at v121. ScummVM is at the v2026 release build.
On the hardware side, v43 adds initial support for the Retroid Pocket 6, the AYN Thor, the Odin 2 Mini, the Powkiddy X55, the FriendlyElec CM3588 NAS, and multiple Anbernic variants (RG28XX, RG34XX, RG35XX, RG40XX, RGCUBEXX). Legion Go S received controller and LED updates. RTL8832CU and RTL8852CU USB Wi-Fi adapters are now supported on x86_64. The Qualcomm SM8250 and SM8550 SoC devices — used in a number of ARM handheld builds — migrated to a single unified image with device selection handled at the bootloader level.
v43 also adds several new systems and emulators. The Casio Loopy — a Japan-exclusive 1995 console marketed to young girls and notable for its built-in thermal sticker printer — is now a dedicated system entry rather than being folded under another category. The Enterprise 64/128 home computer (a Hungarian 8-bit machine from 1985) is now emulated via the CLK multi-system emulator. Cemu (Wii U emulation) gains support on SM8550-based ARM handheld devices. On x86_64, three specialized Sega arcade hardware boards are newly supported: Cave CV1000, Gaelco, and Hikaru. Xroar joins as an emulator option for the Color Computer (Tandy TRS-80 CoCo) line.
v43 expands light gun support significantly: the new Libretro Dolphin core now supports multi-light guns, Duckstation gains multi-light gun support, Play! (the PS2 emulator) gains single-light gun support for Namco 2x6 gun games, and Flycast standalone gains multi-light gun support. MAME standalone also received accuracy fixes for known-broken titles including Jurassic Park, Operation Wolf 3, and Police Trainer. Experimental Sinden light gun borders are now available for RPCS3 and Wine.
/userdata/saves/xbox360/ to the new profile folder that is created there. The standard (non-Canary) Xenia version does not have GamerTags and does not trigger this migration path. Users who switch between the two Xenia versions should verify save locations before and after. This detail is specific to v43 and is documented in the official Batocera changelog on GitHub.
Several other v43 additions are worth noting for day-to-day use. Batocera Control Center is a new on-screen overlay for global configuration and quick controls, accessible by default with the hotkey + east button. On Wayland devices with a touchscreen, it also launches a virtual keyboard. batocera-xtract is a new command-line archive extraction tool; on systems with the PCManFM file manager, it also provides a small GUI and right-click context menu integration for archives. Yamagi Quake II was added as a port, supporting a wider range of hardware than the previous options, including lower-end builds. EmulationStation gained save state support for standalone emulators in v43 — Dolphin, PCSX2, Mupen64Plus, and PPSSPP can now create and load save states from within the EmulationStation interface rather than requiring you to enter each emulator's own save state menu. Display reflection is a new batocera.conf option for x86_64 boards: set display.reflection=x, y, or xy to mirror the display output horizontally, vertically, or both — useful for cocktail-cabinet builds where the second player's screen faces the opposite direction.
Several system ROM directories were renamed in v43 to align with Batocera's convention of naming folders after the system rather than the emulator. If you are upgrading from v42, move your ROMs from the old folder names to the new ones: o2em becomes odyssey2, msu-md becomes megadrive-msu, xash3d_fwgs becomes halflife, plugnplay becomes tvgames, astrocde becomes astrocade, bbc becomes bbcmicro, iortcw becomes rtcw, and casloopy becomes loopy. Games stored under the old names will not appear in EmulationStation until moved.
Stable and Butterfly: Two Update Channels
Batocera offers two update branches. The Stable branch is the recommended channel for the majority of users -- it receives updates only after testing and is the version downloaded by default from batocera.org. The Butterfly branch is the rolling development channel, tracking the latest builds. It is described in the wiki as usually stable but with the caveat that particular features may be broken at any given time -- it is intended for users who want to assist the development team by testing new functionality.
Checking your installed version, switching branches, and performing updates can all be done from the command line via SSH. The official Batocera wiki documents batocera-upgrade as the primary command-line update tool; it always takes a URL argument pointing to the target build directory on the update server.
# Check installed version batocera@batocera:~$ cat /usr/share/batocera/batocera.version # Identify your hardware architecture (use this to build the correct URL) batocera@batocera:~$ cat /boot/boot/batocera.board # Upgrade to latest stable (x86_64) -- canonical server batocera@batocera:~$ batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/last # Upgrade to latest Butterfly (dev) build (x86_64) batocera@batocera:~$ batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/butterfly/last # Downgrade to a specific numbered version (e.g. v42) batocera@batocera:~$ batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/42/ # Shorthand alias (current/beta releases only, redirects to o2switch) batocera@batocera:~$ batocera-upgrade https://updates.batocera.org/x86_64/stable/last # Manual upgrade: place boot.tar.xz in /userdata/system/upgrade/ then run: batocera@batocera:~$ batocera-upgrade manual
Branch switching can also be done persistently by editing batocera.conf directly. Add or change the updates.type line, then trigger an update from the main menu or via batocera-upgrade:
# Set update branch -- add or edit this line in batocera.conf updates.type=stable # recommended for the majority of users # or: updates.type=butterfly # rolling dev builds
Software Beyond Emulators
Batocera's software model is worth understanding. The system does not use a traditional package manager for end-user software installation -- but it does support several mechanisms for extending functionality beyond the base image.
Pacman, the package manager from Arch Linux, is present in Batocera and powers the content downloader and Batocera Store under the hood. It can be used directly from SSH to install community-maintained packages — freeware ROMs, homebrews, themes, and bezels — but it is important to understand that this is not the Arch Linux package repository: packages must be built specifically for Batocera and will not accept generic Arch Linux packages. Flatpak is included for installing native Linux applications: GIMP, Telegram, and Discord are all available through this channel. And Steam can be launched directly from within EmulationStation, giving access to the full Steam library alongside the retro game collection. If you are also interested in optimizing a general-purpose Linux system for gaming, our guide to gaming optimization on Fedora with Steam, Lutris, and GPU drivers covers that workflow in depth.
The Batocera Store
The Batocera Store is an in-system content repository accessible directly from EmulationStation without any external tooling. It is not a software package manager — it does not install system utilities or update emulators. Its scope is decorative and contextual content: themes for the EmulationStation interface, bezels (decorative overlays that frame 4:3 game screens on widescreen displays), and shader presets curated for common use cases.
Themes downloaded from the Store are installed to /userdata/themes/ and can be activated immediately from the Appearance Settings menu. The community theme library ranges from minimalist dark interfaces suited to HTPC setups to faithful recreations of original console startup screens. Bezels from the Bezel Project — a community effort to produce matching decorative borders for thousands of arcade and console titles — are also installable from the Store and apply automatically per game when enabled.
This is not a configuration that is common among retro gaming distributions, and it reflects an interesting design position: Batocera is willing to blur the line between retro gaming appliance and general-purpose Linux gaming platform, as long as the primary experience -- booting directly into EmulationStation -- remains clean and unaffected.
What Experienced Users Often Get Wrong
Batocera's surface is approachable. Its internals have specific behaviors that are easy to misunderstand even after months of use. These are the mechanics that trip up people who already know the basics.
The retroarch.cfg Overwrite Cycle
One of Batocera's most important and least-understood behaviors: Batocera regenerates retroarch.cfg from scratch every time an emulator launches. It does not merge your edits — it replaces the file entirely using its Python configgen scripts. Any change you make directly to retroarch.cfg will be silently overwritten the next time you start a game. This surprises every user who has come from a standard RetroArch setup on another OS.
The correct approaches, in order of preference:
- Use the EmulationStation menus. The vast majority of RetroArch settings are accessible from within ES — check Game Settings, Advanced System Settings (press Select in the system list), and the per-game settings (hold the button on a game title). Setting things through ES writes them to
batocera.confwhere they survive the overwrite cycle. - For RetroArch settings not exposed in ES menus, use the
global.retroarch.<setting>=valuesyntax inbatocera.conf. Batocera reads this before launching and injects the value after its own overwrite, so the setting sticks. Example:global.retroarch.video_smooth=true. - For bleeding-edge RetroArch features or settings that Batocera does not yet handle: write them to
/userdata/system/configs/retroarch/retroarchcustom.cfg. This file is specifically excluded from the overwrite cycle and will not be touched at launch. Use this sparingly — settings here can conflict if Batocera later adds native support for the same key.
# Apply a RetroArch setting globally (survives the overwrite cycle) global.retroarch.video_smooth=true # Apply only to the SNES system snes.retroarch.video_smooth=true # Set a core option globally for genesis_plus_gx global.retroarchcore.genesis_plus_gx_region_detect=pal # Set the same core option for Mega Drive only megadrive.retroarchcore.genesis_plus_gx_region_detect=pal
The Single-Hash vs Double-Hash Comment Distinction
Comments in batocera.conf are not all the same. A line beginning with ## (two hashes) is a pure documentation comment — Batocera ignores it entirely. A line beginning with # (single hash) followed by a valid key-value pair is a "disabled setting" — Batocera still knows the key exists but treats it as inactive.
This distinction matters when scripting. If you query a single-hash commented key via batocera-settings-get from an SSH session, Batocera returns error code 11 ("Value error, key found but it is commented out") rather than treating it as absent. If you query a double-hash commented line or a truly absent key, you get a different error. Automated scripts that use batocera-settings-get need to handle error code 11 explicitly if they check for commented-out keys.
Per-ROM and Per-Folder Settings in batocera.conf
Batocera supports settings scoped to a specific ROM file or an entire folder, using the ROM filename as a key in batocera.conf. The syntax is system["ROM filename.ext"].setting=value. This allows, for example, enabling emulated Wiimotes for a specific Wii game while leaving them off for the rest of the library:
# Emulated Wiimotes off by default for all Wii games wii.emulatedwiimotes=0 # Enable emulated Wiimotes only for Wii Sports Resort wii["Wii Sports Resort (USA).wbfs"].emulatedwiimotes=1 # Force a specific emulator for one PS1 game psx["Castlevania Symphony of the Night (USA).bin"].emulator=mednafen # Set a shader only for one SNES game snes["Super Metroid (USA).sfc"].shaderset=scanlines
Folder-level settings use the folder name in the same syntax. Per-ROM settings override per-system settings, which override global settings. This cascade is how the hardware compatibility checker in this article's logic works internally — and it is also the mechanism behind Batocera's per-game emulator switching visible in the frontend menus, which simply writes these keys to batocera.conf on your behalf.
How "AUTO" Settings Resolve
When a setting is absent from your batocera.conf, Batocera does not fall back to a hardcoded default. It walks a three-level resolution chain that many users never see:
Level 1: /usr/share/batocera/configgen/configgen-defaults.yml — global defaults for all platforms. This is where the default emulator for each system is defined.
Level 2: /usr/share/batocera/configgen/configgen-defaults-arch.yml — architecture-specific overrides. This file is how the Raspberry Pi 0 gets a different default emulator than the x86_64 image for the same system — the lighter emulator wins on limited hardware, automatically, without any user intervention.
Level 3: The emulator-specific configgen Python script for that emulator. If neither YAML file has a value for the key, the configgen script decides through its own logic. This is the layer where emulator-specific behavior (like Dolphin's renderer selection based on available GPU APIs) is resolved.
User settings in batocera.conf have higher priority than all three levels. This chain also explains why deleting a line from batocera.conf and leaving it absent produces "AUTO" behavior — not necessarily the same as setting the key to a specific value.
Multiple WiFi Networks and Password Encryption
Batocera supports up to three WiFi network credentials simultaneously, but only the primary network is configurable from the EmulationStation UI. The secondary and tertiary networks must be set via SSH by editing batocera.conf directly:
# Primary (configurable from ES UI) wifi.ssid=HomeNetwork wifi.key=yourpassword # Secondary (SSH only — not exposed in ES menus) wifi2.ssid=WorkNetwork wifi2.key=workpassword # Third (SSH only) wifi3.ssid=HotspotNetwork wifi3.key=hotspotpassword # Hidden AP (not broadcast SSID — also SSH only) wifi.hidden.ssid=HiddenNetwork wifi.hidden.key=hiddenpassword
One behavior that surprises users: WiFi passwords entered through the ES UI are stored in batocera.conf as plaintext initially, but on the next reboot Batocera encrypts them in place, replacing the value with an enc:xxxxx token. You can overwrite this token with a new plaintext password at any time — it will be re-encrypted on the following reboot. Special characters in passwords (#, ;, $) must be escaped with a backslash: $ becomes \$.
Built-In AI Game Translation
Batocera includes a real-time screen translation feature that almost nobody outside the import game community knows exists. For any game running through a libretro core, pressing Hotkey + R pauses the game, captures a screenshot, sends it to an OCR/translation service, and overlays the translated text on the paused screen. Press the same combination again to resume. It handles non-Latin scripts including Japanese, Chinese, and Korean — making games that were never localized playable without a separate translation patch.
The feature connects to the ztranslate.net service by default (a free account with an API key is required) and is configured under Main Menu > Games Settings > AI Game Translation. The target language is set once globally; Batocera auto-detects the source language. One practical note from the official wiki: disable any active shaders before using the translation service, as post-processing filters interfere with the OCR accuracy.
Netplay's Cross-Architecture Endianness Limit
Batocera's built-in netplay uses RetroArch's client/server model, where one machine hosts a game room and others connect as clients. The default port is 55435, with UPnP auto-configuration available if your router supports it. There is also a relay server (MITM) option for networks that cannot open ports, at the cost of added latency.
The constraint that reliably surprises experienced netplay users: some cores refuse cross-architecture connections due to endianness differences. Picodrive for Genesis/Mega Drive is the documented example — it will not allow a netplay session between an x86_64 machine and a Raspberry Pi. Both machines emulate the same hardware, but their internal byte ordering differs in ways the netplay sync protocol cannot reconcile. RetroArch displays an error message at launch when this incompatibility is detected. The fix is to ensure all players use x86_64 builds of Batocera (or all use ARM builds), and to verify that both sides are running identical ROM files — even minor CRC differences between regional variants will cause desyncs.
The MangoHud Performance Overlay
Batocera includes MangoHud, the GPU performance overlay, and it is already configured for use — it simply requires enabling in batocera.conf. The global.hud key accepts three modes: perf (shows FPS, GPU name, Vulkan driver, resolution, RAM, GPU stats, GPU temp, CPU stats, CPU temp, and per-core load), game (shows boxart and metadata for the currently running game), and custom (fully configurable layout via global.hud_custom).
# Show performance stats (FPS, GPU temp, CPU temp, Vulkan driver, etc.) global.hud=perf # Show game boxart and metadata instead # global.hud=game # Custom layout — bottom-left, semi-transparent, game name + FPS + temps # global.hud=custom # All hud_custom options must be on one line, separated by literal \n global.hud_custom=position=bottom-left\nbackground_alpha=0.5\nlegacy_layout=false\ncustom_text=%GAMENAME%\nfps\ncpu_temp\ngpu_temp
MangoHud is available on x86_64 and Raspberry Pi 4 builds. It is a significantly more useful performance diagnostic than the basic FPS counter in RetroArch's OSD, because it reads directly from the GPU and kernel rather than from RetroArch's internal frame timing. For troubleshooting whether a performance problem is GPU-bound or CPU-bound, GPU temperature vs. CPU temperature under load, or which Vulkan driver version is active, MangoHud provides answers that RetroArch's overlay cannot.
Save State Thumbnails Are Automatic
Every save state Batocera creates automatically captures a screenshot of the exact frame at the moment of saving. This screenshot is stored alongside the save state file as its thumbnail and displayed in the save state browser. The behavior is enabled by default and requires no configuration. It is particularly useful when using multiple save state slots across a long game — the visual preview makes slot selection unambiguous. This is a default that Batocera set globally in the RetroArch configuration; it is not a RetroArch default behavior on other platforms.
Open Source and Community Structure
Batocera is fully open source. The primary repository at github.com/batocera-linux/batocera.linux has seen active development through early 2026, with the repository updated as recently as March 9, 2026. The project explicitly welcomes contributions and describes its development model as following "Bazaar development principles" -- a reference to Eric S. Raymond's framing of open, distributed contribution over closed, controlled development.
The community infrastructure includes a Discord server with a dedicated #help-and-support channel, an active subreddit, a comprehensive wiki at wiki.batocera.org, and a compatibility list at batocera.org/compatibility.php where users can report and check game compatibility across hardware configurations. Funding is handled via PayPal donations, and the project also sells branded merchandise -- an increasingly common model for open-source projects that need to sustain paid infrastructure without corporate backing.
SSH Access and System Administration
Batocera exposes a root SSH session on port 22 by default. The default credentials are username root and password linux. SSH must be enabled first from within EmulationStation under Main Menu > Network Settings > SSH — it is off by default. Once enabled, it persists across reboots until disabled.
The default root / linux credentials are publicly documented. If your Batocera machine is on a network shared with untrusted devices, change the root password immediately after enabling SSH. Run passwd from the SSH session and the new password persists in the userdata overlay.
From an SSH session you can inspect logs, edit batocera.conf directly, install Flatpak applications, run batocera-upgrade for system updates, and perform any other administrative task the underlying Linux system supports. The filesystem is read-only at the system level, but changes written to /userdata/ persist permanently. Changes written elsewhere (e.g., to /etc/) are possible via the overlay mechanism but are wiped on system update — anything you want to survive an upgrade must live in userdata or be applied via a service script.
From version 39 onward, Batocera's enhanced Secure Boot support for x86_64 systems interacts with the Trusted Platform Module (TPM) even when Secure Boot is disabled. On first boot you may see a blue "Boot Option Restoration" screen. You can either disable TPM in firmware settings or acknowledge the prompt. See wiki.batocera.org/secureboot#tpm for instructions.
Batocera vs. the Alternatives
Batocera is not the only retro gaming Linux distribution. The right tool depends on what you are building. Select your scenario to see which option is best suited and why:
An x86_64 PC as a dedicated living room emulation machine is where Batocera has the clearest advantage over every alternative. The practical experience: boot from cold to a game in under 90 seconds. Controllers auto-detect including DualSense and Xbox Series pads. The ES theme and bezel system means the display fills the screen correctly for every system without per-game configuration. HDMI-CEC is supported, so the machine powers on with the TV remote on many setups. The read-only OS means the system state on day 400 is identical to day 1 — nothing drifts, nothing accumulates.
The real-world friction points are also worth naming. Batocera does not have a native on-screen keyboard well-suited to living room use — initial WiFi setup and ScreenScraper credentials are easier to enter via SSH from another machine or a connected keyboard. RPCS3 PS3 performance is highly game-dependent; titles with heavy SPU workloads (Demon's Souls, Metal Gear Solid 4) require a strong CPU and may still not reach full speed. Xenia Xbox 360 compatibility is similarly uneven — broad enough to be useful but not complete enough to replace a physical 360 for every title.
Batocera has specific capabilities that matter for arcade cabinet builds that generic emulation guides never cover. The x86_64 image includes GroovyMame and the switchres library, which dynamically switch the GPU output to the native resolution and refresh rate of each arcade board — critical for authentic output on 15kHz CRT monitors. This works on AMD GPUs connected to a CRT via a VGA adapter or OSSC, and requires a video card with a DAC output path that supports 15kHz signaling. Most modern Nvidia cards do not support this; older AMD cards (R9 2xx series, RX 470/480) are the standard recommendation for CRT arcade builds.
For full multi-game cabinets, Batocera supports auto-launch on boot — you can configure a specific system or game to launch directly without going through EmulationStation — which matters for public-facing cabinets where the interface should not be exposed. Spinners, trackballs, and light guns are mapped through the standard input system and work across MAME and supported cores. Six-button vs. four-button layout differences are handled via per-system input overrides in batocera.conf. For pinball builds specifically, v41 improved dual-display management so the playfield display and backglass display can be driven independently, which was a significant gap before that release.
The read-only OS is not just convenient here — it is architecturally correct for an arcade cabinet. A machine that cannot be accidentally misconfigured, that boots identically every time, and that cannot accumulate software state over years of use is exactly what an arcade cabinet requires.
The recommendation to evaluate Knulli first is not a dismissal of Batocera on handhelds — it is a recognition that device-specific firmware concerns on small ARM handhelds are different in kind from the concerns on an x86 desktop. Knulli is a Batocera fork that adds device-specific patches for Anbernic RG35XX, RG40XX, and closely related hardware. The differences that matter in practice:
Sleep and wake: On RK3326-based devices (RG351 family), Batocera's generic ARM image has historically struggled with reliable sleep-wake behavior. Waking from sleep sometimes produces a black screen requiring a hard reboot. Knulli includes SoC-specific patches that address this for targeted devices. Battery reporting: Accurate battery percentage display requires kernel-level patches for each device's specific fuel gauge IC. Batocera's generic image may show an incorrect or static battery reading on devices whose gauges are not in the mainline kernel path Batocera uses. Screen brightness and PWM: Panel-specific brightness control, including whether PWM is used at low brightness (which causes flicker perceptible to some users), is handled at the kernel driver level. Knulli ships patches for specific Anbernic panel configurations. Button layout: Devices with non-standard button arrangements (the RG35XX H's landscape layout, the RG Cube's orientation) need explicit key mapping corrections that device-specific forks handle automatically.
The Steam Deck's AMD APU (RDNA 2 iGPU, Zen 2 CPU on LCD models; Zen 3+ / RDNA 3 on OLED) has real emulation capability that is worth understanding before choosing between Batocera and EmuDeck. Under Batocera on the LCD Deck: PS2 via PCSX2 runs well with the Vulkan renderer at native or 2x resolution for the majority of the library. GameCube and Wii via Dolphin run excellently. PS3 via RPCS3 is the critical data point — the Zen 2 CPUs in the LCD Deck have adequate single-core throughput for many PS3 titles, but the SPU-heavy workloads (large open-world games, titles with aggressive multithreaded audio) will not hit full speed. The OLED Deck's Zen 3+ cores perform noticeably better on RPCS3. Xbox 360 via Xenia depends heavily on the specific title.
The Deck's 800p display is non-standard and worth addressing specifically. Batocera handles it correctly for most emulators, but the aspect ratio and resolution of some emulator windows can produce unexpected scaling behavior. Bezels are configured for 16:9 displays and generally render as intended. The Deck's physical buttons map well to emulator hotkeys with the default Batocera configuration, though the back paddles require manual binding.
The hardware-specific power management loss when running Batocera is real and consequential: the Deck's TDP slider, suspend/resume reliability, and fan curve tuning all depend on SteamOS. Running Batocera from a USB drive means the device draws at a default TDP without Valve's power management layer, which reduces battery life compared to EmuDeck in SteamOS Game Mode.
Batocera's Pi support spans every model but the capability difference between Pi 4 and Pi 5 is large enough that it changes the answer about which systems are worth targeting. Raspberry Pi 4 on Batocera: NES, SNES, Game Boy, GBA, PS1, and most Genesis-era systems run at full speed. N64 via ParaLLEl-N64 (using the Vulkan renderer on the Pi 4's VideoCore VI) works for many titles but frame drops are common on demanding N64 games. PS2 is not practically usable on the Pi 4 under Batocera — the Emotion Engine emulation is too CPU-intensive for the Cortex-A72 cores. Dreamcast via Flycast is marginal. The Pi 4 is a strong platform for anything through the 5th generation; the 6th generation is largely out of reach.
Raspberry Pi 5 on Batocera: The Cortex-A76 cores and faster memory bandwidth change the picture meaningfully. N64 becomes reliable. PS1 via DuckStation runs with enhanced resolution. Dreamcast via Flycast handles most of the library. PS2 via PCSX2 is still limited but lighter titles in 2D-heavy PS2 games (2D fighters, simpler 3D games at reduced settings) are now feasible where they were not on the Pi 4. The Pi 5 is the first ARM SBC where the 6th generation becomes a realistic target for a meaningful portion of the library under Batocera.
The kernel note matters here: Batocera pins the Pi image to a 6.12.x LTS kernel to match the upstream Pi firmware cycle. This means Pi-specific hardware features (GPU firmware, camera, peripheral support) are kept in sync with the Pi Foundation's releases, but the Pi image may lag behind the x86 image in kernel features for a release cycle.
Dedicated mini PCs — Beelink EQ12, GMKtec NucBox G3/G5, Minisforum UM series, and similar N100/N305/Ryzen-based units — are the most common hardware people buy specifically to run Batocera. This is not an accident: a $150–200 mini PC with an Intel N100 or a Ryzen 5 5600U, installed permanently on a shelf connected to a TV, is an extraordinarily capable and silent emulation machine. Understanding what each tier delivers on Batocera is the question many guides answer poorly.
Intel N100 / N305 class (e.g. Beelink EQ12): The E-core architecture of the Intel Alder Lake-N series produces adequate single-core throughput for PS1, N64, and most Dreamcast titles. PS2 via PCSX2 works well for the majority of the library using the Vulkan renderer on the integrated Intel Xe GPU. GameCube and Wii via Dolphin run well. PS3 via RPCS3 is the hard limit — the N100's E-cores lack the single-core throughput that RPCS3's SPU emulation demands. Expect RPCS3 to be functional for simpler PS3 titles but unreliable for demanding ones. Xbox 360 via Xenia does not perform acceptably on the N100. The N100 is an excellent PS2/GameCube machine and a poor PS3 machine.
Ryzen 5 5600U / 7535U class (e.g. Minisforum UM573X): The Zen 3 and Zen 3+ cores in these units have the single-core performance RPCS3 needs. A Ryzen 5 5600U mini PC running Batocera handles a broad PS3 library well — the SPU-heavy titles that defeat the N100 mostly run here. Xbox 360 via Xenia is functional on the integrated RDNA 2 GPU for many titles. ShadPS4 PS4 emulation is functional for simpler titles. This is the tier where Batocera becomes a credible PS3 platform rather than a marginal one.
Practical setup notes for mini PCs: Install Batocera to the internal NVMe — the difference in PS2 ISO load times between NVMe and USB is noticeable. Use an external USB drive or network share for ROM storage if the internal drive is small. Most N100 and Ryzen mini PCs have no fan noise issues under Batocera's default power profile, but thermal throttling under sustained PS3 load is possible in fanless or low-TDP chassis. Check the chassis airflow before committing to a demanding emulation workload.
Batocera vs. Recalbox: The Fork in Detail
Because Batocera forked directly from Recalbox in 2015, the comparison is sharper and more instructive than any other alternative pairing. Both use Buildroot. Both boot directly into EmulationStation. Both have a read-only squashfs root and a separate userdata partition. The architectural DNA is identical. The divergence since then has been entirely philosophical and operational.
Recalbox is designed to be a finished product — opinionated, locked down, and deliberately simple. System configuration is limited to what the project exposes through its own interface. SSH is available but the expectation is that users will not need it. recalbox.conf is less extensively documented than batocera.conf, and several per-game and per-emulator override mechanisms that Batocera exposes are either absent or accessible only through hidden menus in Recalbox. That design choice produces a device that is zero-maintenance for less technical users — and that is a real advantage in the right context.
Batocera takes the opposite position. Configuration is exposed. batocera.conf is documented extensively on the wiki and expected to be edited. SSH root access is provided and standard. Standalone emulators are more aggressively included. Per-game and per-system emulator overrides are built into the frontend. The result is a system that rewards users who want to understand and control what they are running.
The operational differences that matter when something breaks: on Recalbox, if a game is not launching correctly and the fix requires changing a per-core option or a RetroArch setting not exposed in the Recalbox UI, the path to that fix is either undocumented or requires workarounds. On Batocera, the answer is almost always in batocera.conf or accessible from the RetroArch quick menu, and the wiki documents it. The difference between these two projects is most visible not when everything works, but when something does not.
On hardware support: Recalbox's x86_64 support has historically been less complete than Batocera's. Recalbox added meaningful x86_64 support relatively recently; Batocera has targeted x86_64 as a primary architecture since its first release. For handheld gaming PCs and newer ARM SBCs, Batocera consistently adds support earlier. For Raspberry Pi builds where the hardware is stable and the use case is simple, Recalbox is a fully viable choice and arguably the lower-friction one. For anything else, Batocera's ecosystem advantage is clear.
What Batocera.linux Is
Batocera.linux is a disciplined answer to a specific problem: how do you make retro game emulation as frictionless as possible across the widest possible range of hardware? The answer the project settled on -- build a purpose-specific embedded Linux system from scratch using Buildroot, enforce a clean separation between system and user data, ship the best available emulators for each platform, and wrap it all in a polished controller-first frontend -- has proven durable over nearly a decade of development.
Version 43 running on a modest PC supports more than 200 systems, runs on hardware ranging from Raspberry Pi to Steam Deck to x86 tower machines, ships with a Wayland-based display stack, includes RPCS3 for PlayStation 3 emulation, Xenia for Xbox 360, and -- as of v42 -- ShadPS4 for initial PlayStation 4 support. It can boot a machine into a fully functional gaming environment from a USB stick in under a minute. That is a meaningful engineering achievement for a free, open-source, community-funded project.
For anyone who wants a dedicated gaming machine without the overhead of a general-purpose OS, or who wants to resurrect an old PC as a living room arcade, Batocera represents the clearest and most mature path to that goal currently available. If you are still weighing options and have not settled on a use case, our guide to choosing a Linux distribution covers the full decision framework across general-purpose, gaming, and purpose-built distros.
How to Add ROMs to Batocera
ROMs are added through the userdata partition, accessible over your local network via the built-in Samba share. You do not need any special software beyond a file manager on your other machine.
- Connect Batocera to your network. Boot your Batocera machine and connect it to your router via Ethernet, or configure WiFi from Main Menu > Network Settings inside EmulationStation. Ethernet is recommended for the initial ROM transfer if you have a large collection.
- Access the Samba share from your other machine. On Windows, open File Explorer and browse to
\\batocera. On macOS, use Finder > Go > Connect to Server and entersmb://batocera. On Linux, mountsmb://batocera/shareor use a file manager with network browsing. No credentials are required by default. - Copy ROM files to the correct system folder. Inside the share, navigate to the
romsdirectory. Place each ROM in the subfolder matching its system name — for example,roms/snes/for Super Nintendo,roms/megadrive/for Sega Genesis/Mega Drive, orroms/ps2/for PlayStation 2 ISOs. System folder names are documented at wiki.batocera.org/systems. - Copy BIOS files if required. Systems such as PlayStation 1, PlayStation 2, Sega CD, and Saturn require BIOS files to function. Copy these into the
bios/folder at the root of the share. Required filenames and checksums for each system are listed on the Batocera systems wiki page. - Update the game list in EmulationStation. Once files are copied, press Start in EmulationStation, navigate to Game Settings, and select Update Games Lists. Batocera scans all ROM folders and adds newly detected games to the frontend. Alternatively, restart Batocera entirely to trigger a full scan on boot.
If \\batocera does not resolve by hostname on your Windows machine, try the Batocera machine's IP address instead: \\192.168.x.x. You can find the IP under Main Menu > Network Settings in EmulationStation.
Frequently Asked Questions
Is Batocera.linux legal?
Batocera itself is entirely legal. The project ships emulators and open-source software -- it does not distribute ROMs or BIOS files of any kind. It explicitly requires users to own the games they play. The emulators included are independently legal open-source projects.
Does Batocera modify my existing operating system?
No. Batocera writes to a USB stick or SD card and boots independently. Your existing OS on the internal drive is completely untouched. You can remove the Batocera drive at any time and your computer returns to its normal state.
What is the difference between Batocera and RetroPie?
RetroPie installs on top of Raspberry Pi OS (Debian-based), so it inherits a general-purpose Linux foundation. That gives experienced users more flexibility but also more surface area to manage. Batocera is a purpose-built embedded system compiled from scratch via Buildroot, making it simpler, faster to boot, and portable across far more hardware than RetroPie supports.
Can Batocera run Steam games and modern titles?
Yes, on x86_64 hardware. Batocera includes a Steam client launchable from within EmulationStation, Wine-TKG for Windows game compatibility, and Flatpak for native Linux applications. It is not a full desktop Linux environment, but it handles a meaningful library of modern titles alongside its retro catalog.
What is the current version of Batocera?
The current stable release is v43, codenamed Glasswing, released March 19, 2026. The previous stable release was v42 Papilio Ulysses (October 12, 2025). The Butterfly branch tracks rolling development builds ahead of each numbered stable release.
What hardware does Batocera run on?
Batocera supports over 45 hardware architectures including x86_64 PCs, all Raspberry Pi models, the Steam Deck, Anbernic handhelds, Odroid boards, Orange Pi, Banana Pi, and ARM Android TV boxes. Each architecture receives its own compiled image; not all emulators are available on every architecture.
What changed with Batocera v43 Glasswing?
Version 43 carries several important migration notes. Legacy Nvidia 340.xx and 390.xx driver support was removed — those driver branches can no longer be maintained against the current kernel. The supported Nvidia tracks going forward are 470.xx, 580.xx, and 590.xx. x86_64 handheld devices with AMD or Intel graphics now use the x86-64-v3 image with Wayland and the LabWC compositor; Nvidia drivers are present in that image but flagged as experimental, so desktop Nvidia users should remain on the standard x86-64 Xorg image. The 3DS emulator switched from Azahar Plus to upstream Azahar, which requires ROMs to be decrypted before use. The custom.sh scripting method is deprecated — existing scripts are automatically converted to services at first boot; new scripts should use the services system instead. Nintendo controller drivers migrated to the mainline Linux kernel driver, which may require reconfiguring wired or Bluetooth Nintendo controllers. Wine-TKG compressed application save paths changed structure, so Windows savegames should be backed up before upgrading. SM8250 and SM8550 ARM SoC devices require an Android Bootloader upgrade before migrating from v42. Several ROM folder names were changed for consistency: odyssey2 (was o2em), megadrive-msu (was msu-md), halflife (was xash3d_fwgs), tvgames (was plugnplay), astrocade (was astrocde), bbcmicro (was bbc), rtcw (was iortcw), and loopy (was casloopy). ROMs in old folder names will not appear in EmulationStation until moved to the new names.
What is the Butterfly branch?
Butterfly is Batocera's rolling development channel, tracking the latest builds before they become a numbered stable release. The official wiki describes it as usually stable, but notes that particular features can be broken at any given time. It is intended for users who want to test new functionality and assist the development team.
Can I install Batocera permanently to an internal drive?
Yes. Boot from a USB stick, navigate to Main Menu > System Settings > Install Batocera on a New Disk, and select your internal SSD or hard drive. The installation erases the target drive entirely — it does not dual-boot. An internal NVMe or SATA SSD significantly improves load times for disc-based systems compared to running from USB.
How do I configure controllers in Batocera?
Batocera checks connected controllers against a large internal database and maps them automatically. If your controller is not recognized, EmulationStation presents a mapping wizard at the controller setup screen — press each button when prompted and the resulting profile is applied globally across every emulator. Bluetooth controllers are paired from Controller & Bluetooth Settings in the main menu.
What are the minimum system requirements for Batocera?
The x86_64 image boots on any 64-bit CPU with 1 GB of RAM, but practical use requires more. 4 GB RAM covers PS1 and most 5th-generation systems. 8 GB is the recommended baseline for PS2 and GameCube emulation. PS3 via RPCS3 reliably requires 16 GB RAM and a CPU with strong single-core performance. Storage minimum is 16 GB; ROM collections benefit from 128 GB or more.
How does scraping work in Batocera?
Scraping fetches box art, screenshots, descriptions, and video previews for your ROM collection. Trigger it from Main Menu > Scraper within EmulationStation. Batocera supports ScreenScraper (recommended, free account required) and TheGamesDB. Scraped assets are stored in the userdata partition and survive system updates.
Does Batocera support shaders and upscaling?
Yes. Batocera ships the full RetroArch shader library, including CRT simulation shaders (CRT-Royale, CRT-Geom) and upscaling filters (xBRZ, HQx). Shaders are applied per-core or per-game via the RetroArch quick menu. Standalone emulators like Dolphin and PCSX2-QT have their own internal upscaling settings accessible from their in-Batocera menus.
Will my saves survive a Batocera update?
Yes. All save data lives in the userdata partition, which is never touched by system updates. In-game saves are stored in /userdata/saves/[system]/ and survive updates, hardware swaps, and architecture transfers. Save states are also preserved but are version-sensitive — a save state created by one core version may not load correctly in a significantly newer core version.
How do I access Batocera via SSH?
Enable SSH from Main Menu > Network Settings > SSH within EmulationStation. The default credentials are username root and password linux. Change the root password immediately after enabling SSH on any shared network — run passwd from the SSH session. The new password is written to userdata and persists across updates.
What is the difference between Batocera and Recalbox?
Both share the same Buildroot architecture and forked from a common codebase in 2015. Recalbox is more locked down and opinionated — designed to require no configuration. Batocera exposes more of the system, supports a wider hardware range, includes more standalone emulators, and expects users to be willing to edit configuration files and use SSH. Recalbox suits users who want a device that just works; Batocera suits users who want to understand and control what they are running.
What is the Xenia Canary GamerTag change in v43 and how does it affect my saves?
Xenia Canary in v43 introduced a GamerTag (user profile) system. On first launch or game start, you may be prompted to create a profile. The migration is sometimes automatic — the profile system may move your saves for you. If it does not, copy your existing saves manually from /userdata/saves/xbox360/ to the new profile subfolder that Xenia Canary creates there. The standard (non-Canary) Xenia build does not use GamerTags and does not require this migration. Back up your /userdata/saves/xbox360/ directory before upgrading to v43 if you have saves you cannot afford to lose.
Sources
- [1] Batocera.linux official website. batocera.org
- [2] Batocera.linux GitHub repository. github.com/batocera-linux/batocera.linux
- [3] Batocera.linux Architecture Wiki. wiki.batocera.org/batocera.linux_architecture
- [4] Batocera.linux Changelog (master branch). github.com/batocera-linux -- batocera-Changelog.md
- [5] Batocera Current/Previous/Beta Releases Wiki. wiki.batocera.org/current_and_previous_releases
- [6] HandWiki: Software:Batocera OS. handwiki.org/wiki/Software:Batocera_OS
- [7] GamingOnLinux: "Retro-gaming Linux distribution Batocera 40 released." August 14, 2024. gamingonlinux.com
- [8] GamingOnLinux: "Retro gaming Linux distro Batocera v41 brings expanded Wine support, better multi-screen, new hardware support." January 13, 2025. gamingonlinux.com
- [9] Batocera Supported PC Hardware Wiki. wiki.batocera.org/supported_pc_hardware
- [10] Batocera Systems Wiki. wiki.batocera.org/systems
- [11] rom-game.fr: "Batocera v42 -- Papilio Ulysses." October 2025. rom-game.fr (component version reference)
- [12] Prism News: "Batocera v43 Glasswing Arrives With Expanded Hardware Support and Emulation Updates." March 22, 2026. prismnews.com
- [13] GamingOnLinux: "Retro gaming Linux distro Batocera v42 Papilio Ulysses is out now." October 2025. gamingonlinux.com
- [14] Batocera.linux Scripting Services Wiki. wiki.batocera.org/scripting_services_rules_examples
- [15] ShadPS4 GitHub repository. github.com/shadps4-emu/shadPS4
- [16] Batocera PS4 system Wiki. wiki.batocera.org/systems:ps4
- [17] Batocera.linux changelog (v43 Glasswing entries — Xenia Canary GamerTag, batocera-xtract, Batocera Control Center, display reflection, Yamagi Quake II, ES save state standalone support). github.com/batocera-linux -- batocera-Changelog.md (master)