Batocera Download 2026: 43.1 in 12 Steps, 30 Min

You do not install Batocera so much as pour it onto a card. That is the entire pitch, and it is genuinely most of the truth: one compressed image, one flashing tool, one reboot, and a dead microSD becomes a console that speaks around two hundred systems. The part nobody prints on the download button is that the thirty minutes of real work is bracketed by two reliable ways to ruin your afternoon — grabbing the wrong image for your hardware, and later running an upgrade command that points at a marketing page instead of a build folder. This guide exists so you do neither.

We are writing against a specific target: Batocera 43.1, the current stable release as of this writing, dated 30 May 2026. It is a small, boring, welcome release, and "boring" is the highest compliment you can pay an emulation OS. Below is the whole job, in order, and then the parts of it that actually bite.

1. Identify your exact hardware target.
2. Download the matching image from batocera.org.
3. Understand the .img.gz you just received.
4. Verify the published checksum before you trust it.
5. Choose a flashing tool.
6. Flash the SD card, USB stick, or SSD.
7. Eject cleanly and seat the media.
8. First boot and watch userdata auto-expand.
9. Pair a controller.
10. Get on the network and open SSH.
11. Copy ROMs into the right per-system folders.
12. Add BIOS files you own and refresh the gamelists.

Twelve steps. The rest is maintenance, taste, and knowing which corners the project has quietly moved since last year.

What Batocera Actually Is

An operating system, not a ROM pack

Batocera.linux is a self-contained, read-only Linux distribution whose only job is to boot straight into EmulationStation and hand your controller to a stack of emulators. It ships as a single image you write to removable media; the host machine's internal drive is never touched unless you explicitly ask for it. That read-only design is deliberate. The system partition is immutable, your data lives on a separate writable /userdata partition, and an "upgrade" swaps the former while leaving the latter alone. This is why a botched update rarely costs you a save, and why the project can be reckless-sounding about telling you to just reflash.

The other half of that design is legal, and it is worth saying plainly because most download pages are coy about it. Batocera contains zero games and zero copyrighted BIOS. It is an empty console. Everything that makes it interesting — the ROMs, the firmware dumps a PlayStation or a Sega CD needs to boot — you supply yourself, ideally from hardware you own. The distribution is licensed CC-BY-NC-SA and copyrighted 2016–2026; the content is your problem and your liability. If you want the defensible path to a legal library, the honest answer is to dump your own cartridges, which is a project unto itself and one we cover in the Retrode cartridge-dumping walkthrough.

Where it sits: RetroPie, Recalbox, and the butterfly problem

Batocera descends from the Recalbox family, and if you ever wondered how closely, run its legacy upgrade path and watch it call a script literally named recalbox-upgrade.sh. It has since diverged hard on breadth and hardware coverage. Compared with RetroPie — still the GitHub star champion at roughly 10,381 stars against Batocera's ~3,084 as of June 2026 — Batocera is the one that actually ships current images. RetroPie's last full image is v4.8 from March 2022 and has no Raspberry Pi 5 build; Batocera and Recalbox both do. If you want the pure libretro/RetroArch layer underneath any of these front-ends, that is its own rabbit hole, covered in our RetroArch cores install guide.

As for the butterfly problem: the project names its releases after Lepidoptera. Batocera 42 was "Papilio" (12 October 2025), the swallowtail genus. Batocera 43 is "Glasswing" (8 May 2026), after Greta oto, the butterfly with transparent wings. This matters only because content farms keep mislabeling the point release — more on that in a moment.

What "download" actually means here

Because the OS and your data are separate, "downloading Batocera" splits into two workflows that people constantly conflate. The install workflow is a one-time image write to fresh media. The update workflow never touches your card's data — it fetches a new system image over the network or from a build folder and hot-swaps it. The commands, the files, and the failure modes differ. Almost every support thread that starts "my Batocera download won't work" is someone running an install procedure when they wanted an update, or vice versa. Keep the two in separate mental boxes and this whole thing gets easier.

The 2026 Version Landscape

43 "Glasswing" versus 43.1: the codename trap

Here is the single most-repeated error in the 2026 Batocera coverage, and you should learn it as an inoculation: "Glasswing" is the name of the 43 branch, not of 43.1. Batocera 43 shipped on 8 May 2026 as Glasswing. Batocera 43.1 followed on 30 May 2026 as a bug-fix point release on that same branch. Any guide that tells you "43.1 Glasswing dropped on May 30 as a major release" has fused two dates and two release tiers into one wrong sentence. Several AI-slop content mills — the usual suspects with names built from "tech," "insider," and "shattered" — do exactly this, which is a decent reason to distrust everything else on the page. Cross-check dates against the official Batocera changelog on GitHub and move on.

What 43.1 actually fixed

43.1 added no features. That is the point of it. It is a stability patch that cleaned up regressions the 43 launch introduced, and the fix list reads like a triage board: EmulationStation dropping whole systems and making collections vanish; libretro Dolphin's options menu broken; a Steam and Flatpak launching issue; the Apple II GS falling out of MAME; libretro MAME light-gun input broken; Microsoft controllers being misdetected as keyboards; and the storage manager silently ignoring some partitions. If you installed 43.0 and something felt haunted — a console that was there yesterday and gone today, an Xbox pad that typed instead of played — 43.1 is the exorcism. Install it.

What shipped inside the 43 branch

The Glasswing branch itself is the substantive release. Its headline was a graphics overhaul for AMD and Intel systems on the x86_64-v3 image, a move to Wayland with the LabWC compositor, and experimental Nvidia support. Under the hood it runs kernel 6.15.11 and LLVM 19.1.7, with fresh emulator builds across the board — Genesis Plus GX from a December 21 2025 build, Fceumm from September 12 2025, the original Xbox emulator Xemu at v0.8.96, and Xenia pinned to commit 1d7973a. It also carried breaking changes you must plan around, which we return to under Pitfalls: DraStic is gone, 3DS ROMs now must be decrypted, and "Azahar Plus" collapsed back into "Azahar." None of that stops a clean install; all of it can wreck an in-place upgrade if you assumed your saves were portable.

Prerequisites: Hardware and Software

Hardware floor: storage is the real constraint

Batocera is undemanding in the ways people worry about and demanding in the way they ignore. On RAM, the official wiki declines to publish a hard floor, and for good reason: the project ships images down to a 512 MB Raspberry Pi Zero 2 W. RAM is rarely what stops you; 2 GB is comfortable and lets the heavier cores — PS2, GameCube, the original Xbox — breathe. Storage is the number that actually gates you. The official install page states 16 GB as the minimum and 32 GB as recommended for full functionality, and it is blunt that automatic updates cannot run on a 16 GB device. Read that as: 16 GB boots, 32 GB is the practical floor if you ever want the built-in updater to work. Buy the 64 GB card; the price delta is a rounding error and you will fill it.

You also need to know your exact device family before you download, because Batocera ships a different image per architecture. There is no universal build. The download page currently offers x86_64 for standard PCs, laptops, NUCs and Intel Macs; x86_64-v3 for the Steam Deck and modern handheld PCs; a 32-bit x86 legacy image; the full Raspberry Pi range from the Zero 2 up through the Pi 5 and CM3/CM3+; plus Odroid, Orange Pi, the Ayn Odin 2, several Retroid Pocket models, Anbernic RG handhelds, and assorted Rockchip boards. Handheld emulation devices are their own dense market — if you are choosing hardware rather than reusing a PC, our Miyoo Mini Plus library breakdown is a useful reality check on what a cheap ARM handheld actually delivers.

Software you need before you start

The full prerequisite list is short and version-specific:

• Batocera 43.1 image (30 May 2026), from the official download page. Nowhere else.
• A flashing tool. The wiki's primary recommendations are the Raspberry Pi Imager and USBImager; the widely used cross-platform alternative is Balena Etcher from etcher.balena.io. On Windows, Rufus works; on Linux and macOS, plain dd works if you are careful. All of these read .img.gz directly — you do not decompress first.
• A card reader and the target media itself: 32 GB or larger, ideally an A2-rated microSD or, better, a USB 3.0 SSD.
• An SSH client for the upgrade and configuration steps. The default login is user root, password linux. Change it.
• Optionally, legal BIOS files you dumped yourself, staged and ready to copy after first boot.

The legal prerequisite nobody lists

Treat this as a checklist item because it is one. Batocera will happily boot without a single ROM, and it should stay that way until you supply content you are entitled to. Firmware images — the PlayStation scph files, the Sega CD BIOS, the various handheld boot ROMs — are copyrighted and are not distributed with the OS. The libretro project maintains a reference for exactly which files each core expects, their names, and their hashes, at the libretro BIOS documentation; use it to confirm you have the right files, not as a shopping list. The defensible acquisition path for all of it is your own hardware. This is not legal advice; it is the posture that keeps the hobby a hobby.

Steps 1-3: Pick the Right Image

Step 1 — Identify your exact hardware target

Rationale: flashing the wrong architecture is the number-one first-attempt failure, and it fails in the most confusing way possible — a black screen with no error, because the CPU cannot execute the boot code. On a PC the split that catches people is x86_64 versus x86_64-v3. The v3 image is compiled for newer AVX2-class processors (Zen 3 and up, the Steam Deck, modern handheld PCs) and will not boot on an older chip; the plain x86_64 image is the broad-compatibility build. When in doubt on a PC, take plain x86_64 first and only move to v3 once you have confirmed the hardware.

If you already have any Batocera install running — even the one you are about to replace — the board name is one command away over SSH. This is also exactly the string you will need later to build an upgrade URL:

$ cat /boot/boot/batocera.board
x86_64

Common outputs map cleanly to download targets: x86_64 and x86_64-v3 for PCs, bcm2712 for the Pi 5, bcm2711 for the Pi 4/400, bcm2837 for the Pi 3, rk3588 for many Rockchip handhelds, and h700 for the Anbernic RG35XX class. Write yours down.

Step 2 — Download the matching image from batocera.org

Rationale: the official download page is the only source that guarantees an unmodified image with a checksum beside it. In 2026 the homepage call to action reads plainly — "Get Batocera.linux 43.1" — and the download page lists "Current version: 43.1." Pick your hardware category, then your specific device, and you will be handed a compressed image. The filename follows a predictable pattern, batocera-(arch)-(version)-(date).img.gz, for example batocera-x86_64-43-20260530.img.gz. That embedded date is your ground truth for which build you actually pulled; screenshot it. Do not download from a mirror homepage, a forum attachment, or a YouTube description link. Content mills reupload these images with "optimizations" baked in, and you have no way to audit them.

Step 3 — Understand the .img.gz you just received

Rationale: knowing what the file is prevents two wasted hours. The download is a gzip-compressed raw disk image, roughly 3 GB compressed, which expands to about 8 GB written to the card. Every modern flashing tool — Etcher, Raspberry Pi Imager, Rufus — decompresses it on the fly, so you should not manually unzip it first. The only time you decompress by hand is if some older tool demands a raw .img:

# You almost never need this. Etcher and Pi Imager read .img.gz directly.
# Only if a tool refuses the compressed file:
$ gunzip -k batocera-x86_64-43-20260530.img.gz
# -k keeps the compressed original.
# Expect ~3 GB in, ~8 GB out.

Steps 4-7: Verify and Flash

Step 4 — Verify the checksum before you trust it

Rationale: a half-downloaded or bit-rotted image produces a device that boots almost right, then corrupts saves or hangs on random games — the worst class of bug, because it looks like a hardware fault. Batocera publishes a checksum next to every image on the download page. Compute the hash of what you actually received and compare the two strings; if they differ by one character, delete the file and download again.

# Linux / macOS
$ sha256sum batocera-x86_64-43-20260530.img.gz
3f9c1e0b7a...d4e2a71b4d  batocera-x86_64-43-20260530.img.gz

# Windows (PowerShell)
PS> Get-FileHash .\batocera-x86_64-43-20260530.img.gz -Algorithm SHA256

Expected result: the printed hash matches the one on the download page character-for-character. The hash shown above is illustrative — use whatever the site lists for your specific build and date. If the page lists an MD5 instead, swap sha256sum for md5sum. A mismatch is never noise; it is always a re-download.

Step 5 — Choose your flashing tool

Rationale: the tool determines how much can go wrong at the one irreversible step. The wiki's first recommendations are the Raspberry Pi Imager and USBImager, both of which are hard to misuse. The most common cross-platform choice remains Balena Etcher, which validates the write automatically after flashing — a genuinely useful feature that catches a failing card before you have wasted a boot cycle on it. On Windows, Rufus is faster and offers more knobs than you need. On the command line, dd is fine for people who have used dd before and catastrophic for people who have not, because a wrong of= target overwrites your system drive without a prompt. Match the tool to your nerve.

Step 6 — Flash, and Step 7 — eject cleanly

Rationale for Step 6: this is the point of no return, so slow down and confirm the destination. In Etcher: select the .img.gz, select the correct removable device — read the size, not just the letter — and flash. It will decompress, write, and verify in one pass. A 32 GB card over a decent USB 3.0 reader lands in a few minutes.

Rationale for Step 7: pulling the media mid-flush is how you produce a card that passes verification and still boots wrong. Let the tool finish its verify stage, then use your OS's safe-eject before you physically remove it. On Linux, a manual sync followed by unmount is the same idea:

# Linux, after the write completes
$ sync
$ umount /dev/sdX*   # replace sdX with YOUR device, not a guess

Steps 8-10: First Boot and Controllers

Step 8 — First boot and userdata expansion

Rationale: the first boot does invisible one-time work you must not interrupt. Seat the freshly flashed media in the target device and power on. On first boot Batocera detects the free space on your card and automatically expands the /userdata partition to fill it, then reboots itself once. This is why an 8 GB image written to a 64 GB card yields ~56 GB of usable ROM space with no manual partitioning. Do not yank power during this expansion; if you do, you get a device with a tiny data partition and mysterious "disk full" errors later. Wait for EmulationStation's theme to settle before you touch anything. If the screen is black past a minute, jump to the Troubleshooting table — it is almost always the wrong architecture from Step 1.

Step 9 — Pair a controller

Rationale: nothing else is navigable until input works, and 43.1 specifically fixed a class of input bug worth knowing about. Most USB pads are recognized instantly — plug in, press a button, follow the on-screen mapping prompt. For Bluetooth, go to the main menu (press Start), then Controller Settings → Pair a Bluetooth Controller, and put the pad in pairing mode. If you are on 43.0 and an Xbox controller is behaving as if it were a keyboard — menus scrolling on their own, buttons typing — that is the exact regression 43.1 patched. Update, or expect ghosts.

Step 10 — Network and SSH

Rationale: the network is how every subsequent step gets easier, from copying ROMs to running the upgrade commands. Join Wi-Fi from Network Settings, or just plug in Ethernet and skip the typing. Once online, confirm SSH: from another machine, connect to root@batocera.local (password linux) or to the device's IP. Change that password immediately — a retro console with a default root login sitting on your LAN is exactly the kind of thing that ages badly. With SSH open you can run batocera-check-updates, edit config files, and manage the box headless, which is how experienced users run these things.

# From your desktop
$ ssh root@batocera.local
# password: linux  (change it: run 'passwd' once connected)

# Confirm the box sees itself correctly
$ cat /boot/boot/batocera.board
$ batocera-check-updates

Steps 11-12: ROMs and BIOS

Step 11 — Where ROMs actually go

Rationale: put a ROM in the wrong folder and it simply will not appear — no error, no system, nothing — and this accounts for most "my games don't show up" threads. Batocera exposes its data partition as a network share the moment it is online. Reach it by name or IP:

# Windows Explorer / macOS Finder:
\\BATOCERA\share

# Linux file manager:
smb://BATOCERA.local/share

# Or straight to the IP:
\\192.168.1.50\share

Inside share the layout is rigid and unforgiving about naming. Each system has its own folder keyed to a specific short name, and the ROM has to land in the matching one:

/userdata (exposed as \\BATOCERA\share)
|-- roms/
|   |-- snes/       # Super Nintendo
|   |-- nes/        # Nintendo
|   |-- megadrive/  # Sega Genesis / Mega Drive
|   |-- psx/        # PlayStation
|   |   \-- _info.txt   # lists the formats THIS system accepts
|   \-- n64/
|-- bios/           # firmware you dumped yourself
|-- saves/
\-- system/
    \-- batocera.conf

Step 12 — BIOS files and updating gamelists

Rationale: some systems refuse to launch a single game until their firmware is present, and new ROMs will not always show without a rescan. Copy the BIOS files you own into share/bios/, matching the exact filenames the emulators expect — the built-in BIOS Checker under System Settings (or the libretro BIOS reference) tells you which are missing and what to name them. After copying ROMs, trigger a rescan so EmulationStation rebuilds its lists: press Start, then Game Settings → Update Gamelists. For the authoritative, per-system placement details, the official add-games-and-BIOS page is the reference to keep open.

The _info.txt you keep ignoring

Every roms/[system] folder ships with an _info.txt file, and it is the single most-ignored, most-useful file on the whole card. Open it and it tells you precisely which file extensions and formats that system will accept — whether the Neo Geo folder wants a .zip or the PSP folder wants an .iso or a .chd. When a ROM you are certain is good refuses to appear, read that folder's _info.txt before you blame the emulator. Nine times out of ten the file is a format the core does not load, or it is compressed in a way the system does not expect.

Upgrading and Downgrading

batocera-check-updates and the built-in updater

Once you are on 43.1, staying current is a two-command habit, and it is where the OS/data separation pays off — upgrades never touch your ROMs, saves, or config. The gentle path is the graphical updater under Updates & Downloads in the main menu, which is fine if your device has more than 16 GB of storage (recall that auto-updates refuse to run on a 16 GB card). From the command line, check first:

$ batocera-check-updates
# Representative output:
# A newer version is available.
# Installed: 43   Available: 43.1

Treat that output as illustrative — the exact wording varies by build — but the intent is clear: it tells you whether a newer build exists for your architecture before you commit to pulling it.

batocera-upgrade with a build-folder URL

The command that matters, and the one people misuse, is batocera-upgrade. It takes a URL that points at a build folder, not a homepage. This is the distinction that eats afternoons: https://batocera.org is a website; https://mirrors.o2switch.fr/batocera/x86_64/stable/last is a build folder. Feed it the latter, matched to the architecture you confirmed back in Step 1:

# Upgrade in place to the latest stable for THIS architecture
$ batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/last

# It downloads the new system image, stages it, and asks you to reboot.
# /userdata is left completely untouched.

Swap x86_64 for your board's mirror path. The official manual-upgrade page documents the full mirror layout and is the canonical source when a path changes.

Manual boot.tar.xz and downgrading

Two situations need the manual path: a device with no reliable internet, and a downgrade after a release breaks something you rely on. For the offline case, download the boot.tar.xz for your build, drop it into /userdata/system/upgrade, and run the manual form. For a downgrade, point batocera-upgrade at an older build folder — the mirror keeps prior versions under numbered paths:

# Offline / manual upgrade (Batocera 39+):
# 1. copy boot.tar.xz into /userdata/system/upgrade/
# 2. then:
$ batocera-upgrade manual

# Downgrade example: roll back to version 36 on x86_64
$ batocera-upgrade https://mirrors.o2switch.fr/batocera/x86_64/stable/36/

Because the data partition is never in play, a downgrade is genuinely safe as an escape hatch. That is the whole design philosophy showing through: the system is disposable, your data is not.

Common Pitfalls and Fixes

Wrong architecture, right stubbornness

Pitfall 1: flashing x86_64-v3 onto an older CPU, or a Pi 4 image onto a Pi 5. The symptom is a black screen or an instant reboot loop with no error text, and people respond by re-flashing the same wrong image more carefully. Fix: go back to Step 1, confirm the board name, and download the matching build. On a PC that means dropping from v3 to plain x86_64 if your processor predates AVX2.

Pitfall 2: the corrupted-download tail. A flash that verifies but boots into random hangs and save corruption is almost always a bad image that you never checksummed. Fix: do Step 4. Every time. A one-character hash mismatch is a guaranteed re-download, not a maybe.

Pointing batocera-upgrade at a homepage

Pitfall 3: running batocera-upgrade https://batocera.org or some mirror's index page and watching it error or stall. The command wants a build folder ending in a version or last, not a marketing site. Fix: use the mirror path pattern — .../batocera/[arch]/stable/last for current, .../stable/[number]/ for a specific version. If you are unsure of the exact mirror layout, open the official upgrade page rather than guessing.

Pitfall 4: the 16 GB update wall. You installed to a 16 GB card, everything works, and then the updater is greyed out or refuses to run. This is documented behavior, not a bug — auto-update needs more than 16 GB. Fix: reflash to a 32 GB-or-larger card, or perform upgrades manually via boot.tar.xz, which sidesteps the auto-updater's space check.

Assuming your saves are portable

Pitfall 5: upgrading to the 43 branch and discovering your handheld games no longer launch or your saves evaporated. This is the breaking-change tax. Version 43 removed DraStic; Nintendo DS now runs on melonDS, and DraStic saves do not transfer to it. It also began requiring 3DS ROMs to be decrypted, with hardware shaders off by default, and folded "Azahar Plus" back into "Azahar." Fix: before a major upgrade, back up /userdata/saves; after it, re-dump or decrypt 3DS content and accept that DS saves may need a fresh start. This kind of firmware discipline — read the changelog, back up before you jump, don't assume forward compatibility — is the same habit that separates a stable retro setup from a haunted one, a theme we go deep on in the Analogue 3D firmware history.

Troubleshooting Table

The table

Most first-week problems resolve to one of these. Work top to bottom; the common causes are ordered by how often they are the actual culprit.

Reading the logs

When the table does not cover it, the logs do. EmulationStation and per-emulator logs live under /userdata/system/logs/. A game that launches to a black screen and drops back to the menu almost always wrote its reason there — a missing BIOS line, an unsupported format, a core that failed to load. Over SSH, tailing the relevant log while you launch the game turns a guess into a diagnosis:

$ ls /userdata/system/logs/
$ tail -n 40 /userdata/system/logs/es_launch_stdout.log

When to reflash versus when to repair

Because the system partition is disposable, the calculus is different from a normal Linux box. If the OS itself is misbehaving — not your config, the OS — reflashing 43.1 to a fresh card and copying /userdata back is often faster than debugging. Repair, rather than reflash, when the problem is clearly in your data: a bad ROM, a missing BIOS, a config typo. The rule of thumb: system weirdness gets a reflash, content weirdness gets a fix.

Advanced Tips

Install to internal disk

Running from removable media is the default and it is fine, but a permanent build — an old NUC or mini-PC turned dedicated console — benefits from living on the internal drive. Boot Batocera from the USB stick you flashed, then go to System Settings → Install Batocera on a New Disk, pick the internal target, and let it clone across. This wipes the destination drive, so confirm the target twice; it is the one operation in this whole guide that touches a disk you might care about. Afterward, remove the USB stick and boot straight off internal storage. Performance improves, and an SSD makes the heavier cores markedly happier.

Network shares and headless management

The SMB share is not just for the initial ROM dump — it is how you run the box day to day without ever plugging in a keyboard. Combined with SSH, you can manage a Batocera install that lives in a cupboard entirely from your desktop: copy ROMs over the network, edit batocera.conf remotely, trigger updates, and pull logs. For anyone comparing this software route against dedicated FPGA hardware — which trades this flexibility for cycle-accurate silicon — the contrast is exactly what we lay out in the MiSTer Multisystem 2 breakdown. Software emulation wins on breadth and price; FPGA wins on latency and accuracy. Batocera is firmly the breadth play.

Overlays, shaders, and per-system overrides

The configuration model is hierarchical, and once you understand it you stop fighting it. Global defaults live in batocera.conf; any setting can be overridden per system by prefixing it with the system's short name, and many can be pushed down to a single game. Want CRT scanline shaders on your SNES library but pixel-sharp output on GBA? Set a global default and override SNES specifically. Want the N64 to use a more accurate core than the default? One line does it:

## In /userdata/system/batocera.conf
global.shaderset=none
snes.shaderset=scanlines
n64.core=parallel_n64
psx.core=mednafen_psx_hw
psx.mednafen_psx_hw.internal_resolution=4x

The core names (parallel_n64, mednafen_psx_hw, and the rest) are the same libretro cores documented across the RetroArch ecosystem; if you want to understand what each one trades in accuracy versus speed, that is the core-by-core territory of our RetroArch cores guide.

A Complete batocera.conf

A working baseline

Here is a complete, sane batocera.conf for a 43.1 install — a real starting point rather than a fragment. It lives at /userdata/system/batocera.conf and is plain key=value text. Treat the exotic keys as templates and confirm anything unfamiliar against the Batocera source and wiki; the common ones below are stable across the 43 branch.

## /userdata/system/batocera.conf  --  a sane 43.1 baseline

## --- System / UI ---
system.language=en_US
system.kblayout=us
audio.volume=90
audio.device=auto

## --- Network ---
wifi.enabled=1
wifi.ssid=YourNetworkName
wifi.key=YourWiFiPassword

## --- Global emulator defaults ---
global.retroachievements=1
global.retroachievements.username=YourRAName
global.ratio=auto
global.rewind=0
global.smooth=0
global.shaderset=none
global.integerscale=1

## --- Per-system overrides ---
snes.core=snes9x
snes.shaderset=scanlines
nes.core=fceumm
megadrive.core=genesisplusgx
n64.core=parallel_n64
psx.core=mednafen_psx_hw
psx.mednafen_psx_hw.internal_resolution=4x
nds.core=melonds          # DraStic is gone as of v43
3ds.core=azahar           # Citra is retired; ROMs must be decrypted

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

Per-system tweaks worth keeping

Two overrides above earn their place. psx.mednafen_psx_hw.internal_resolution=4x renders PlayStation games at four times native resolution through the hardware-accelerated Beetle PSX core — the single highest-impact quality tweak for that library, at a cost most modern hardware absorbs easily. snes.shaderset=scanlines applies a CRT-style shader only to the SNES, leaving everything else sharp; it is the difference between "emulator" and "the thing you remember." Add per-system lines sparingly and test each one, because a shader that flies on a PC will crawl on a Pi.

Back it up before every upgrade

The last habit is the one that saves you: before any major version jump, copy this file and your saves off the device. The system partition is disposable by design, but batocera.conf encodes hours of tuning, and a fresh install starts blank. Over SSH it is one command — cp /userdata/system/batocera.conf /userdata/saves/batocera.conf.bak — or drag it off the SMB share. Do it before you run batocera-upgrade, not after you wish you had. A retro console is only as good as the last configuration you can restore, and Batocera makes restoring trivial precisely because it keeps your data and its own guts in separate boxes. Respect that separation and 43.1 will outlast several of the cards you flash it onto.