Batocera 43.1 Download 2026: 12 Steps in 20 Minutes

Downloading Batocera is the easy part. It is one file, it is free, and it lives at a single official URL that has not moved in years. The hard part is everything that happens in the ninety seconds after the download finishes: choosing the right image for your hardware, proving the file is not corrupt, and writing it to a disk without accidentally erasing the one your operating system is sitting on. This is where people faceplant, and they faceplant in the same five or six ways every single time.

Batocera 43.1 — the current stable release as of this writing, with a changelog dated May 30, 2026 — is a read-only Linux distribution that boots straight into a games menu and emulates a couple hundred systems out of the box. It ships zero games and zero BIOS files, which is both a legal necessity and the origin of roughly half the support threads on the internet. This guide walks the entire path: what to download, how to verify it, how to flash it, how to feed it your own ROMs, and how to fix it when it sulks. Twelve numbered steps, nine code blocks you can copy, a troubleshooting table for when the code does not cooperate, and a complete working configuration at the end.

What Batocera 43.1 Is

Before you download anything, understand what the file actually is, because it changes how you treat it. Batocera is not an application you install onto an existing operating system. It is the operating system. The .img.gz you download is a complete disk image — bootloader, kernel, frontend, and a couple hundred emulators — that you write to a drive whole, replacing whatever was there. Treat it like a bootable USB installer, not like a program.

A read-only OS that boots into games

Batocera is built with Buildroot into a deliberately minimal, mostly read-only Linux system. The system partition does not change while you use it; everything you add or configure — ROMs, BIOS, saves, settings — lands on a separate writable partition called userdata. That split is the whole design philosophy: you cannot easily break the OS, because you are never writing to it. If a configuration goes sideways, you delete a file in userdata and reboot, and the base system is exactly as it shipped. The frontend you see is EmulationStation, and underneath it sit libretro cores running inside RetroArch alongside a growing pile of standalone emulators (PCSX2, Dolphin, melonDS, Azahar, and friends) for the systems that need more horsepower than a libretro core provides.

The 43.1 point release, and the butterflies

Version 43, codenamed Glasswing, landed on 2026/05/08. Its point release, 43.1, followed on 2026/05/30 and is purely a bugfix build: it repaired an EmulationStation regression where entire systems and collections could vanish from the menu, un-broke the LR-Dolphin options screen, corrected an Apple II GS MAME removal, and fixed CUDA acceleration on NVIDIA drivers. If you are downloading today, you want 43.1 and nothing older — the disappearing-systems bug alone is reason enough. One aside for the observant: Batocera's recent codenames are all butterflies. Glasswing (43), Papilio Ulysses (42), Golden-rayed Blue (41). It means nothing and it is a small, pleasant detail, which is more than most changelogs offer.

Nobody owns it, and it costs nothing

Batocera is 100% open source and completely free. There is no paid tier, no license key, no "pro" edition, and no company standing behind it — it is a community project developed by the batocera-linux collective, with all source hosted on GitHub. You can support it with a donation or a GitHub sponsorship if you feel like it, but there is no dollar figure attached and nothing is withheld if you do not. What Batocera pointedly does not include is content: no game ROMs, no console BIOS files, nothing copyrighted. That is the law, not an oversight. You supply your own dumps, ideally from cartridges and discs you own, and the defensible position — the one The Machine will always point you toward — is to dump your own hardware rather than trust a stranger's upload. If you are weighing Batocera against the alternatives, it is worth knowing that RetroPie has effectively frozen at v4.8 with no x86 image, and that a hardware approach like the MiSTer FPGA route trades software emulation for cycle-accurate logic at considerably more cost and effort.

Version History: 41 to 43.1

Downloading the correct version matters more than beginners expect, because Batocera's majors are not always additive — version 43 removed things, and if you land on the wrong build you will chase ghosts. Here is the recent lineage, straight from the project's own changelog and the releases wiki.

The release table

What Glasswing (43) actually changed

Version 43 was a display-plumbing release as much as an emulator one. The marquee item: x86_64 handheld systems with AMD and Intel graphics now run on Wayland with the LabWC compositor instead of the old X stack, a genuine modernization that also underpins the Zen3/v3 desktop build. Alongside it, Batocera moved to the mainline Nintendo controller driver, shifted RK3588 boards to the Mesa 3D Panthor driver, swapped Moonlight Embedded for Moonlight QT on most boards, and introduced the Batocera Control Center, an on-screen configuration overlay. The removals are the part that bites people: the closed-source DraStic DS emulator is gone (DS now runs on open cores such as melonDS), Azahar Plus was folded back into plain Azahar, and 3DS ROMs must now be decrypted — no encrypted CIA or CCI files.

Take the point release; do not chase betas

The rule is simple. Grab the highest stable point release, which today is 43.1. Point releases are bugfix-only and carry no risk relative to the major they patch; they exist precisely because 43.0 shipped with the EmulationStation regression noted above. Beta and nightly images exist for people testing new hardware or new cores, and they are exactly as stable as that sentence implies. Unless you own a device that only just gained support, there is no reason to touch them. If you are on an older major already, you do not need to reflash to move up — the in-place updater handles it, covered in the advanced section below.

Prerequisites

You need three things: a target drive you are willing to erase, a computer to write the image from, and one piece of flashing software. None of it is exotic, but the specifics decide whether your first boot is smooth or a forty-minute detour through your motherboard's firmware menu.

Hardware floor versus what you actually want

Batocera's minimum is genuinely low, but "boots" and "plays PlayStation 2 at full speed" are different bars. The base system wants at least 1 GB of RAM and runs comfortably on 2 GB; storage needs a hard floor of 16 GB, with 32 GB recommended — and note that a 16 GB drive is too small for the in-place updater to work, so if you go that small you are committing to reflashing for every upgrade. Eight- and sixteen-bit systems will run on a Raspberry Pi Zero 2. The heavy sixth- and seventh-generation consoles — PS2, GameCube, Wii, 3DS, and anything Vulkan-hungry — want a modern x86_64 mini PC with a real GPU. Do not expect a Pi 4 to run Dolphin at full speed; it cannot, and no configuration file will change the physics.

The drive you are going to flash

You have three realistic targets: a USB stick, an SD card, or an internal SSD/NVMe. For a first run, a decent USB 3.0 stick or an A2-rated SD card of 32 GB or larger is the sweet spot — big enough for the updater, fast enough that the menu is not sluggish, and non-destructive to your existing setup. The card's speed class is not cosmetic: a bargain-bin SD card produces stutter that people mistake for emulator problems. Whatever you choose gets completely erased. There is no partition-shrinking, no dual-boot, no "just the empty space." The entire drive becomes Batocera. If you later want it on your PC's internal disk, Batocera can install itself there from a running USB session, but start with removable media.

The flashing software you need

Exactly one of these, plus a card reader if you are using SD. Balena Etcher is the default recommendation and works on Windows, macOS, and Linux; it reads the compressed .img.gz directly and validates the write afterward. Raspberry Pi Imager is the equal-footing alternative and the one the official install wiki nudges you toward, especially for Pi targets. USBImager is a lightweight third option. On Linux you can use dd, but the wiki explicitly calls it "not recommended" for good reason: one mistyped letter in the output path erases the wrong disk with no confirmation. You also need your operating system's built-in checksum tool — CertUtil on Windows, md5sum on Linux, md5 on macOS — which you already have.

Pick the Right Image

The official download page presents images by device, and picking the wrong one is the single most common way to end up with a drive that does nothing when you power on. An image built for one system-on-chip will not boot on another. There is no universal build.

x86_64: standard versus Zen3/v3

For any 64-bit PC there are two flavors. The standard x86_64 build runs on essentially everything with a 64-bit Intel or AMD CPU, old or new — if you are unsure, this is the safe choice and it will not leave performance on the table for older hardware. The Zen3/v3 build targets the x86_64-v3 microarchitecture level: modern Ryzen chips and recent Intel, the mini-PC crowd (a Beelink S12-class box, for instance). It is the build that carries the new Wayland stack and squeezes a little more out of capable silicon. If your machine is from the last few years, take Zen3/v3; if it is genuinely old or you cannot tell, take standard. Guessing wrong on a too-new instruction set produces an unbootable image, so when in doubt, go standard.

SBCs, handhelds, and everything else

Batocera builds images for a sprawling list of non-PC hardware: Raspberry Pi 0 through 5, Odroid boards, Orange Pi variants, Rockchip-based devices, Khadas, even RISC-V boards, plus purpose-built handheld targets like the Steam Deck, the Odin 2 series, various Retroid Pocket models, AYN handhelds, and the PiBoy DMG. Each is a distinct download. A Raspberry Pi 5 image will not boot a Pi 4, and vice versa — they are different files for different silicon. Match the image to your exact board. If your device is a small ARM handheld, this is also the moment to be honest about whether Batocera is even the right OS for it; some budget handhelds are far better served by their native firmware, as we argued at length in the Miyoo Mini Plus versus RG35XX comparison where OnionOS still wins.

The filename, decoded

Today's standard PC download is named batocera-x86_64-43.1-20260529.img.gz. Read it left to right: distribution (batocera), architecture (x86_64), version (43.1), build date stamp (20260529), and format (.img.gz, a gzip-compressed raw disk image). The build stamp is May 29 while the changelog is dated May 30 — the image is simply compiled the day before the announcement goes out, which is normal and not a sign of a bad file. The download itself is roughly 3 GB compressed and expands to an image on the order of 8 GB; the writable partition then auto-grows to fill your entire drive on first boot, so the image size is not the size you end up with.

Download & Flash: 12 Steps

This is the spine of the tutorial. Twelve steps take you from an empty browser tab to EmulationStation asking you to map a controller. Each one has a reason attached, because "do this" without "because" is how people skip the step that mattered. Budget about twenty minutes, most of which is the download and the write; your hands are busy for maybe five.

1. Open the official download page. Go to batocera.org/download and nowhere else. This is the only source guaranteed to be current, and the only one that also publishes the MD5 checksum and a torrent next to the image. Forum mirrors and anonymous file lockers are how you end up on a two-year-old build, or something with an extra payload you did not ask for.
2. Select the image that matches your exact device. Standard x86_64 or Zen3/v3 for a PC; the precise Pi model; the specific handheld. The wrong system-on-chip produces a drive that will not boot, and a black screen tells you nothing about why — so eliminate the possibility here.
3. Download the .img.gz and its .md5 together. The checksum file is small and sits right beside the image. A corrupted or truncated download is the number-one cause of "it flashed fine but will not boot," and without the checksum you have no way to know before you have wasted twenty minutes.
4. Prefer the torrent if the direct mirror crawls. Batocera publishes official torrents for the major builds. They are usually faster than a saturated HTTP mirror and self-verify every chunk as they download. This is also the correct answer to "the mirror is slow" — not a random third-party file host you found in a comment thread.
5. Verify the MD5 before you flash. Two minutes now saves you from debugging a corrupt image for an hour. Run the checksum and compare it, character for character, against the contents of the .md5 file (or the value on the O2Switch mirror). If they do not match, the download is bad — delete it and pull it again, ideally via torrent.
6. Insert the target drive and positively identify it. On Windows, open Disk Management and note the disk number and size; on Linux, run lsblk. You are looking for the drive that matches your USB stick or card's capacity. This is the step that prevents the worst outcome in the entire process: flashing over your system disk.
7. Flash with Balena Etcher (or Raspberry Pi Imager). Point it at the .img.gz, select the drive you just identified, and write. Etcher reads the gzip directly and re-reads the drive afterward to validate — let it finish that validation rather than yanking the stick when the progress bar hits 100%.
8. Do not decompress the image first. Etcher and Raspberry Pi Imager both consume .img.gz natively. Manually extracting to a raw .img is only necessary if your chosen tool cannot read gzip, and doing it needlessly just gives a large file more chances to corrupt on disk.
9. Eject safely, do not rip it out. Use your OS's eject/unmount so any buffered writes flush. A truncated write produces an image that passes a glance and fails at boot — the same symptom as a bad download, from a different cause.
10. Set the machine to boot from the drive. On a PC, enter the UEFI/BIOS, disable Secure Boot, and put the USB or the target disk first in the boot order (enable Legacy/CSM only if a pure-UEFI boot fails). On a Pi or handheld, there is nothing to configure — insert the card and power on. Secure Boot left enabled is a leading cause of "the drive is fine but the PC ignores it."
11. First boot: let userdata auto-expand and do not cut power. On the initial boot Batocera resizes its writable partition to fill the whole drive and may reboot once on its own. Interrupting this leaves you with a cramped partition or a half-configured system. Give it a minute; the screen will settle into EmulationStation.
12. Map a controller and you are in. EmulationStation greets you by asking you to hold a button and map a pad; a keyboard works as a fallback. Once mapped, you can navigate the menu — and now you add games, which is the next section. That is the whole install: download, verify, flash, boot, map.

Here is the MD5 verification from step 5 on both major platforms. Expected output is a single 32-character hex string that must equal the one inside the .md5 file:

# Windows (PowerShell or cmd)
CertUtil -hashfile batocera-x86_64-43.1-20260529.img.gz MD5

# Linux
md5sum batocera-x86_64-43.1-20260529.img.gz

# macOS
md5 -r batocera-x86_64-43.1-20260529.img.gz

# Expected output (Linux) -- the hash must match the .md5 file:
# 7c9a1f0e5b3d2a48c6e1f0b9d4a72e15  batocera-x86_64-43.1-20260529.img.gz

And here is how to positively identify your target drive on Linux before you write to it (step 6). The USB stick or SD card is the small device whose size matches the label on the hardware — in this example, sdb at 29 GB, not the 931 GB system disk:

$ lsblk
NAME   SIZE TYPE MOUNTPOINT
sda    931G disk
├─sda1 512M part /boot/efi
└─sda2 930G part /
sdb     29G disk            <-- your USB/SD target
└─sdb1  29G part

If you insist on dd instead of Etcher (step 7, advanced, Linux only), decompress on the fly and write with a sane block size. Triple-check of=. There is no undo:

# DANGER: of= must be the whole target disk (e.g. /dev/sdb), NOT a partition.
# One wrong letter erases the wrong drive with no confirmation.
gunzip -c batocera-x86_64-43.1-20260529.img.gz | sudo dd of=/dev/sdb bs=4M status=progress conv=fsync
sync

If twenty minutes on a desktop is not your target device — say you are doing this on a Raspberry Pi and want the board-specific quirks — the same twelve-step spine is broken out for that hardware in our dedicated Batocera 43.1 download walkthrough, and if your real question is which emulator core to run per system once you are booted, start with the RetroArch cores guide covering 200-plus emulators.

First Boot

The first boot is not like subsequent ones, and knowing what is normal keeps you from interrupting something you should not. Batocera does one-time housekeeping the first time it powers on, then behaves identically forever after.

The userdata auto-expansion

The image you flashed is around 8 GB regardless of your drive's real size. On first boot, Batocera grows the userdata partition to consume all remaining space, so a 128 GB card actually gives you roughly 120 GB for ROMs and saves. This can trigger a single automatic reboot. Do not power off during it. Once you are in, you can confirm the expansion worked by checking the partition over SSH or a terminal — the expected output shows /userdata claiming most of the disk, not the ~8 GB of the image:

$ df -h /userdata
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda3   455G  6.1G  449G   2% /userdata

Controller mapping and the Batocera Control Center

EmulationStation opens by asking you to map a controller: hold any button to begin, then walk through the prompts (D-pad, face buttons, sticks, shoulders, Hotkey). A USB keyboard works if no pad is connected — arrows to move, Enter to select, Escape to back out. New in Glasswing, the Batocera Control Center gives you an on-screen configuration overlay for display and system options without diving into config files. You can remap or add controllers any time from the main menu under Controller Settings; there is no need to get it perfect on the first pass.

Getting on the network

Wired Ethernet is plug-and-play — Batocera picks up DHCP and you are online. For Wi-Fi, open the network settings in the menu and enter your SSID and key, or set them in batocera.conf (shown in the final section). Once networked, the machine advertises a file share on your LAN, which is how you will move games onto it without pulling the card. The default SSH credentials are user root, password linux — change the password if this box is on a network you do not fully control, and see the SSH wiki page for the details.

Adding Games & BIOS

Batocera boots with an empty library because it legally must. Filling it correctly is mostly about putting files in the right folders with the right names, and it is where the second wave of confusion hits after installation. The authoritative reference is the add games and BIOS wiki page; what follows is the practical version.

The network share is the easy path

Once Batocera is on your network, it exposes a share you can browse from any computer. On Windows or macOS, open \\BATOCERA\share (or \\BATOCERA.local); on Linux, connect to smb://BATOCERA.local/share. Inside you will find a roms folder with one subfolder per system, and a bios folder. Copy games into the matching system folder, copy BIOS files into bios, and you are done — no reflashing, no card removal. This is the intended workflow and the one to use unless the machine is offline, in which case you power down, pull the card, and drop files into the same folders directly.

ROM folder structure and rescanning

Every system has a short internal name, and the folder must use it exactly — snes, psx, n64, nds, megadrive, and so on. Put a SNES ROM in the snes folder, not one you invented called "Super Nintendo." On the running device these live under /userdata/roms/; over the share they appear under share/roms/ — same place, two names. After copying files, tell EmulationStation to rescan by choosing Update Gamelists (Main Menu, then Game Settings), or simply restart EmulationStation. The layout looks like this:

/userdata/roms/
├─ snes/
│   ├─ Chrono Trigger (USA).sfc
│   └─ Super Metroid (USA, Japan).sfc
├─ psx/
│   └─ Final Fantasy VII (USA).chd
├─ n64/
│   └─ The Legend of Zelda - Ocarina of Time (USA).z64
└─ nds/
    └─ Mario Kart DS (USA).nds

BIOS files and their MD5 hashes

Many systems refuse to run without exact BIOS files — PlayStation, PS2, Sega CD, Neo Geo, and others. Batocera cannot ship these; they are copyrighted, so you dump them from your own hardware. The catch is that emulators check the file's MD5 hash, so "a PSX BIOS" is not enough — it must be the right one, byte for byte. Batocera has a built-in Missing BIOS Check screen (under System Settings) that lists precisely which files a system wants and the hash it expects; the libretro BIOS documentation is the cross-reference for the per-core requirements. Drop BIOS files flat into /userdata/bios/ (some cores want subfolders, which the check screen tells you), then verify:

$ cd /userdata/bios
$ md5sum scph5501.bin
490f666e1afb15b7362b406ed1cea246  scph5501.bin

# Compare against the value Batocera's Missing BIOS Check expects.
# A mismatch means wrong region or a bad dump -- the emulator will refuse to boot.

Common Pitfalls

These are the mistakes that turn a twenty-minute job into an afternoon. None of them are your fault the first time; all of them are avoidable the second. Grouped by where they happen.

Storage and flashing mistakes

Pitfall 1 — flashing the wrong disk. The nightmare scenario: you select your system SSD instead of the USB stick and erase your working operating system. Fix: identify the target by size before writing (step 6), and prefer Etcher, which hides system disks by default, over raw dd. Pitfall 2 — a 16 GB drive with no upgrade path. Sixteen gigabytes boots, but the in-place updater cannot run, so every version bump means a full reflash. Fix: use 32 GB or larger and save yourself the future annoyance. Pitfall 3 — the FAT32 4 GB file limit. If your ROM drive is formatted FAT32, single files over 4 GB (large PS2 or GameCube images) silently fail to copy or get truncated. Fix: format the storage as exFAT, which Batocera reads fine and which has no practical file-size ceiling.

Download and trust mistakes

Pitfall 4 — skipping the MD5, or trusting a random mirror. A corrupt image is indistinguishable from a bad flash at boot time, and a stranger's "faster download" is exactly the kind of thing you should not run as your machine's entire operating system. Fix: download only from batocera.org, verify the MD5 every time, and use the official torrent when the mirror is slow. Pitfall 5 — decompressing when you should not. Hand-extracting the .img.gz to a raw .img for a tool that reads gzip natively just invites a corrupt intermediate file. Fix: feed Etcher or Raspberry Pi Imager the .img.gz as-is.

Version 43 gotchas that look like bugs

Pitfall 6 — encrypted 3DS ROMs. Version 43 requires decrypted 3DS files; encrypted CIA/CCI dumps that worked on older builds will now silently fail to launch. Fix: decrypt to a supported format; .3ds is re-supported, with hardware shaders off by default. Pitfall 7 — missing DS save states after upgrading. Glasswing removed the closed-source DraStic emulator, and DS now runs on melonDS, whose save states are not compatible with DraStic's. Fix: rely on in-game saves, which do transfer, and do not expect old save states to survive the move. Pitfall 8 — BIOS in the wrong folder or with the wrong hash. A system shows up but every game refuses to start. Fix: run the Missing BIOS Check, place files exactly where it says, and match the MD5.

Troubleshooting Table

When something goes wrong, the symptom rarely names its cause — a black screen could be a bad download, the wrong image, or Secure Boot. Work the table by symptom.

When it will not boot at all

Boot failures cluster around three causes: a corrupt or wrong image, firmware settings on x86, and power on a Pi. If a PC ignores the drive entirely, the problem is almost always Secure Boot or boot order, not the image. If a Pi shows a blank or rainbow screen, suspect the wrong board image or an underpowered supply before anything else.

When it boots but games will not run

Once EmulationStation is on screen, remaining problems are content and configuration: missing ROMs, an un-rescanned gamelist, absent BIOS, or a version-43 format change. These never require reflashing — they are fixed by adding files or flipping a setting.

The lookup table

Advanced Tips

Once the basics work, Batocera rewards a little command-line comfort. None of this is required, but it is the difference between a fixed appliance and a machine you actually control.

Upgrading without reflashing

You do not reflash to move between versions. For point releases and most majors, the built-in updater under the main menu's Updates section fetches and applies the new build in place — provided your drive is 32 GB or larger, since the updater needs working room. From a shell, the same thing is one command. When you are jumping several majors at once or the in-place updater is broken, the manual boot.tar route documented on the upgrade-manually wiki page is the fallback: you download the correct architecture's boot.tar.xz, place it where the bootloader expects it, and reboot.

# Network upgrade to the latest stable, from an SSH shell:
batocera-upgrade

# Manual upgrade (major jumps or a broken updater):
#  1. Download boot.tar.xz for your architecture from the official mirror
#  2. Place it in the upgrade folder Batocera expects
#  3. Reboot; the bootloader applies it on next start
# Exact paths: wiki.batocera.org/upgrade_manually

SSH and the command line

SSH is the fastest way to inspect and fix a headless box. Enable it in the network settings, then connect with the default credentials — and change the password immediately if this machine is exposed. batocera-info summarizes the hardware, df -h confirms your storage, and the whole userdata tree is right there to edit. Expected session:

$ ssh root@BATOCERA.local
root@BATOCERA.local's password:      # default: linux

  *** Batocera.linux 43.1 ***

# batocera-info
board: x86_64
cpu:   AMD Ryzen (8) @ 3.80GHz
mem:   15Gi total

# df -h /userdata
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda3   455G  6.1G  449G   2% /userdata

# passwd                               # change the default!
Changing password for root ...

Tuning through batocera.conf

Nearly every global and per-system setting lives in one file: /userdata/system/batocera.conf. You can edit it over the network share or via SSH, and changes take effect when the relevant emulator next launches (or after an EmulationStation restart). The pattern is global.<setting> for defaults that apply everywhere and <system>.<setting> to override a single console — so global.shaderset=scanlines turns on CRT shaders across the board, while snes.core=snes9x pins one system to a specific core. This is also where you set the emulator for heavy systems (ps2.emulator=pcsx2, gc.emulator=dolphin), enable RetroAchievements, and, on supported boards, apply overclocks. The complete example below is a sane starting point.

Complete batocera.conf

Here is a full working batocera.conf for an x86_64 mini PC — networked, sensible defaults, per-system cores chosen for accuracy on a capable machine. Drop it into /userdata/system/batocera.conf, edit the Wi-Fi SSID and key (or delete those two lines for wired), and reboot. Every value here is a real Batocera key; comment out anything you do not want with a leading #.

# ---- Batocera 43.1 -- /userdata/system/batocera.conf ----

# --- System ---
system.hostname=BATOCERA
system.language=en_US
system.kblayout=us
system.timezone=America/New_York

# --- Updates (needs a 32GB+ drive; 16GB cannot auto-update) ---
updates.enabled=1
updates.type=stable

# --- Network / Wi-Fi (delete these three lines if wired) ---
wifi.enabled=1
wifi.ssid=YourNetworkName
wifi.key=YourNetworkPassword

# --- Audio ---
audio.device=auto
audio.volume=90

# --- Global emulator defaults ---
global.retroachievements=0
global.retroachievements.username=
global.retroachievements.password=
global.retroachievements.hardcore=0
global.smooth=1
global.rewind=0
global.autosave=0
global.shaderset=none
global.bezel=thebezelproject
global.integerscale=0
global.ratio=auto
global.videomode=default

# --- Per-system overrides (core / emulator selection) ---
nes.core=fceumm
snes.core=snes9x
megadrive.core=genesis_plus_gx
n64.core=mupen64plus_next
psx.emulator=libretro
psx.core=swanstation
nds.emulator=libretro
nds.core=melonds
ps2.emulator=pcsx2
gc.emulator=dolphin
wii.emulator=dolphin
# ---- end ----

That is the entire arc: one verified download, one clean flash, your own games in the right folders, and a config file you understand. Batocera 43.1 is the build to grab in 2026 — verify the MD5, ignore the file lockers, supply your own ROMs and BIOS, and keep the drive at 32 GB or larger so the next butterfly can land without a reflash. The project ships a new major roughly twice a year; when the one after Glasswing arrives, batocera-upgrade is all it takes.