Batocera Download 2026: Flash 43.1 in 12 Steps, 20 Min

There is a species of retro-gaming project that survives on the strength of not lying to you, and Batocera is one of them. It does not promise a magic box stuffed with 28,000 games. It does not ship a single copyrighted ROM. It hands you a compressed disk image, points at a flashing tool, and then gets out of the way. The 2026 stable release, version 43.1, codenamed Glasswing, went out on 30 May 2026 as a bug-fix pass over the 43 branch that shipped three weeks earlier on 8 May 2026. If you have landed here for a batocera download, the honest version of the task takes about twenty minutes and twelve discrete steps, most of which are the machine waiting for bytes to move.

This tutorial walks the whole path. We decode the torrent index that reads like a licence-plate factory, pick the one image that matches your silicon, verify it so you are not flashing a corrupted file, write it without accidentally erasing the wrong disk, and get through a first boot that does not end in a black rectangle. Along the way we cover the parts the marketing copy skips: that the 200-plus pre-configured systems arrive completely empty, that BIOS files are your legal problem and not the project's, and that the update path after this is a single command rather than a reflash. Read it once before you touch anything. The twenty minutes assume you did.

What 43.1 Glasswing Actually Is

Before you download anything, it helps to know exactly which release you are chasing and what sits underneath its friendly grid of box art. Version numbers matter here more than in most software, because Batocera bakes the build date into every filename and because the difference between a point release and its predecessor is precisely the set of bugs someone already fixed for you.

The Glasswing release, dated and pinned

Batocera's changelog places 43.1 at 30 May 2026. The homepage in 2026 leads with the line Get Batocera.linux 43.1 and the slogan Download, flash, connect and play, which is the entire product thesis compressed into five words. The 43 branch itself, codenamed Glasswing, landed on 8 May 2026; 43.1 is the point release that cleaned up whatever the first three weeks of field reports surfaced. If a guide is still telling you to grab version 42, note that the 42 image carries a build stamp of 20251006, which is October 2025, and it has been superseded twice over. For a download tutorial this is not trivia. A bug-fix release exists because the .0 had bugs. You want the .1, and you want the newest build date inside it.

What Batocera is, underneath the frontend

Batocera.linux is a buildroot-based Linux distribution that boots straight into EmulationStation, the frontend you will actually touch. The operating system lives on a read-only partition; everything you change (games, saves, config, scraped artwork) lives on a separate writable partition called userdata. That split is why a botched config almost never bricks the install and why you can wipe your settings without re-downloading the OS. Most systems run through libretro cores inside RetroArch, with standalone emulators such as PCSX2, Dolphin, and Flycast wired in where a libretro core is not the best option. The per-core behaviour, hotkeys, and options are documented in the libretro docs, and the whole distribution is open source, built in the open on the project's GitHub. Bookmark both before you start; you will want them the first time an emulator behaves oddly.

Why the download model still wins in 2026

Batocera distributes exactly one artifact per device: a gzipped raw disk image. There is no installer wizard, no account, no launcher, no telemetry handshake. You download an .img.gz, you write it to a USB stick or SD card, you boot. That model has not changed in 2026, and its rivals mostly validate it. RetroPie, by contrast, is a script you layer onto an existing Linux system, and we have written about why RetroPie in 2026 is still on v4.8 with no Windows build. Batocera's image-first approach is less flexible and much harder to get wrong, which is the correct trade for anyone who wants to play games this evening rather than debug a package manager.

Prerequisites: Hardware and Software

A download is only useful if the thing on the other end can run what you flash. Sort the hardware and the toolchain first, because the two most common ways to waste an afternoon are buying the wrong storage and expecting files the project legally cannot ship.

Hardware: what actually runs it

The floor is low and the ceiling is your wallet. For 8-bit and 16-bit systems through the original PlayStation, a Raspberry Pi 4 (the bcm2711 target) or any decade-old x86 mini-PC will do. For the demanding tier (PS2, GameCube, Wii, Dreamcast at high internal resolution) you want x86_64 with a real GPU: a modern Ryzen APU or an Intel N100-class box at the low end, an actual discrete card if you are chasing 4K bezels and heavy upscaling. Batocera advertises more than 200 pre-configured systems in the Glasswing release, but nobody's Raspberry Pi runs all 200 at full speed, and any guide implying otherwise is selling you a feeling rather than a frame rate.

Storage is the other axis. The image itself is small, but your library is not. Budget a USB 3.0 stick or SSD of at least 32GB for a starter setup, and 256GB or more if you intend to hoard. Slow, no-name SD cards are the single most common cause of stutter and corruption; buy an A1 or, better, A2-rated card from a brand you recognise, and treat the bargain-bin 400GB card with the suspiciously round price as the fiction it usually is.

Software: the flashing toolchain

You need exactly two capabilities: a way to download and a way to write. For downloading, a browser pointed at the official batocera.org/download page, or a torrent client such as qBittorrent or Transmission if you take the torrent route. For writing, pick one of balenaEtcher, the Raspberry Pi Imager, or the dd command on Linux and macOS. Etcher and the Pi Imager both read the .img.gz directly, so you do not decompress first. dd does not, so you do. That single distinction causes more failed first flashes than everything else combined, and we will hammer it again below because it is worth hammering.

The parts Batocera does not give you

Two categories of file are your responsibility and nobody else's. First, ROMs: Batocera ships zero games, and the 200-plus systems arrive as empty shelves. The legal path is dumping cartridges and discs you own, which is exactly the job a Retrode does for SNES and Genesis carts. Second, BIOS and firmware: systems like the PlayStation, Saturn, and Dreamcast need original BIOS images that Batocera cannot distribute, and the emulator will refuse to launch until you supply them. This is not the project being difficult. It is the project declining to commit copyright infringement on your behalf, which, if you have read even one page of the relevant case law, is the only sane way to ship an emulator distribution.

Pick the Right Image for Your Hardware

The download page and torrent index list a wall of files that all begin with the word batocera and diverge from there. Ninety percent of the intimidation vanishes the moment you learn to read one naming pattern. Grab the wrong token and you get a stick that boots nothing; grab the right one and the rest of this tutorial is mechanical.

Decoding the filename

Every Batocera build follows one shape: batocera-[architecture]-[version]-[date].img.gz. The architecture token is the one that decides whether your device boots at all; the date is just the build stamp. Here are real 43.1 filenames from the 2026 index next to the version-42 predecessor, so you can see the pattern hold across releases:

batocera-x86_64-43.1-20260529.img.gz     # 64-bit PC / most mini-PCs
batocera-bcm2711-43.1-20260530.img.gz    # Raspberry Pi 4 / 400 / CM4
batocera-sm8550-43.1-20260529.img.gz     # Snapdragon 8 Gen 2 handhelds
batocera-x86_64-42-20251006.img.gz       # previous stable (version 42)

pattern: batocera-[architecture]-[version]-[YYYYMMDD].img.gz

An x86_64 image will not boot a Raspberry Pi, and a bcm2711 image will not boot your PC. The version and date tokens tell you which release you are holding, which matters when you are staring at a mirror that keeps both the 43.1 line and version 42 around for people on older setups.

x86_64, ARM, and the SBC zoo

Three broad families cover most readers. x86_64 is the 64-bit PC target: desktops, laptops, NUCs, N100 boxes, and most of what people mean when they say mini-PC. bcm2711 is the Raspberry Pi 4, 400, and Compute Module 4; the Pi 5 uses a different target, bcm2712, so do not assume one Pi image fits every Pi. Then there is the growing list of ARM system-on-chip builds for handhelds and TV boxes, of which sm8550 is the interesting one: it targets Qualcomm's Snapdragon 8 Gen 2 (SM8550), the same chip family that sits inside the Retroid Pocket 6. That the project maintains a dedicated sm8550 image in 2026 is a quiet signal about where ARM handheld support is heading.

Matching the build to your board

The decision tree is short. PC of any description: x86_64. Raspberry Pi 4 or 400: bcm2711. Snapdragon 8 Gen 2 handheld: check your device's compatibility notes first, then sm8550. Anything exotic (Rockchip RK3588 boxes, Odroid units, assorted TV sticks) has its own target on the download page, and you match the token to your chip. When in doubt, the full architecture list and the current image links live on the official download page, which is the canonical source and the one you should trust over any third-party mirror, torrent aggregator, or reseller promising a pre-loaded card. The pre-loaded card is where malware and stale builds go to make money.

The 12-Step Download and Flash Walkthrough

Here is the entire process, start to finish, with a reason attached to every step so you know which corners are safe to cut (none of them) and which will cost you a reflash if you skip them. Read all twelve before you begin so nothing surprises you mid-write.

The twelve steps, start to finish

1. Open batocera.org/download in a browser. It is the canonical source. Third-party mirrors, torrent-bundle sites, and eBay cards are exactly where stale builds and injected payloads live, and you cannot un-flash a compromised image.
2. Identify your architecture. x86_64 for a PC, bcm2711 for a Pi 4, sm8550 for a Snapdragon 8 Gen 2 handheld, and so on. The wrong target is the number-one first-timer failure and produces a stick that does precisely nothing on boot.
3. Choose direct download or torrent. The page lists both. Torrent is faster and self-verifying on busy release days because the client checks each piece; direct HTTP is simpler behind restrictive corporate or campus firewalls that throttle peer traffic.
4. Download the 43.1 image for your target, for example batocera-x86_64-43.1-20260529.img.gz. The newest point release carries the fewest known bugs, which is the whole reason 43.1 exists over 43.
5. Note the published checksum. You will compare against it in a moment. Recording it now means you are not hunting for it after a suspicious boot, when you are already annoyed.
6. Verify the file with sha256sum (or Get-FileHash on Windows). A single flipped bit can produce a stick that boots halfway and then hangs, and that symptom mimics a hardware fault so convincingly that people RMA good USB drives over it.
7. Insert your USB stick or SD card and identify the device precisely with lsblk, Disk Management, or diskutil list. Writing to the wrong disk erases it, and dd in particular does not ask twice or offer an undo.
8. Write the image. With Etcher or the Raspberry Pi Imager, point at the .img.gz and flash; they decompress on the fly. With dd, decompress first and then write, because feeding dd a gzip file produces an unbootable mess that looks like a Batocera bug and is not.
9. Safely eject, move the stick to the target device, and set it as the boot device. On a PC that usually means a one-time boot menu (F12, F11, or Esc depending on the board) or setting USB-first in firmware, so the machine looks at your stick before its internal drive.
10. Boot Batocera and let the userdata partition auto-expand. On first boot the system grows userdata to fill the drive. Interrupting it can leave you with a few gigabytes usable out of a 256GB card, and you will not notice until you run out of room.
11. Configure your controller when EmulationStation prompts. Nothing else is navigable until an input device is mapped; if no pad is detected, a plugged-in keyboard works and the arrow keys plus Enter will get you through setup.
12. Add ROMs and BIOS, then refresh. The systems stay empty (and hidden) until you populate /userdata/roms and /userdata/bios. This is the step where the download becomes a games machine rather than a very tidy Linux boot.

What a correct flash looks like

On Linux and macOS the manual route is two commands: list your disks, then decompress-and-write to the right one. The output below shows how to tell a 64GB stick apart from your system SSD, and what a finished dd run reports. Read the device name twice. There is no confirmation dialog waiting to save you.

# 1. list block devices and find your USB/SD by size
lsblk -o NAME,SIZE,MODEL

NAME     SIZE MODEL
sda    238.5G Samsung SSD 870
sdb     57.3G Generic USB3.0        # this is the stick you are about to erase

# 2. decompress, then write (confirm /dev/sdb before you press Enter)
gunzip -c batocera-x86_64-43.1-20260529.img.gz | sudo dd of=/dev/sdb bs=4M status=progress conv=fsync

3221225472 bytes (3.2 GB, 3.0 GiB) copied, 210 s, 15.3 MB/s
768+1 records in
768+1 records out

If you are on Windows, or you simply value your other drives, use balenaEtcher or the Raspberry Pi Imager instead. Point either one at the .img.gz, choose the target device from its dropdown, and let it flash and validate. Both refuse to write to your system disk by default, which is a guardrail dd conspicuously lacks.

Booting for the first time

A correct first boot shows a brief text splash, then EmulationStation, then a controller-configuration prompt. If you flashed to a large drive, the userdata expansion happens silently in this window; give it a minute and do not yank power. Once you are at the main menu with a mapped controller, the download-and-flash job is technically done. Everything after this is content and configuration, which is the fun part and also, mercifully, the reversible part.

Verifying the Download: Checksums and Torrents

Verification is the step everyone skips and half of those people regret. It costs thirty seconds and it converts a whole class of maddening intermittent faults into a single clear yes-or-no answer before you have wasted a flash-and-boot cycle.

Why a bad download hides as a hardware fault

A corrupted image rarely fails loudly. More often it boots to a splash, then freezes; or it runs for a day, then throws a filesystem error; or one emulator crashes and no others do. Because the symptom is erratic, people blame the USB stick, the SD card, the PSU, the target device, anything but the download. A checksum settles it up front. If the hash matches the value on the download page, the bytes are exactly what the project shipped, and any later fault is genuinely hardware or configuration. If it does not match, you re-download and you have saved yourself a evening of superstition.

Running the checksum

The command is one line on every platform. Compare its output character by character against the SHA256 value published next to the file on batocera.org/download. It either matches or it does not; there is no partial credit.

# Linux / macOS
sha256sum batocera-x86_64-43.1-20260529.img.gz

# expected form (compare the left column to the value on the download page)
a1b2c3d4e5f6...0a0b0c0d  batocera-x86_64-43.1-20260529.img.gz

# Windows (PowerShell)
Get-FileHash ./batocera-x86_64-43.1-20260529.img.gz -Algorithm SHA256

The hash above is a placeholder; the real one lives on the page beside the download link. Do not trust a hash printed in a random blog (including this one) as the source of truth. The authority is the project's own page, and the whole point of the exercise is defeated if you compare against a value someone else transcribed.

Torrent versus direct, and how the index is laid out

The download page lists both a direct link and a torrent for each build, and the torrent index is where you see the full naming scheme in the wild: entries such as batocera-x86_64-43.1-20260529.img.gz.torrent for PCs, batocera-bcm2711-43.1-20260530.img.gz.torrent for the Pi 4, and batocera-sm8550-43.1-20260529.img.gz.torrent for the Snapdragon handhelds, alongside the older batocera-x86_64-42-20251006.img.gz.torrent for anyone deliberately staying on version 42. Torrents carry their own integrity checking, so on release day they are often both faster and safer than a hammered HTTP mirror. If a torrent stalls at zero because your network blocks peer traffic, fall back to the direct download. For the release dates behind each of these builds, the official changelog is the primary record, and it is worth reading before you pick a version to pin.

First Boot: Partitions, ROMs, and BIOS

The flash gave you an operating system. This section turns it into a games console. Three things happen in order: the storage partition grows to fit your drive, you learn where files belong, and you get those files onto the device over the network instead of shuffling the card back and forth.

The auto-expanding userdata partition

Batocera writes a fixed-size image, then expands its userdata partition to fill whatever drive it finds on first boot. This is why a fresh 256GB card can briefly report only a few gigabytes free: the expansion is queued, not yet finished. Reboot once, wait, and it resolves. If it genuinely fails to expand (usually because the first boot was interrupted or the card is flaky), you can trigger it from the menu under System Settings and Storage, or reflash and let first boot complete undisturbed. The read-only system partition, meanwhile, never changes size, which is by design and is the reason updates can replace the OS wholesale without touching your library.

Where ROMs and BIOS go

The layout is predictable, one folder per system under /userdata/roms, with a parallel /userdata/bios for the firmware files you supply. Learn this tree once and you never wonder where a file belongs again:

/userdata/
  roms/            # your games, one folder per system
    snes/
    psx/
    n64/
  bios/            # firmware you supply (e.g. scph1001.bin for PSX)
  saves/           # in-game saves and save states
  system/
    batocera.conf  # the main settings file
  decorations/     # bezels and overlays
  shaders/
  music/

Empty systems are hidden in EmulationStation by default, so if the SNES entry is missing it is not broken; it is waiting for a .sfc or .zip to appear in /userdata/roms/snes. BIOS files that are missing or wrong will announce themselves under Game Settings and Missing BIOS, which lists every expected file and its checksum so you can confirm you have the right dump rather than a same-named impostor.

Getting files onto the drive over the network

You do not need to keep pulling the card. Batocera exposes its userdata folder as a network share and runs an SSH server, so you can copy games and edit config from your desktop. Over SSH the documented default login is root with the password linux, which you should change immediately with passwd because a default credential on your home network is a small but real invitation:

ssh root@batocera.local
# documented default password: linux   (change it now with: passwd)

root@BATOCERA:~# cat /usr/share/batocera/batocera.version
43.1-20260529 (Batocera.linux)

root@BATOCERA:~# ls /userdata/roms
bios  dreamcast  gba  megadrive  n64  nes  psx  snes

From Windows or macOS you can instead browse to the device by name or IP address once network shares are enabled, drop ROMs straight into the matching folders, and let EmulationStation pick them up on the next refresh. This is the workflow the project expects you to use; the SD-card shuffle is for the very first ROM only, if that.

The Content Downloader and pacman

Batocera has a built-in way to fetch legal extras without leaving the couch. It is useful, it is honest about its limits, and it is easy to mistake for something it is not, so it earns its own section.

What the Content Downloader actually offers

From EmulationStation you can reach the Updates and Downloads menu, and inside it the Content Downloader, which pulls freely distributed material: homebrew and public-domain ROMs, bezels and decorations, music themes, and other cosmetic and gameplay enhancements that carry no copyright encumbrance. The full menu map and the current list of what the downloader serves are documented on the official wiki, which is the reference to trust over forum hearsay. Think of it as a curated shelf of things the project can legally hand you, not a storefront for the commercial library you already own on cartridge.

pacman under the hood, since 5.27

This online content system is not new. It has existed since Batocera 5.27 and relies on the pacman package manager to install, upgrade, and remove the packages it offers. That heritage matters for two reasons. First, it means the mechanism is mature and predictable rather than a fresh 2026 experiment. Second, it means power users can reason about it in familiar terms: packages, a manager, install and remove operations, all wrapped in a controller-friendly menu so you never have to touch a shell unless you want to. If you have used Arch, the plumbing will feel like an old acquaintance.

What it will not do

The Content Downloader will not fetch commercial ROMs or console BIOS files, and it should not, because distributing those is the exact liability the whole project is built to avoid. It fills your themes, your bezels, and your homebrew shelf; it does not fill your PlayStation folder with games you have not dumped. If a tutorial claims Batocera can download a full commercial library for you, it is describing a reseller's pirate bundle, not this feature, and it is worth remembering how that comparison usually ends: the handheld that advertised 28,000 games and shipped a folder of 5,819 mostly-junk ROMs is the honest illustration of what padded counts are actually worth.

Updating and Upgrading Without Reflashing

The best thing about the read-only system partition is that moving from 43.1 to whatever comes next does not mean starting over. Your games, saves, and config all live on userdata and survive an OS swap untouched. There are two ways to do the swap, one for everyone and one for people who like a shell.

The Updates and Downloads menu

The everyone route is the same Updates and Downloads menu that houses the Content Downloader. It checks your current channel, tells you whether a newer build exists, and applies it in place, replacing the system partition while leaving userdata alone. On a stable install this is the correct default: you press a button, it downloads, it reboots, you are current. Because the OS is versioned and the data is separate, a failed update is recoverable rather than catastrophic, which is not something you can say about every distro's in-place upgrade.

batocera-upgrade from the shell

Over SSH there is a direct command. Run batocera-upgrade with no arguments to move to the latest build in your current channel, or pass the URL of a specific build folder to pin an exact version, which is how you move onto a beta or step back to a particular 43 point release:

# upgrade to the latest build in your current channel (stable)
batocera-upgrade

# pin to a specific build folder (a beta, or an older point release)
batocera-upgrade https://<mirror>/batocera/x86_64/beta/last/

# the general form documented by the project:
batocera-upgrade [url of the build folder containing the version you want]

The bracketed form is straight from the project's current-and-previous-releases documentation, and it is the officially sanctioned way to land on a build the menu will not offer you. Substitute the real mirror path from the download page for the placeholder; do not trust a hostname copied from a blog.

Stable, beta, and pinning a build

Batocera runs parallel channels, and the one you follow determines what the menu and the bare batocera-upgrade command hand you. Stable is what 43.1 is, and it is where almost everyone should stay. Beta exists for people who want the next release early and accept that early means occasionally broken. The upgrade and channel mechanics, including how to switch between them and how to pin an exact build, are laid out on the Batocera wiki. The rule of thumb writes itself: pin a build when you have a working setup you refuse to disturb, follow stable when you want current-and-safe, and touch beta only when you are prepared to treat a broken boot as a Tuesday.

Six Pitfalls That Waste Your Afternoon

Almost every Batocera download that goes wrong goes wrong in one of six predictable ways. Read these once and you will recognise the failure the instant it happens instead of forty minutes later.

Flashing and image mistakes

Pitfall one: unzipping the .gz before Etcher. balenaEtcher and the Raspberry Pi Imager read the .img.gz directly and decompress it as they write. If you extract it to a bare .img first, you have not helped; if you then hand the .gz to dd expecting the same magic, you have written a compressed archive to a raw device and produced an unbootable stick. Rule: gzip stays zipped for Etcher and the Imager, and gets decompressed only for dd.

Pitfall two: flashing the wrong disk. dd will happily overwrite your system SSD if you point it there, with no prompt and no undo. Always run lsblk (or diskutil list, or Disk Management) and confirm the target by size and model before you commit. This is the pitfall that ends with people restoring backups they are grateful they made.

Pitfall three: the wrong architecture. An x86_64 image on a Pi, or a bcm2711 image on a PC, yields a stick that boots to nothing and looks bricked. It is not bricked; it is the wrong file. Re-read the filename token against your chip before you flash, not after.

Boot and partition mistakes

Pitfall four: interrupting the first boot. The userdata partition expands on first boot, and cutting power mid-expansion can strand you with a fraction of your drive usable. Let the first boot finish. If your 256GB card reports 8GB free, this is almost always the cause, and the fix is a clean reboot or, worst case, a reflash with the patience to wait.

Pitfall five: no boot device selected. Flashing the stick is not enough; the target has to be told to boot from it. On a PC that means a one-time boot menu or a firmware change to put USB ahead of the internal drive. If the machine sails past your stick straight into Windows, you have flashed correctly and simply not asked the firmware to look.

Content and expectation mistakes

Pitfall six: expecting games and BIOS in the box, on a bargain card. Two errors that travel together. Batocera ships no ROMs and no console BIOS, so a first boot into empty shelves is correct behaviour, not a failed download. And the cheap, unbranded, suspiciously-large SD card that seemed like a deal is the leading cause of corruption and mid-session freezes. Supply your own legal ROMs and BIOS, buy an A2-rated card from a real brand, and five of these six pitfalls never touch you.

Troubleshooting Table

When the flash is done and something still misbehaves, the fault is usually one of a dozen known cases with a known fix. Match your symptom to the left column and work across.

How to read this table

The columns are symptom, the most likely cause, and the fix that resolves it in the majority of cases. Work top to bottom; the earlier rows are the more common failures. If two rows could describe your problem, verify the checksum first (row one's cure is half the table's cure) before you go deeper.

The failures worth extra words

Three rows deserve elaboration because they masquerade as something worse. A black screen on a PC almost always means the wrong architecture or an unverified download, not a dead machine, which is why the checksum step earns its keep. An emulator that quits the instant you launch a game is nine times out of ten a missing BIOS, and the Missing BIOS screen names exactly what it wants. And the shrunken-partition case looks like a defective card but is usually an interrupted first boot, curable by rebooting and waiting rather than by binning perfectly good hardware.

When the answer is just reflash

Some problems are not worth diagnosing. If you interrupted a flash, mixed up architectures, or cannot get a clean checksum, the fastest fix is to re-download, verify, and write again from scratch. Because your library and config live on userdata (and, if you followed the advice above, on a network share or a backup), a reflash of a fresh install costs you twenty minutes and nothing else. Stubbornness is more expensive than a second flash.

Advanced Tips: USB, Bezels, CRT

Once the basics work, Batocera rewards a bit of ambition. These are the moves that separate a working install from a good one, and none of them require abandoning the friendly menu.

Run from USB or install to internal disk

You can run Batocera indefinitely straight off the USB stick you flashed, which is ideal for turning any borrowed PC into a console without touching its drive. It is also the safest way to evaluate the release before you commit. When you are sure, Batocera can install itself to an internal disk from within the running system, which trades the stick's portability for the speed and reliability of a real SSD. The choice is genuinely yours: a fast USB 3.0 stick is fine for most libraries, while a discrete SSD earns its place the moment you start loading large PS2 and GameCube images.

Bezels, shaders, and overlays

The cosmetic layer is where a Batocera setup starts to look intentional. Decorations (bezels) frame 4:3 games so your widescreen panel is not two black bars around a small picture; shaders emulate scanlines, phosphor bloom, and the soft geometry of a CRT; overlays combine the two. Many arrive through the Content Downloader, and more are configurable per system or per game through the RetroArch options, whose behaviour is documented in the libretro docs linked earlier. Start global, then override the handful of systems that deserve special treatment, and resist the urge to stack five effects on a game that shipped at 256 by 224.

CRT output, multi-device, and the accuracy question

Batocera supports genuine CRT output on suitable hardware, which is the closest a software emulator gets to the real thing for anyone who still owns a tube. And because the image model is architecture-agnostic, you can run the same project across a PC in the living room, a Pi in the bedroom, and a Snapdragon handheld in your bag, each with its own build but the same mental model. If, on the other hand, you decide that emulation timing is never quite accurate enough for you, that is a legitimate position and it points at FPGA hardware; the crowd that cares about cycle accuracy congregates around the MiSTer project and its forum. Batocera and MiSTer are different churches solving overlapping problems, and there is no shame in attending both.

A Complete Working batocera.conf

Everything you set through the menus is ultimately written to one plain-text file. Knowing that file lets you back up a whole configuration, replicate it across devices, or fix a bad setting without booting into a broken UI. Here is where it lives and a reference you can adapt.

Where the file lives and how to edit it

The main settings file is /userdata/system/batocera.conf. It is a flat list of key=value lines, human-readable and safe to edit over SSH or from the network share while the device is off or idle. The menus and the file are two views of the same state, so a change in one appears in the other. If you ever paint yourself into a corner through the UI, editing this file directly is the escape hatch, and because it sits on userdata it survives every OS update you will ever apply.

The reference configuration

The block below is a complete, working starting point for a 43.1 install: system locale, network, update channel, sensible global emulator defaults, controllers, audio, and one per-system override to show how those work. Adjust the network credentials and timezone to yours, and treat the per-system line as a template for any exceptions you want:

# /userdata/system/batocera.conf  (Batocera 43.1)
# ---- system ----
system.hostname=BATOCERA
system.language=en_US
system.kblayout=us
system.timezone=America/New_York

# ---- network ----
wifi.enabled=1
wifi.ssid=YourNetworkName
wifi.key=YourNetworkPassword
system.samba.enabled=1

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

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

# ---- controllers ----
controllers.bluetooth.enabled=1

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

# ---- per-system override example (SNES gets a CRT shader and 4:3) ----
snes.shaderset=retro
snes.ratio=4/3

Backing it up before you tinker

Before you change anything ambitious, copy this file somewhere off the device: scp it to your desktop, drop it on the network share, or keep it in a notes file. A saved batocera.conf plus your ROM and BIOS folders is your entire setup; with those three in hand, a reflash to a newer release is a restore rather than a rebuild. That is the quiet payoff of the whole download-first model. The OS is disposable and re-downloadable, your configuration is a text file, and your library is yours because you supplied it. Get the checksum right, keep a backup, and the twenty-minute install stays a twenty-minute install for as many releases as you care to follow.