Batocera Download 2026: 43.1 in 12 Steps, 30 Min

There is no Batocera installer. No wizard that makes you click Next four times, no .exe that drops a Start-menu shortcut, no store listing that phones home. "Batocera download" is a slightly misleading search term, and the sooner you internalize why, the fewer hours you lose. What you download is a disk image. You write that image, byte for byte, onto a USB stick or an SD card, and the stick becomes the console. The operating system, the emulators, the front end, and your whole library live on that one piece of removable storage. Pull it out of one machine, push it into another, and the console follows you.

This is a tutorial for doing that correctly on the current release: Batocera 43.1, a point release shipped on 30 May 2026 to patch the 43 "Glasswing" build that landed on 8 May. It is free, it is genuinely open source under CC-BY-NC-SA, and on the right hardware it boots everything from an Atari 2600 up to a PlayStation 2 without asking for a cent or an account. Budget about thirty minutes. Most of that is copying files. The part that needs a functioning brain takes ten.

What "Batocera Download" Actually Means

A whole operating system on a stick

Batocera.linux is not an app you install on top of Windows. It is a complete Linux distribution — kernel 6.15.11 and an LLVM 19.1.7 toolchain under the hood on 43.1 — purpose-built to do exactly one thing: turn a computer, a mini PC, a Raspberry Pi, or an ARM handheld into a games console that boots straight into a controller-driven menu. There is no desktop to babysit, no antivirus, no telemetry. The front end is EmulationStation; the emulators are mostly RetroArch cores plus a stack of standalone engines. The project ships more than 200 systems configured out of the box, and it costs nothing because there is nothing to sell — the whole tree lives publicly at the batocera-linux GitHub repository.

Read that "200+ systems" number the way an adult reads a spec sheet, not the way a marketer writes one. It means the configuration exists for that many platforms. It does not mean your particular board runs all of them at full speed. A Raspberry Pi will happily emulate an NES, a Mega Drive, a PlayStation, and — with some coaxing — an N64 or a Dreamcast. It will not run PlayStation 2 at a playable frame rate, and it will not pretend to. That gap between "supported" and "playable" is where most disappointment lives, and we will keep returning to it.

Version 43.1 "Glasswing," and what changed

The codename "Glasswing" belongs to version 43, released 8 May 2026. The headline feature was a reworked graphics stack: a Wayland-plus-LabWC compositor and an x86_64-v3 image tuned for modern AMD and Intel GPUs, with Nvidia support still flagged experimental. Version 43.1, which arrived three weeks later on 30 May, is not a new codename and not a feature release. It is a stability patch, and a necessary one. It fixed EmulationStation dropping systems and collections from the menu, broken LR-Dolphin options, a Steam and Flatpak regression, LR-MAME light-gun input, Microsoft controllers being misdetected as keyboards, and a storage manager that ignored some partitions. If a 2026 write-up tells you "43.1 Glasswing" as though they are the same thing, it is copying from something that never checked the changelog. The prior major build was v42 "Papilio," from 12 October 2025 — useful context only if you are tracking the release cadence.

Why "download" really means "flash"

Because Batocera runs off the storage you write it to, the download step and the install step are the same physical act: you flash an .img.gz onto a card. That is why every honest "Batocera download" guide is really a flashing guide. It is also why Batocera travels so well between machines — and why, unlike RetroPie, it ships an official Raspberry Pi 5 image rather than making you hand-build one. If you have been fighting the fact that RetroPie's last official image froze at v4.8 back in March 2022, Batocera's you-download-it-and-it-just-boots model is the reason people jump ship. And if you are weighing software emulation against dedicated silicon at all, note that a fixed-function box like the Analogue 3D's FPGA approach to the N64 solves a different problem than a distro that runs 200 systems on commodity hardware — accuracy for one platform versus breadth across all of them.

Prerequisites: Hardware, Storage, Software

The hardware floor

Batocera's minimum is genuinely low, which is the point. The RAM floor is 1 GB, with 2 GB recommended; below 1 GB, EmulationStation will thrash and heavy cores will fall over. For the CPU and GPU there is no single number, because the distro spans a Raspberry Pi 2 to a 16-core desktop. The rule that matters is architecture, not clock speed: you must download the image built for your board, and the choices are not interchangeable. An x86_64 image will not boot on a Raspberry Pi, and a bcm2712 image will not boot on your PC. Get this wrong and you get a black screen, not a helpful error — so we spend a whole section on it below.

For target hardware, sanity-check your ambitions against the silicon. A Pi 4 or Pi 5 is a fine 8-bit-through-PS1 machine and a competent N64 and Dreamcast one. A modern x86 mini PC or handheld will push PS2, GameCube, and — on capable hardware — even PS3. ARM handhelds sit across that whole range depending on the chip; a device like the Retroid Pocket 6, roughly 70% faster than the Pocket 5, is a very different Batocera experience than an entry-level RK3326 unit, even though both show "200+ systems" in the menu.

Storage: 16 GB is the floor, 32 GB is the answer

The USB stick or SD card is the single most under-specified part of a Batocera build, and cheaping out here causes more grief than any other decision. The absolute minimum is 16 GB. The practical recommendation is 32 GB or larger, and there is a concrete reason beyond "more room for games": below 16 GB, Batocera disables its automatic update mechanism outright. A 32 GB card is the smallest size that behaves like a normal, updatable system. Beyond capacity, buy for quality. A genuine A1/A2-rated card from a brand that actually makes flash — not a marketplace listing promising 512 GB for the price of a sandwich — is the difference between snappy menus and a system that corrupts itself in a week. Counterfeit and end-of-life cards are the number-one hardware cause of "my Batocera keeps breaking."

The image itself is a compressed .img.gz of roughly 3 GB that expands to about 8 GB written. On first boot, Batocera automatically grows its data partition to fill whatever card you used, so a 128 GB card gives you ~120 GB of ROM space with no manual resizing. That auto-expand step is load-bearing; interrupting it is a classic self-inflicted wound we cover in troubleshooting.

What you need on the PC doing the flashing

You are flashing from some other working computer, and you need exactly two things on it: a browser to fetch the image, and an imaging tool to write it. For the tool, use balenaEtcher (Windows, macOS, Linux), Rufus (Windows), or dd (Linux and macOS, for people who read man pages for fun). All three do a block-level write and — Etcher and Rufus by default — a verify pass afterward. Do not use anything that "copies files onto" a formatted drive; that is not flashing and it will not boot. Etcher and Rufus both read the .gz directly, so you never need to decompress the download by hand. One good sequence and one 32 GB card, and you are equipped. The official mechanics for all of this are on the Batocera wiki install page, which is the canonical reference when this article and reality disagree.

Picking the Right Image for Your Board

x86_64 and the new x86_64-v3 split

If your target is a PC — a desktop, a NUC, a laptop, a mini PC, or an x86 handheld — you want an x86_64 image. As of Glasswing there are effectively two: the standard x86_64 build, which runs on essentially any 64-bit PC from the last decade, and the newer x86_64-v3 build, tuned for Zen 3 and later chips and for handheld PCs and the Steam Deck. The v3 build assumes CPU instruction-set extensions that older processors lack, so it is faster where it runs and a non-starter where it does not. If you are unsure whether your chip is v3-capable, take the plain x86_64 image; it is the safe default. This matters increasingly as x86 handhelds proliferate — the class of device that now includes things like the Xbox-branded ROG Ally handhelds that shipped in late 2025 is squarely x86_64-v3 territory, and picking the tuned build there is free performance.

Raspberry Pi and the bcm codes

Raspberry Pi images are named by the Broadcom SoC, not by the marketing name, and confusing the two is a common misfire. The mapping you need: Pi 5 is bcm2712, Pi 4 and Pi 400 are bcm2711, Pi 3 is bcm2837, and Pi 2 is bcm2836. Batocera supports the Pi 2 through the Pi 5 in 2026, and — unlike RetroPie — it ships an official, ready-to-flash Pi 5 image rather than asking you to assemble one on top of Raspberry Pi OS. If you already have a Pi and are agonizing over which Batocera to grab, the SoC code on the download page is the only field that matters; match it to your board and move on.

ARM handhelds: rk3588, h700, and friends

The handheld situation is the messiest, because there are dozens of devices and the images are chip-specific. The two codes you will meet most often are rk3588 (the Rockchip SoC in a large slice of mid-to-high-end Android handhelds and TV boxes) and h700 (the Allwinner chip in the Anbernic RG35XX family). Glasswing added or refreshed support for devices including the AYN Thor, the Odin 2 Mini, the Powkiddy X55, the Retroid Pocket 6, and the Radxa Dragon Q6A; the Papilio cycle before it brought the Anbernic RG351V, the Odin 2 and Odin 2 Portal, and the Retroid Pocket Mini V2 and Flip 2, among others. The download page groups these by device name, which is friendlier than the raw SoC code — but if in doubt, find your exact model on the list rather than guessing from a similar-sounding sibling. A wrong ARM image does not boot, it does not warn you, and it wastes a flash.

The 12-Step Flash, Start to Finish

Here is the whole procedure, start to blinking cursor to first game, in twelve numbered steps. Each one carries its rationale, because a step you understand is a step you do not skip. Steps 1 through 4 get you a verified image and a prepared target. Steps 5 through 8 write it and boot it. Steps 9 through 12 configure it and put a game on screen.

Steps 1–4: Download, verify, and prep the target

1. Identify your architecture, then open the download page. Go to batocera.org/download and find the entry for your exact board using the section above. Rationale: the single most common cause of a dead flash is the wrong image, and Batocera ships dozens of architecture-specific builds that are not interchangeable. Two minutes of matching here saves a wasted write.
2. Download the matching .img.gz. It is roughly 3 GB. Rationale: the filename itself is a receipt — it encodes the architecture, the version, and the build date, so you can confirm you actually grabbed 43.1 for the right board and not an archived release. Read it before you flash it.
3. Leave it compressed and confirm the file. Rationale: balenaEtcher and Rufus read .gz natively, so decompressing to an 8 GB loose image first only burns time and a temp file. Confirm the download finished and the size looks right; a truncated image flashes into a brick.
4. Choose your target card and back up anything on it. Use a genuine 32 GB-or-larger card. Rationale: flashing is destructive — every existing byte on that card dies — and sub-16 GB media disables auto-updates. There is no undo on step 5.

The filename in step 2 follows a fixed pattern. The trailing digits are the build date, so yours may differ slightly from the illustrative ones below; the architecture token in the middle is the part that must match your board.

# The download filename tells you exactly what you have:
#   batocera-(arch)-(version)-(date).img.gz

batocera-x86_64-43.1-20260530.img.gz      # PC / mini PC / most laptops
batocera-x86_64_v3-43.1-20260530.img.gz   # Steam Deck & Zen3+ handheld PCs
batocera-bcm2712-43.1-20260530.img.gz     # Raspberry Pi 5
batocera-bcm2711-43.1-20260530.img.gz     # Raspberry Pi 4 / 400
batocera-rk3588-43.1-20260530.img.gz      # RK3588 ARM boxes & handhelds
batocera-h700-43.1-20260530.img.gz        # Anbernic RG35XX (H700) family

Steps 5–8: Write the image and first boot

5. Flash the image with Etcher, Rufus, or dd. Point the tool at the .img.gz, select your card as the destination, and write. Rationale: these tools do a verified block-level copy; a plain file copy onto a formatted volume produces a drive that will never boot. Double-check the destination letter or device node before you commit — this is the step that eats the wrong disk if you are careless.
6. Let it verify, then eject cleanly. Rationale: pulling a card mid-write, or before the OS flushes its cache, corrupts the image in ways that surface as random boot failures later. Wait for "flash complete" and use your OS's eject.
7. Move the card to the target and set it to boot. On a Pi, just insert the card and power on. On a PC, enter the UEFI/BIOS and put USB or the card reader first in the boot order; for some AMD and Nvidia GPUs you may also need to disable Secure Boot. Rationale: the machine will happily boot your old OS instead if you do not tell it otherwise, and people routinely conclude "Batocera didn't work" when the PC simply ignored the stick.
8. First boot — do not interrupt the partition expansion. The image writes ~8 GB; on the very first boot Batocera automatically grows its data partition to fill the card. Rationale: interrupt this — by yanking power because "it's taking a while" — and you get a system that thinks it has an 8 GB disk on a 128 GB card, or worse. Let it finish; it is a one-time event.

On Linux or macOS you can skip the GUI entirely. The one command below streams the compressed image straight through gunzip into the raw device — no intermediate file — and forces a flush so the eject is honest. Get the device node wrong and you overwrite the wrong disk, so run lsblk or diskutil list first and be sure.

# Linux / macOS only. Windows: use balenaEtcher or Rufus instead.

# 1. Find the TARGET DEVICE (the whole disk, not a partition):
lsblk            # Linux  -> e.g. /dev/sdX
diskutil list    # macOS  -> e.g. /dev/diskN

# 2. Write the compressed image straight through gunzip:
gunzip -c batocera-x86_64-43.1-20260530.img.gz | \
  sudo dd of=/dev/sdX bs=4M status=progress conv=fsync

# 3. Flush caches before you pull the card:
sync

Steps 9–12: Expand, configure, and test

9. Configure your controller. At the EmulationStation welcome screen, hold any button on your gamepad until the mapping wizard appears, then follow the prompts. Rationale: nothing else in the interface is usable until an input device is mapped, and a controller that works in the menu but not in games almost always traces back to a rushed mapping here.
10. Set language, timezone, video output, and network. Press START to open the main menu and work through SYSTEM SETTINGS and NETWORK SETTINGS. Rationale: getting Wi-Fi or Ethernet up now is what lets you copy games over the network in the next step instead of shuffling the card back to your PC.
11. Copy your ROMs and BIOS over the network share. With networking live, Batocera exposes a share you drop files into from your main computer — games into roms/<system>, BIOS into bios/. Rationale: this is the intended workflow and it is far less error-prone than pulling the card; the next section covers the exact paths and the _info.txt contract.
12. Update gamelists, then optionally install to internal storage. Press START, open GAME SETTINGS, and run UPDATE GAMELISTS so freshly copied games appear and can be scraped. If you want Batocera off the stick and onto an internal SSD, use SYSTEM SETTINGS → INSTALL BATOCERA ON A NEW DISK. Rationale: the gamelist refresh is what makes new ROMs visible without a reboot, and the internal install turns a live USB into a permanent, faster console.

Want to confirm what board a running system thinks it is — handy before an install or an upgrade? SSH in (default user root, password linux) and ask it directly.

# Log in over SSH and ask the board to identify itself:
ssh root@BATOCERA.local          # password: linux

cat /boot/boot/batocera.board
# -> x86_64        (a PC)
# -> bcm2712       (a Raspberry Pi 5)
# -> rk3588        (an RK3588 handheld)

Adding ROMs and BIOS the Right Way

The network share

Batocera exposes its data partition as a network share the moment it is online, and this is the sanctioned way to load a system. From Windows or macOS, browse to \\BATOCERA\share; from Linux, use smb://BATOCERA.local/share; and if name resolution is being difficult, address the box by IP as \\192.168.1.X\share, substituting whatever address your router handed it. Inside that share you will find the four folders that constitute the entire user-data surface of the system: roms/, bios/, saves/, and system/. Everything you own lives under those four. Back them up and you have backed up your console.

Batocera ships zero copyrighted games and no BIOS files, and that is not an oversight — it is the law working as intended. The distribution is a set of emulators; you supply the content, legally, from media you own. The project can hand you a PlayStation emulator; it cannot hand you the PlayStation BIOS, and a guide that offers to is a guide to close. If you would rather sidestep the sourcing question entirely, dumping your own cartridges is a legitimate path, and the curation problem it creates is real — the same problem you see when a handheld advertises tens of thousands of titles but only a few thousand are actually distinct, working games. Quantity on a spec sheet is not a library.

roms/<shortname> and the _info.txt contract

Games go into a per-system folder named by the emulator's short name, not its friendly name: NES is nes, Super Nintendo is snes, PlayStation is psx, PlayStation 2 is ps2, GameCube is gamecube. Drop a ROM in the wrong folder and the system simply will not show it. When you are unsure what a folder accepts — extensions vary wildly, and some systems want a .chd or an .m3u rather than a raw dump — every ROM directory contains an _info.txt file that spells out the accepted formats. Read it before you copy a hundred files in the wrong container.

# Copy games into the folder named by the system's SHORT NAME:
/userdata/roms/nes/          <- NES / Famicom
/userdata/roms/snes/         <- Super Nintendo
/userdata/roms/psx/          <- PlayStation
/userdata/roms/ps2/          <- PlayStation 2
/userdata/roms/gamecube/     <- GameCube

# Not sure what a folder accepts? Read its _info.txt:
cat /userdata/roms/psx/_info.txt

That last command prints something close to the following. Treat the exact wording as representative — the point is that the folder documents its own accepted formats and tells you where the BIOS must live.

== PlayStation (psx) ==
Accepted ROM extensions:
  .cue .img .mdf .pbp .toc .cbn .m3u .ccd .chd .iso .bin

BIOS files go in: /userdata/bios/
See the wiki for the exact BIOS filenames and MD5 checksums.

BIOS files and the dc_boot.bin trap

BIOS files go in bios/, and some systems flatly refuse to appear in the menu until the required BIOS is present with the correct filename and checksum. The canonical, checksum-accurate list is the libretro BIOS reference and the Batocera add-games-and-BIOS wiki page; use those, not a forum comment, because a BIOS with the wrong hash fails as silently as a missing one. One specific gotcha bites people upgrading from older builds: since v42, Dreamcast expects its BIOS at /userdata/bios/dc/dc_boot.bin — in a dc subfolder, not loose in bios/. If Dreamcast games refuse to launch after an upgrade, that moved path is the first thing to check.

Updating Without Re-Flashing

Updates & Downloads inside EmulationStation

The whole reason to keep a 32 GB-plus card is that you never have to re-flash to move forward. The normal update path is entirely in the GUI: from the system list or a game list, press START and open Updates & Downloads. From there Batocera checks its channel, tells you whether a newer build exists, and applies it in place while preserving your ROMs, saves, and configuration. The mechanics are documented on the official Updates & Downloads wiki page. This is where 90% of users should live; the SSH methods below exist for the other 10% and for the days the GUI updater is being stubborn.

batocera-upgrade over SSH

If you prefer the command line, or the in-GUI updater is refusing to find anything, Batocera exposes the same machinery as a shell command. Per the official docs, on Batocera 5.23 and higher you upgrade — or downgrade — with batocera-upgrade and a mirror URL. The canonical example for a standard x86_64 machine points at the o2switch mirror. Note the /batocera/ segment in the path; guides that drop it send you to a URL that does not resolve, and that specific typo is depressingly common in the wild.

# The GUI updater is the normal path. This is the manual one, over SSH.

# Standard in-place update to the latest STABLE for your arch (5.23+):
batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/last

# Pin or downgrade to a specific numbered release (e.g. v36):
batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/36/

A small piece of lore for the archaeologically inclined: on truly ancient builds (5.7 through 5.22) the equivalent command was recalbox-upgrade.sh, a fossil from Batocera's origin as a Recalbox fork. You will never need it, but if you ever see it referenced, that is what it was.

The manual boot.tar.xz method

For fully offline or air-gapped machines, Batocera supports a hand-fed upgrade. Per the docs, on Batocera 39 and higher you download boot.tar.xz yourself, drop it into /userdata/system/upgrade/, and then run batocera-upgrade manual. This is the method to reach for when the machine that runs Batocera cannot see the internet but you can carry a file to it on a stick. The authoritative reference — including the exact version thresholds — is the Batocera manual-upgrade wiki page.

# Fully manual upgrade, for offline machines (v39+):

#   1. Download boot.tar.xz for your arch from the mirror.
#   2. Copy it into the upgrade folder:
#        /userdata/system/upgrade/boot.tar.xz
#   3. Apply it:
batocera-upgrade manual

# Confirm the running version afterward:
cat /usr/share/batocera/batocera.version

Five Ways a Flash Goes Wrong

Storage and partition mistakes

Pitfall 1: copying the image instead of flashing it. If you double-click the .img.gz, extract it, and drag the resulting file onto a formatted USB drive, you have not made a bootable Batocera stick — you have made a USB drive with a big file on it. Fix: use balenaEtcher, Rufus, or dd to perform a block-level write, and let the verify pass complete. There is no shortcut around a real imaging tool.

Pitfall 2: the sub-16 GB or counterfeit card. A card under 16 GB silently disables auto-updates, and a fake or worn-out card corrupts itself into apparently random failures — games that stop saving, menus that vanish, boots that hang. Fix: buy a genuine 32 GB-or-larger A1/A2 card from a reputable maker, and if an existing build is behaving erratically for no clear reason, suspect the card before you suspect the software.

Wrong image, wrong expectations

Pitfall 3: the wrong architecture. An x86_64 image on a Pi, a Pi image on a PC, or a plain x86_64 image where a device wanted x86_64-v3 — each produces a black screen with no explanation. Fix: match the architecture token in the filename to your board using the picking-your-image section; when unsure on x86, take the plain x86_64 build. Pitfall 4: expecting hardware to exceed itself. "200+ systems" is a configuration count, not a performance promise. A Pi will not run PS2; a low-end ARM handheld will not run GameCube. Fix: match your library to your silicon, and read the distro's device notes before assuming a platform is playable rather than merely present.

The BIOS and decryption tax

Pitfall 5: assuming ROMs are enough. Several systems need more than a game file. PlayStation, PS2, and Dreamcast need correct BIOS files with matching checksums; Dreamcast specifically wants dc_boot.bin in a dc subfolder since v42. And on Glasswing, the 3DS emulator requires decrypted ROMs, with hardware shaders off by default, after the Azahar Plus core was folded back into plain Azahar. Fix: consult the per-system _info.txt and the libretro BIOS list, supply the required BIOS or decrypted dump, and do not conclude the emulator is broken when it is simply waiting for a file you have not provided.

Troubleshooting Table

Boot and storage failures

The failures that keep you from ever seeing the menu are almost always in three buckets: the machine did not boot from the card, the card is wrong or damaged, or the first-boot expansion was interrupted. Work those before you touch anything emulator-specific.

Video, audio, and performance

A black screen after the splash is usually a graphics-mode or arch mismatch, not a broken install. Sluggish games are usually a mismatch between platform and hardware, or a shader you did not mean to enable. The table sorts the most common symptoms by what actually causes them.

Input, network, and upgrade issues

Controller-in-menu-but-not-in-game, an invisible network share, and updates that find nothing are the three that generate the most confused forum posts. All three have mundane causes and one-line fixes.

Advanced Tips: SSH and batocera.conf

SSH access and batocera-settings

Every Batocera box runs an SSH server. Connect as user root with password linux — change that password if the machine is anywhere near an untrusted network — and you have a full shell. The most useful tools once you are in are batocera-settings-get and batocera-settings-set, which read and write the same settings the menus do, without the menus. This is how you script a build, fix a system that boots to a broken video mode you cannot navigate, or flip a setting the GUI buries three submenus deep.

# Read and write settings from the shell, no menus required:
batocera-settings-get audio.volume
batocera-settings-set audio.volume 90

# Bring Wi-Fi up and hand it credentials.
# The plaintext key is replaced with enc:xxxx on the next reboot:
batocera-settings-set wifi.enabled 1
batocera-settings-set wifi.ssid "MyNetwork"
batocera-settings-set wifi.key "MyPassword"

Per-system core and emulator overrides

Batocera's global defaults are sensible, but you will eventually want a specific core for a specific system — a different N64 or PlayStation core than the default, say. In batocera.conf you set this with per-system keys: <system>.core chooses the core and <system>.emulator chooses the emulator, e.g. snes.core and n64.emulator. This is the config-file equivalent of the per-game options in the emulator menu, and it is the clean way to pin choices that survive updates. The full key syntax lives on the batocera.conf reference — worth a read before you start hand-editing.

RetroAchievements, shaders, and bezels

Three global switches are worth knowing because they change the whole system's feel at once. global.retroachievements (plus global.retroachievements.username) enables the achievement layer across every supported core. global.shaderset applies a shader — a CRT filter, most commonly — everywhere, and global.bezel draws artwork around the game area to fill a 16:9 display without stretching a 4:3 image. global.smooth, global.integerscale, and global.rewind round out the set. Set them globally, then override per system where a particular platform wants something different. It is the fastest way to take a raw flash from "functional" to "the way you actually want to play."

A Complete Working batocera.conf

The file

Everything above comes together in one file: /userdata/system/batocera.conf. Below is a complete, annotated configuration you can adapt — networking, a global CRT shader with RetroAchievements, and two per-system core overrides as examples. Lines beginning with # are comments and are ignored.

# /userdata/system/batocera.conf  —  complete working example

# ---- Identity & localization ----
system.hostname=BATOCERA
system.language=en_US
system.timezone=America/New_York

# ---- Networking (Wi-Fi) ----
# wifi.key is stored plaintext until first reboot, then enc:xxxx.
# Escape special characters in the key with a backslash.
wifi.enabled=1
wifi.ssid=MyNetwork
wifi.key=MyPassword

# ---- Updates ----
# Channels: stable (default) or beta.
updates.type=stable

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

# ---- Global emulator behavior ----
global.smooth=1              # bilinear smoothing
global.integerscale=0        # off; let shaders/bezels handle scaling
global.rewind=1              # enable rewind where cores support it
global.shaderset=scanlines   # a CRT-style shader everywhere
global.bezel=default         # artwork bezels around 4:3 content

# ---- RetroAchievements ----
global.retroachievements=1
global.retroachievements.username=YourName

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

# ---- Per-system overrides (examples) ----
# Pin a specific core/emulator for one system only:
snes.core=snes9x
n64.emulator=mupen64plus

What each block does

The identity block sets the hostname the network share answers to and the interface language and clock. The networking block joins Wi-Fi; on the first reboot Batocera rewrites wifi.key to an encrypted enc: form, which is expected and not a bug. The updates line pins you to the stable channel — set it to beta only if you want to test-drive breakage. The global block is the system-wide feel: smoothing, rewind, a CRT shader, and bezels applied to every core at once, with RetroAchievements layered on top. The per-system lines at the bottom demonstrate the override pattern — those two systems ignore the global core choice and use exactly what you named.

Applying it without a reboot fight

After editing batocera.conf, the clean way to apply it is a full reboot, which re-reads the file from scratch and performs the one-time transforms like Wi-Fi key encryption. If you only changed a handful of values and do not want to cycle the box, batocera-settings-set writes the same keys live. What you should not do is edit the file with a Windows editor that rewrites line endings; keep it as plain LF-terminated text — editing over SSH with nano, or through the network share with an editor that preserves Unix line endings, avoids the mangling. Save it, reboot once, and the console you flashed thirty minutes ago comes up configured exactly the way you specified — which was the entire point of downloading Batocera instead of buying a locked box.