Batocera 43.1 Download 2026: 12 Steps, 30 Min

There is a specific kind of guilt attached to owning a laptop too slow for a modern web browser and too functional to throw in a skip. Batocera is the cure. It is a free, read-only Linux distribution that boots straight into an emulation frontend, ignores whatever operating system is rotting on the internal drive, and turns a decade-old machine into a console that plays somewhere north of 200 systems. You do not install it in the traditional sense. You write an image to a USB stick, you boot from that stick, and the host computer is never touched.

The catch — and there is always a catch — is that the internet is now clogged with auto-generated tutorials promising to do all of this in exactly twelve steps, most of them stamped out by machines that have never flashed a drive in their lives. Sites like tech-insider.org will happily sell you a confident, wrong number. This guide is the opposite. It is long, it is opinionated, and it assumes you would rather understand what you are doing than follow a numbered list into a boot loop. We will cover the current release (43.1, the point release of the Glasswing series), the exact files to download, how to verify them, how to flash them without vaporising your Windows partition, and how to load the thing with games afterward. Budget thirty minutes and a spare 32 GB drive.

Here is the entire process at altitude before we descend into it. Every step has a reason attached, because a step without a reason is how people end up reformatting the wrong disk.

1. Confirm the hardware clears the floor (1 GB RAM minimum, 2 GB recommended; any 64-bit x86 CPU). Batocera boots on weak hardware, but emulation speed is capped by the GPU and CPU you actually own, not by the distro.
2. Find a 32 GB or larger USB 3.0 stick or SSD. Under 16 GB the in-place updater refuses to run, and USB 2.0 media turns loading screens into a hobby.
3. Install Balena Etcher or Raspberry Pi Imager on a working computer. You need a tool that writes raw disk images and decompresses the .gz on the fly.
4. Go to batocera.org/download and pick the correct architecture. The wrong image — a v3 build on an ancient CPU, or an ARM image on a PC — simply will not boot.
5. Download the .img.gz (~3 GB). That single file is the entire operating system; it expands to roughly 8 GB once written.
6. Verify the checksum. A truncated download flashes cleanly and then boot-loops, costing you an hour and your composure.
7. Flash the image to the drive. Etcher handles decompression and verification and will not target your system disk by accident. dd will, cheerfully.
8. Set the target machine to boot from USB in UEFI, disabling Secure Boot. Secure Boot blocks the bootloader, and the machine quietly falls back to Windows.
9. Boot Batocera and let it auto-expand userdata. The first boot resizes the data partition to fill the drive; interrupting it corrupts the filesystem.
10. Map a controller and connect to the network. The network share is how you move games onto the device without pulling the drive out again.
11. Copy ROMs into share/roms/[system] and BIOS into share/bios, then UPDATE GAMELISTS. Batocera scans by folder shortname and only indexes what it finds.
12. Update from the menu when a point release lands. Userdata lives on its own partition, so updates keep every save, scrape, and ROM.

What Batocera Actually Is

Before you download anything, it is worth understanding what you are downloading, because the mental model saves you from half the mistakes in the pitfalls section later. Batocera is not an application you run inside Windows. It is not an emulator. It is an entire operating system, and for the duration of your gaming session it is the only operating system your machine is running.

A read-only Linux distro that boots into EmulationStation

Under the paint, Batocera is a stripped, purpose-built Linux distribution. It boots directly into EmulationStation, the same frontend that RetroPie and Recalbox use, and it bundles the entire libretro ecosystem plus a pile of standalone emulators. The clever part is the partitioning: the system itself lives on a small, read-only partition, and everything you generate — ROMs, save states, screenshots, scraped box art, configuration — lives on a separate userdata partition. That separation is not cosmetic. It is the reason an update can replace the entire operating system without touching a single one of your saves, and it is the reason a botched configuration can never brick the boot process. If you want a deeper tour of the cores doing the actual emulation, our breakdown of RetroArch cores and how libretro packages 200+ emulators covers the layer Batocera sits on top of.

The Glasswing release, decoded

The current series is version 43, which the project shipped on May 8, 2026 under the internal codename Glasswing. The current stable point release is 43.1, which superseded it on May 30, 2026 — so if a tutorial insists 43.1 landed on May 8, it has quietly merged two dates, which tells you how carefully it was written. The headline feature of the Glasswing line is proper support for x86_64 handhelds running AMD and Intel graphics, delivered through a dedicated x86_64-v3 image built on a modern Wayland + LabWC compositor. Under the hood, the kernel moved to 6.15.11 and the LLVM toolchain to 19.1.7. Emulator cores were refreshed across the board: Libretro Fceumm to the September 12, 2025 build, Genesis Plus GX to December 21, 2025, Xemu (Xbox) to v0.8.96, and Xenia (Xbox 360) to build 1d7973a from June 10, 2025. None of these numbers matter to a first-time installer, but they matter enormously to the person deciding whether to bother updating from an older release. If you are eyeing one of those newly-supported x86 handhelds, our Retroid Pocket 5 vs 6 comparison is a useful reality check on what the ARM side of the market costs by contrast.

Free, open source, and the licence clause nobody reads

Batocera is genuinely free — not free-with-an-asterisk, not free-trial. It costs zero, the source is published in full on the batocera.linux GitHub repository, and it is copyrighted by Batocera.linux from 2016 to 2026 under a CC-BY-NC-SA licence. That licence has teeth, and here is the part the marketplace listings ignore: the NC stands for non-commercial. Every eBay seller flogging a "preloaded 500,000-game Batocera SSD" is violating the licence twice over — once for selling the distribution commercially, and once for the several terabytes of copyrighted ROMs riding along with it. Batocera the software is legal, gorgeous, and yours for nothing. What you point it at is your own legal problem, and if accuracy over convenience is your religion, dedicated FPGA hardware like the MiSTer Multisystem 2 is the purist's alternative to software emulation entirely.

Prerequisites and Hardware

Batocera is famously forgiving about hardware, which is not the same as saying it runs everything well. The distribution will boot on a potato; whether that potato can hold 60 frames per second in a GameCube game is a separate conversation entirely, and one the download page will not have with you.

Minimum versus recommended hardware

The official floor is 1 GB of RAM, with 2 GB recommended, on any 64-bit x86 processor — realistically anything made since about 2010. That gets you booted. It does not get you Dreamcast. As a rough guide: an old dual-core with integrated graphics will comfortably run 8- and 16-bit systems, the original PlayStation, and Nintendo 64; a modern mini PC will add PSP, Saturn, Dreamcast, and light GameCube. PlayStation 2 and Wii remain hungry. The GPU matters more than the badge on the CPU, and the single biggest performance lever most people ignore is the storage medium, which we will get to. Here is the shape of it:

Storage: the 16 GB floor and the 32 GB you actually want

The storage minimum is 16 GB, and the recommended size is 32 GB or more. This is not a suggestion you can wave away. Below 16 GB, Batocera's in-place update mechanism will not function, because it needs headroom to stage the new system image beside the old one. On the first boot, Batocera automatically expands its userdata partition to consume whatever free space remains on the drive, so a 128 GB SSD becomes a 128 GB game library with no manual partitioning on your part. Just as important is the type of storage: a cheap USB 2.0 thumb drive works, technically, but the constant asset streaming turns game loads and box-art scraping into a test of patience. A USB 3.0 stick is the sane minimum; an actual SATA or NVMe SSD in a USB enclosure is transformative and is what we would use for anything beyond a demo.

The software you flash with

You flash from a second, working computer, and you need exactly one imaging tool. The two the project officially endorses are Balena Etcher and Raspberry Pi Imager; the Batocera wiki also points to USBImager, and Win32 Disk Imager remains a workable Windows option. Etcher is the path of least resistance because it decompresses the .gz automatically and refuses to write to your system disk. Notably, the Batocera wiki explicitly labels raw dd as "not recommended" for newcomers, and having watched people dd over their boot drive, we agree. Grab a controller too — an Xbox or 8BitDo pad is detected instantly — though a keyboard is enough to complete the initial setup.

Picking the Right Image

This is the single stage where otherwise-competent people come unstuck, because the download page offers several builds and does not stop you from choosing a wrong one. The wrong image does not throw a helpful error. It simply does nothing — a black screen, a blinking cursor, or an immediate fall-through to your existing operating system.

x86_64 versus x86_64-v3

For any standard PC, laptop, or mini PC, there are two x86 flavours to weigh. The plain x86_64 image is the universal choice and runs on effectively any 64-bit machine from the last fifteen years. The newer x86_64-v3 image, introduced with the 2026 Glasswing work, targets the v3 microarchitecture level — broadly, Intel Haswell and AMD Excavator onward, the generations that guarantee AVX2. It is the build that brings Wayland to the x86 line and is tuned for modern mini PCs such as the Beelink Mini S12 and the new wave of x86 handhelds. The rule is blunt: if your hardware is recent, take v3 for the smoother compositor; if you are reviving something genuinely old, or you are unsure, take plain x86_64, because a v3 image on a pre-AVX2 CPU will not boot at all.

Desktop, Laptop, NUC, Apple Intel

The download page also presents named targets — Desktop, Laptop, NUC, and Intel-based Apple computers. Do not overthink these. They resolve to the same x86_64 family and exist to reassure you that a given form factor is supported rather than to hand you four incompatible files. An Intel MacBook, a generic tower, and an Intel NUC all take the x86_64 image. What is not in this family is the Raspberry Pi and other ARM boards, which have their own entirely separate images; if you are building on a Pi, you want the ARM download, not anything discussed in this section. (Worth noting for Pi owners weighing distros: Batocera and Recalbox both ship official Raspberry Pi 5 images, while RetroPie in 2026 still does not.)

The 3 GB download versus the 8 GB reality

The file you download is a compressed disk image, roughly 3 GB as an .img.gz. When written to your drive it decompresses to approximately 8 GB — that is the actual operating system unpacked. Etcher and Raspberry Pi Imager both decompress on the fly, so you never manually extract anything. The filename follows a consistent scheme; here is the documented pattern from a prior release alongside the current-series analogue:

# Documented filename pattern (real v38 example):
batocera-x86_64-x86_64-38-20231014.img.gz

# The Batocera 43 series follows the same scheme, e.g.:
batocera-x86_64-x86_64-43-20260508.img.gz     # ~3 GB compressed, ~8 GB written

# The v3 / Wayland build carries a v3 token in the arch field, e.g.:
batocera-x86_64-x86_64_v3-43-20260508.img.gz  # requires an AVX2-class CPU

The trailing eight digits are the build date, so a later 43.1 rebuild will carry a newer date. Match the file you downloaded against the checksum published beside it and you never have to wonder which one you grabbed.

Download and Verify

The download itself is trivial. Verifying it is the ten-second habit that separates a working install from a mystifying boot loop, and almost nobody does it. We are going to do it.

The only URL that matters

There is exactly one canonical source: https://batocera.org/download. The raw image index lives at https://batocera.org/images/download/, and a well-known European mirror at mirrors.o2switch.fr/batocera/ carries the same files and the upgrade archives. That is the complete list of places you should obtain Batocera. Not a Google Drive link in a YouTube description, not a torrent bundled with 400 GB of ROMs, and emphatically not a "12-step 2026 mega-image" from a content farm that spells the developer's name three different ways. The official image is 3 GB, it is free, and it takes two minutes to fetch. There is no legitimate reason to source it anywhere else.

Checksums, and why you bother

Every official image is published beside a SHA-256 checksum. A partial or corrupted download — which happens more often than you would think on flaky connections — produces a file that flashes without complaint and then fails to boot, sending you down an hour-long rabbit hole of BIOS settings when the real fault was three missing megabytes. Verifying takes seconds:

# Linux / macOS — hash the file you downloaded
sha256sum batocera-x86_64-x86_64-43-20260508.img.gz

# Expected output: a 64-character hash that MUST equal the
# value published next to the file on batocera.org, e.g.
# 9f2c3a...<64 hex characters total>...  batocera-x86_64-x86_64-43-20260508.img.gz

On Windows, the built-in tool does the same job without installing anything:

:: Windows (Command Prompt or PowerShell)
certutil -hashfile batocera-x86_64-x86_64-43-20260508.img.gz SHA256

:: Compare the printed hash to the one on the download page.
:: If they differ by even one character, delete it and download again.

What the download should look like

When the fetch completes you should have a single file of roughly 3 GB with a .img.gz extension. If your browser "helpfully" decompressed it to a bare .img of about 8 GB, that is fine — Etcher writes either. What you must not have is a .zip, a folder full of files, or an installer .exe; if you do, you downloaded the wrong thing from the wrong place. The correct artifact is one compressed disk image and its matching checksum, nothing more.

Flashing the Image

Flashing means writing the raw image byte-for-byte onto your USB stick or SSD, replacing whatever was there. This is destructive to the target drive and harmless to everything else — provided you point it at the right drive. Choose the wrong one and you will overwrite your data. There is no undo.

Balena Etcher, the default

Etcher is the recommended tool because it makes the dangerous mistake nearly impossible; it hides your system disk by default and re-reads the drive afterward to confirm the write. The flow is four steps:

1. Flash from file — select the .img.gz you downloaded. Etcher decompresses it automatically; no manual extraction needed, which is why we did not bother extracting it.
2. Select target — choose your USB stick or SSD. Etcher greys out your internal system drive on purpose. If you only see one option and it is your Windows disk, stop and plug the USB in.
3. Flash — click it and wait. Writing 8 GB to a USB 3.0 stick takes a few minutes; to a slow USB 2.0 stick, considerably longer, which is your first hint that USB 2.0 was a false economy.
4. Validate — Etcher re-reads the drive and confirms the write matches. Let it finish. This step is the reason we trust it over dd.

Raspberry Pi Imager and USBImager

Raspberry Pi Imager is not just for the Pi; on the x86 side it is an equally good, arguably friendlier choice, and the Batocera wiki nudges beginners toward it and USBImager specifically. In Imager you choose "Use custom" for the operating system, select the downloaded image, pick your storage, and write. USBImager is a lighter, no-frills alternative that does the same job with a smaller download. Any of the three — Etcher, Imager, USBImager — produces an identical, bootable drive. Pick whichever you already trust.

The dd path, and why the wiki flinches

If you live on the Linux command line, dd works and is fast, but it is a loaded gun with the safety filed off — there is no confirmation, no undo, and no protection against selecting your root disk. The wiki calls it "not recommended" for exactly this reason. If you insist, list your block devices first, identify the target with total certainty, and only then write:

# List block devices FIRST — do not skip this
lsblk

# Identify the USB/SSD, e.g. /dev/sdb — NOT your system disk (usually /dev/sda or /dev/nvme0n1)
# Then stream the gzip straight through gunzip into dd:
gunzip -c batocera-x86_64-x86_64-43-20260508.img.gz | sudo dd of=/dev/sdb bs=4M status=progress conv=fsync

# Flush caches and eject cleanly
sync

Read that of= value out loud before you press Enter. The difference between /dev/sdb and /dev/sda is the difference between installing Batocera and erasing your operating system.

First Boot and Setup

With a flashed drive in hand, the remaining work happens on the machine you are converting. Nothing here writes to that machine's internal disk unless you deliberately, later, choose to install Batocera onto it — the default is entirely non-destructive to the host.

Getting the machine to boot from the drive

Insert the USB stick or connect the SSD, power on, and summon the one-time boot menu — the key varies by manufacturer, commonly F12, F11, Esc, or F9. Select your Batocera drive from the list. If it does not appear, dive into the UEFI/BIOS setup (Del or F2 on most boards) and do two things: disable Secure Boot, which otherwise blocks Batocera's bootloader outright, and move USB above the internal disk in the boot order. Secure Boot is the most common reason a correctly-flashed drive appears to "do nothing" — the firmware silently rejects the bootloader and loads Windows instead, and the user blames the download.

The userdata auto-expand

On the very first boot, Batocera performs a one-time expansion of its userdata partition to fill all remaining free space on the drive, then reboots itself. This is normal and it is why you never had to partition anything. The one rule: do not interrupt it. Yanking the power during the resize can corrupt the filesystem and force you to re-flash. Let the machine do its thing; a minute later it lands in EmulationStation on its own.

Language, controllers, and network

You will arrive at the EmulationStation system carousel, populated with a handful of bundled open-source and homebrew games. Three quick tasks finish the setup. First, map a controller by holding any button until the mapping wizard appears, then walk through the prompts. Second, set your language and region in the main menu if the defaults are wrong. Third, and most important for what comes next, connect to your network via the NETWORK SETTINGS menu — wired Ethernet is plug-and-forget, Wi-Fi needs your SSID and key. The network connection is what makes the file share visible so you can load games without ever removing the drive again. Expected result at this point: a working retro console with a near-empty library, waiting to be fed.

Adding ROMs and BIOS

An empty Batocera is a proof of concept. Filling it is the actual objective, and Batocera makes this pleasantly network-native: it exposes its userdata as a standard Windows file share, so you copy games over your LAN from the comfort of your main computer.

The network share layout

Once Batocera is on the network, it advertises a share reachable from any other machine on the same subnet. From Windows or macOS you browse to \\BATOCERA\share; from Linux you connect to smb://BATOCERA.local/share. Inside that share is the entire user-writable half of the system — every folder you will ever need to touch lives here, and nothing here can break the boot process. The two folders that matter for content are roms and bios.

ROMs go in roms/[shortname]

Batocera scans for games by system "shortname" — a fixed folder name per platform. Super Nintendo games go in roms/snes, Sega Genesis in roms/megadrive, PlayStation in roms/psx, and so on. Put a ROM in the wrong folder and it will not appear, because Batocera indexes by directory, not by file contents. Here is the layout:

share/
├── roms/
│   ├── snes/          # Super Nintendo    -> Game.sfc / Game.zip
│   ├── megadrive/     # Sega Genesis      -> Game.md  / Game.bin
│   ├── nes/           # Nintendo (FCEUmm) -> Game.nes / Game.zip
│   ├── psx/           # Sony PlayStation  -> Game.chd or Game.cue + Game.bin
│   └── n64/           # Nintendo 64       -> Game.z64
└── bios/
    ├── scph1001.bin   # PSX (US)  — MD5 must match docs.libretro.com
    ├── scph5501.bin   # PSX (EU)
    └── bios_MD.bin    # Sega CD

After copying files across, the library will not refresh on its own. Press Start, open GAME SETTINGS, and run UPDATE GAMELISTS to force a rescan. Your new titles appear immediately. If you are still deciding how large a library to build and how to curate it, our look at the Miyoo Mini Plus and its 6,041-game aggregation is a sobering counterweight to the "put everything on it" instinct.

BIOS files, MD5 hashes, and the libretro hub

Many systems — PlayStation, Saturn, Sega CD, Neo Geo, PSP — require original BIOS files that Batocera cannot legally distribute. These go in the bios folder, and here is the trap: the emulators check the file's exact MD5 hash, not just its name. A BIOS with the right filename but a wrong or hacked dump will fail silently with a black screen, and you will swear the emulator is broken when the file is the culprit. The authoritative reference for correct filenames and their MD5 hashes is the libretro BIOS documentation, and Batocera's own add games and BIOS wiki page mirrors the per-system requirements. Match the hashes and the black screens evaporate.

Updating Without Data Loss

This is where Batocera's split-partition design pays off. Because your ROMs, saves, and configuration all live on the separate userdata partition, replacing the operating system leaves your library untouched. You can update fearlessly, which is not something you can say about most retro-gaming setups.

The built-in updater

The path of least resistance is entirely in the interface. Open the MAIN MENU, go to UPDATES & DOWNLOADS, and choose UPDATE SYSTEM. Batocera checks the release channel, downloads the new system image beside the current one, and swaps them on the next reboot. Nothing on the userdata side is touched. This is the recommended route for point releases like 43.0 to 43.1, and it is why we insisted on a drive of at least 16 GB earlier — the updater needs room to stage the incoming image, and on undersized media it simply refuses to run.

The manual boot.tar upgrade

When the automatic updater cannot reach the network, or you want to move between major versions deliberately, there is a manual path. Download the appropriate boot.tar or boot.tar.xz archive from the mirror, drop it into the boot partition, and invoke the upgrade tool over SSH:

# SSH in (default credentials: user root, password linux)
ssh root@batocera.local

# Check the running version before you touch anything
batocera-es-swissknife --version      # -> reports the current build, e.g. 43

# Trigger the standard updater from the shell
batocera-upgrade

# Manual/offline route: place boot.tar.xz in /boot, then run
batocera-upgrade-manual

The official manual upgrade wiki page documents the archive locations and the edge cases. This cadence of small, frequent point releases is standard in the enthusiast-hardware world now — the Analogue 3D's eleven firmware builds in seven months is a fitting parallel for anyone who thinks a launch version is ever the final one.

What version 43 broke — read before you jump

Major upgrades are not always frictionless, and Glasswing removed some things on purpose. The closed-source DraStic Nintendo DS emulator is gone, replaced by open cores such as melonDS; be aware that DraStic save states do not transfer, so finish anything important before upgrading. Nintendo 3DS handling changed too: encrypted CIA and CCI dumps are no longer accepted, so ROMs must be decrypted to .3ds first, and hardware shaders now default to off. The Citra fork Azahar Plus was renamed to simply Azahar, and the TheXTech engine (an open-source Super Mario Bros. X reimplementation, whatever a mislabelled tutorial tells you) now requires 1.3.7-or-newer assets. The full, exhaustive list lives in the official changelog on GitHub. Read it before a major jump; skim it for point releases.

Common Pitfalls

Most Batocera failures are not bugs. They are the same handful of avoidable mistakes, repeated across every forum thread ever posted. Here are the ones that account for the overwhelming majority of "it doesn't work" posts, each with the fix.

Flashing and storage pitfalls

Pitfall 1 — Writing to the wrong drive. The catastrophic one. A misidentified dd target or a careless Etcher selection overwrites your data disk. Fix: use Etcher (which hides system disks) or run lsblk and confirm the device node twice before writing. There is no recovery after the fact.

Pitfall 2 — Using a drive that is too small or too slow. A sub-16 GB stick disables the updater; a USB 2.0 stick makes everything crawl. Fix: a 32 GB-or-larger USB 3.0 stick at minimum, an SSD if you are remotely serious. This single choice affects load times more than any in-menu setting.

Boot and hardware pitfalls

Pitfall 3 — Secure Boot left enabled. The machine ignores the flashed drive and boots Windows, and the drive looks "dead." Fix: enter UEFI setup, disable Secure Boot, and set USB first in the boot order.

Pitfall 4 — Choosing the wrong image for the CPU. The x86_64-v3 build will not boot on a pre-AVX2 processor, and an ARM image will never boot on a PC. Fix: when unsure, take the plain x86_64 image; it runs on essentially everything. Verify the checksum so you know the file itself is not the problem.

ROM and BIOS pitfalls

Pitfall 5 — ROMs in the wrong folder, or gamelists not refreshed. Games copied to the wrong shortname folder, or copied correctly but never rescanned, simply do not appear. Fix: place files in the exact roms/[shortname] directory, then run UPDATE GAMELISTS from GAME SETTINGS.

Pitfall 6 — Missing or wrong-hash BIOS files. PlayStation, Saturn, and similar systems show a black screen when the BIOS is absent or the MD5 does not match. Fix: obtain the correct dump, drop it in bios, and confirm the hash against docs.libretro.com. A right-name, wrong-hash BIOS is the single most misdiagnosed fault in emulation.

Pitfall 7 — Wrong disc format for CD-based systems. Loose folders of .iso fragments or mismatched .cue and .bin pairs fail to launch. Fix: prefer a single .chd per disc, or keep the .cue and its referenced .bin files together and unrenamed.

Troubleshooting Table

When something does go wrong, the symptom usually points straight at the cause. This table covers the failures we see most often, grouped by area, with the fix that resolves each.

Boot and display

These are the faults that stop you before you ever reach a game — the machine will not boot, or boots to a black screen. Nine times out of ten it is Secure Boot, a bad flash, or a graphics driver quirk.

Input, audio, network, and games

Everything past the boot stage — controllers not detected, silent HDMI, an invisible file share, or games that stutter — tends to have a one-line fix once you know where to look.

Advanced Tips and Config

Once the basics work, Batocera rewards tinkering. Almost everything the menus expose is also a single line in a plain-text config file, which means you can script it, back it up, and reason about it. This is where a retro box graduates from appliance to tool.

SSH in and know what to touch

Batocera runs an SSH server. Connect with the default credentials — user root, password linux — and the first thing any sane person does is change that password, because those defaults are printed in every guide including this one. The SSH wiki page covers key-based login if you want to skip passwords entirely. The single file that governs global behaviour is /userdata/system/batocera.conf. Because it lives on the userdata partition, it survives every update — back it up and you can rebuild a fully-configured system in minutes.

Per-system overrides and performance

The config uses a simple scoping convention. A key prefixed global. applies to every system; the same key prefixed with a system shortname — snes., psx., n64. — overrides it for just that platform. This is how you run smoothing globally but force sharp pixels on the SNES, or assign a heavier, more accurate core to one system while keeping fast defaults everywhere else. For weak hardware, the highest-impact changes are turning off bezel decorations (global.bezel=none), disabling rewind (global.rewind=0), and setting global.shaderset=none — decorative shaders are the quietest framerate thief in the whole system. For a full tour of which core to assign per system, the RetroArch cores guide maps the trade-offs.

A complete working batocera.conf

Here is a sane, complete starting configuration. Drop it into /userdata/system/batocera.conf, adjust the region and Wi-Fi lines, and you have a documented baseline you can version-control and restore at will. Every key follows the global/per-system scoping described above; the Batocera install wiki lists the exhaustive set.

# /userdata/system/batocera.conf
# Scoping: global.<key> applies everywhere; <system>.<key> overrides per system.

## --- System ---
system.hostname=BATOCERA
system.language=en_US
system.timezone=Europe/Paris
system.kblayout=us

## --- Network and sharing ---
wifi.enabled=0
wifi.ssid=
wifi.key=
system.samba.enabled=1
ssh.enabled=1

## --- Updates ---
updates.enabled=1
updates.type=stable

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

## --- Global emulator defaults (tuned for lean hardware) ---
global.ratio=auto
global.smooth=1
global.rewind=0
global.shaderset=none
global.bezel=none
global.retroachievements=0
global.retroachievements.username=
global.retroachievements.password=
global.retroachievements.hardcore=0

## --- Per-system overrides ---
snes.ratio=4/3
snes.emulator=libretro
snes.core=snes9x
nes.core=fceumm
megadrive.core=genesisplusgx
psx.emulator=libretro
psx.core=swanstation
n64.emulator=libretro
n64.core=mupen64plus_next

That configuration boots a quiet, fast, network-shared system with sensible cores — Fceumm for the NES and Genesis Plus GX for the Mega Drive, both refreshed in the 43 series — and no decorative overhead. From here, the machine is yours to overbuild. For a genuinely thorough written companion to the PC-specific quirks, Wagner's TechTalk maintains a long-running PC Batocera guide that is worth a bookmark. Everything else — every core, every system, every shader — is one documented line away.