Batocera Download 2026: 43.1 in 12 Steps, 30 Min

Batocera.linux is a single-purpose operating system with a chip on its shoulder. You copy one image to a USB stick or an SD card, you point it at a pile of ROMs, and a generic computer — or, in the project's own phrasing, a nano computer — stops being a computer and becomes a games console. No Windows license to activate, no Steam client to update, no desktop to babysit. The official site describes it as an open-source and completely free retro-gaming distribution, and in 2026 that word free is carrying more weight than usual.

This is a download tutorial, so we are going to be precise about the thing most guides fudge: which file you actually click. The official download page lists 43.1 as the current version and was refreshed on 2026-08-26. That is the target. Everything below assumes you want a verified, bootable 43.1 image on real hardware in about half an hour, without bricking a memory card or discovering three days later that you flashed the wrong architecture. Twelve steps. One coffee.

Why Batocera, and When to Walk Away

Before you download anything, be honest about whether Batocera is the right shape for your problem. It is a fixed-function appliance OS. That is its entire virtue and its entire limitation.

What Batocera Actually Is

Batocera is a read-only Linux image built around EmulationStation and a large stable of emulators, most of them RetroArch cores from the libretro project. The system partition boots read-only, and all of your mutable data — ROMs, BIOS files, saves, scraped artwork, your batocera.conf — lives on a separate /userdata partition that the image expands to fill your card on first boot. That split is the whole design philosophy: the OS is disposable and re-flashable, your data is not. It means you can nuke and reinstall the system in ten minutes and lose nothing, which is the correct way to run an appliance.

Because so much of the emulation layer is RetroArch underneath, understanding what cores are and which ones matter pays off quickly. If you have never wrangled libretro cores by hand, our walkthrough on installing RetroArch cores in 2026 is a useful companion — Batocera hides most of that plumbing, but the vocabulary is identical.

The 43.1 "Glasswing" Release

The changelog records Batocera 43.1 - 2026/05/30 as the current point release. Community installation guides from July 2026 identify the base Batocera 43 release under the codename "Glasswing," stable as of 2026-05-08, with the 43.1 point release following on 2026-05-30. The project even publishes its own roadmap: a status page titled "batocera 43 status (approximative dates)" went up on 2026-06-13. So the version you are chasing is not a rumor or a nightly — it is the documented, dated stable branch, and 43.1 is where you want to land.

When You Should Reach for Something Else

Batocera is not a magic accuracy machine. It runs the same emulators everyone else runs; it just configures them for you. If your goal is cycle-accurate N64 output on a big panel, software emulation on a mid-range box will not touch a good FPGA or a dedicated device — see what an Analogue 3D firmware upscaler does with N64 in 2026 before you assume a $150 mini-PC will match it. If you want zero-configuration hardware-level accuracy, the MiSTer FPGA community is a different and more expensive road. And if you just want a couch-free PS1 handheld and not a project, a Miyoo Mini Plus with its PS1 ceiling or a Retroid Pocket already boots into a menu out of the box. Batocera is for the person who has hardware lying around and wants to weaponize it. If that is you, keep reading.

Prerequisites: Hardware, Storage, Software

Three things determine whether this goes smoothly: the machine you are installing onto, the card or drive you flash, and the tools on the computer doing the flashing. Get these wrong and no amount of following steps will save you.

Hardware Requirements by Architecture

Batocera is 64-bit only on the PC side — a 64-bit CPU is not a suggestion, it is the entire reason the file is called x86_64. Practically, aim for a machine from the last decade with a GPU that speaks OpenGL, 4 GB of RAM as a comfortable floor (2 GB will technically boot but you will feel it), and a wired or supported wireless network adapter so you can copy games across without pulling the card out repeatedly. On the single-board side, Batocera maintains distinct builds for Raspberry Pi and Qualcomm-based hardware, so "a Pi" is not specific enough — you need to know the exact board, because a Pi 4 and a Pi 5 take different images. More on that in the next section.

Storage: SD Card vs USB vs SSD

This is where most first installs die. Batocera does a lot of small random reads and writes, and cheap or counterfeit SD cards fail at exactly that workload. Buy a genuine, name-brand A1 or A2-rated card of at least 32 GB (64–128 GB if you actually want a library), or better yet flash to a USB 3.0 SSD for x86 machines, which is dramatically faster and does not wear out in a season. Whatever you pick, budget for the games: the OS itself fits in a couple of gigabytes, but the /userdata partition expands to fill the device, and ROM sets — especially disc-based systems — are enormous.

The Software You Need First

On the computer doing the flashing, you want exactly one of the following, plus a way to check a hash:

• balenaEtcher (current 2.x release) — cross-platform, reads .img.gz directly so you do not decompress first. The path of least resistance.
• Rufus (latest 4.x series) — Windows only, faster, more options, and it will not let you accidentally pick your system drive as easily.
• A hashing tool — md5sum on Linux, md5 on macOS, or CertUtil -hashfile FILE MD5 on Windows. You already have one; you just have not used it.

Download links for the two flashers, straight from the projects: balenaEtcher and Rufus. Do not get either from a random "download" ad farm. This is a security tool that writes raw bytes to disks; get it from source.

Choosing the Right Image (x86_64 Isn't Always It)

Here is the single most common failure in the entire process: downloading the wrong architecture, flashing it perfectly, and getting a black screen or a device that will not POST. The image is not universal. Match it to your silicon.

Decoding the Filename

Batocera images follow a rigid, legible naming pattern: batocera-[architecture]-[version]-[date].img.gz. For the current PC build that reads out as batocera-x86_64-43.1-20260530.img.gz. Read it left to right and it tells you everything:

# batocera-[architecture]-[version]-[date].img.gz
#
#   architecture -> x86_64      (which CPU family)
#   version      -> 43.1        (the point release)
#   date         -> 20260530    (2026-05-30 build date)
#   .img.gz      -> gzip-compressed raw disk image

batocera-x86_64-43.1-20260530.img.gz
batocera-x86_64-43.1-20260530.img.gz.md5

That 20260530 date lines up exactly with the 43.1 - 2026/05/30 changelog entry. If the date on the file you grabbed does not match the version you think you are installing, stop and re-check the download page. The .md5 sitting next to it is not decoration — it is step six.

The 2026 Architecture Table

The official torrent index carries 43.1 images for multiple hardware families. Here is how the six most relevant ones map to real devices:

Build (architecture)	Target hardware	Pick this if...
x86_64	Any 64-bit PC, mini-PC, laptop, or USB SSD build	You have an Intel/AMD machine and want the safe, universal default
zen3-x86-64-v3	Modern AMD (Zen 3+) and other x86-64-v3-capable CPUs	Your CPU supports the v3 feature level (AVX2 era) and you want the tuned build
bcm2711	Raspberry Pi 4, Pi 400, CM4	You have a Pi 4-class board (Broadcom BCM2711)
bcm2712	Raspberry Pi 5	You have a Pi 5 (Broadcom BCM2712)
sm8250	Qualcomm Snapdragon 865 devices	Your handheld or SBC uses the SD865
sm8550	Qualcomm Snapdragon 8 Gen 2 devices	Your handheld or SBC uses the SD 8 Gen 2

Two clarifications the guides always skip. First, bcm2711 and bcm2712 are not interchangeable — a Pi 5 image will not boot a Pi 4 and vice versa. Second, zen3-x86-64-v3 is an optimization, not a requirement. The v3 microarchitecture level requires AVX2 and friends, which means Intel Haswell (2013) and AMD Zen (2017) and newer support it — but if you are not certain, take the plain x86_64 build. It runs everywhere v3 runs, just without the last few percent of tuning. The existence of both the Qualcomm (sm8250, sm8550) and Pi builds is the proof that Batocera is not a PC-only download: the project ships separate release assets and update packages per device family.

Download, Torrent, or md5

Each release on the official downloads page exposes three buttons: download, torrent, and md5. Use download for the direct HTTP grab. Use torrent when the mirror is slow or you are pulling a large image on a flaky connection — BitTorrent is self-verifying and resumes cleanly, which for a multi-gigabyte file is worth the extra thirty seconds of setup. And always grab the md5, because a corrupted download is indistinguishable from a good one until it fails to boot at the worst possible moment. Get all three from the source: the official Batocera site.

The 12-Step Install: Download to First Boot

This is the spine of the tutorial. Twelve numbered steps, each with the reason it exists — because "do this" without "because" is how you end up cargo-culting a broken install. Later sections drill into the flashing and first-boot mechanics with actual commands.

1. Identify your exact hardware. Not "a PC," but the CPU family; not "a Pi," but the board. Rationale: architecture mismatch is the number-one cause of a non-booting card, and it is invisible until boot.
2. Go to the official downloads page at batocera.org. Rationale: you are about to run a tool that writes raw sectors to a disk; the provenance of the image matters more than for almost any other download you make this year.
3. Select your device family and pick the matching architecture. PC users take x86_64 (or zen3-x86-64-v3 if certain); Pi users take bcm2711 or bcm2712 by exact model. Rationale: this is the decision the whole install rides on. Get it right once.
4. Click download — or torrent for a large or unreliable pull. Rationale: torrent self-verifies and resumes; direct HTTP is fine on a fast, stable line.
5. Grab the matching .md5 file. Rationale: without the reference hash you cannot prove the download is intact, and you will not find out otherwise until it fails.
6. Verify the md5 locally before you touch the card. Rationale: flashing a corrupt image wastes ten minutes and produces a confusing failure. Thirty seconds of hashing prevents it.
7. Prepare genuine storage — a real A1/A2 card or a USB 3.0 SSD. Rationale: counterfeit and worn cards fail under Batocera's random-I/O workload, and the symptoms mimic software bugs.
8. Flash the image with Etcher, Rufus, or dd. Rationale: this writes the raw image; Etcher decompresses .img.gz on the fly so you skip a manual step.
9. Insert the media into the target device and set the boot order. Rationale: on PCs you may need to disable Secure Boot and enable USB booting in firmware, or the machine ignores the drive entirely.
10. Boot and let Batocera auto-expand /userdata. Rationale: the first boot resizes the data partition to fill the device; interrupting it leaves you with a fraction of your card usable.
11. Configure controller, language, timezone, and network. Rationale: a mapped controller and a live network connection are what make the box usable and updatable without pulling the card.
12. Copy ROMs and BIOS over the network share, then scrape metadata. Rationale: games are what you came for; the network share is faster and less card-abrasive than shuttling the card back and forth.

Expected Download Output

If you prefer the command line to buttons, the grab looks like this. Paste the real URL from the download button on batocera.org — the exact mirror path changes, so do not trust a hard-coded URL from any tutorial, including this one:

# Paste the real link from the download button on batocera.org:
curl -L -O "PASTE_DOWNLOAD_URL_HERE"
curl -L -O "PASTE_MD5_URL_HERE"

# You should now have both files side by side:
$ ls -lh
-rw-r--r-- 1 you you 2.9G batocera-x86_64-43.1-20260530.img.gz
-rw-r--r-- 1 you you   77 batocera-x86_64-43.1-20260530.img.gz.md5

The exact byte size will differ by architecture and release; what matters is that both files landed and neither is zero bytes. Now verify it.

Flashing: Etcher, Rufus, or dd

Flashing is where "raw image" becomes literal. You are copying bytes to a block device, not files to a filesystem. Choose your tool by temperament.

Step Six First: The md5 Verification Ritual

Do this before flashing, every single time. Compute the hash of the image you downloaded and compare it to the string inside the .md5 file:

$ md5sum batocera-x86_64-43.1-20260530.img.gz
3f2b9c...a17e  batocera-x86_64-43.1-20260530.img.gz

# Now read the reference hash the project published:
$ cat batocera-x86_64-43.1-20260530.img.gz.md5
3f2b9c...a17e

# macOS:      md5 batocera-x86_64-43.1-20260530.img.gz
# Windows:    CertUtil -hashfile batocera-x86_64-43.1-20260530.img.gz MD5

The 32-character hex string on the left must match the contents of the .md5 file exactly — the abbreviated 3f2b9c...a17e above is illustrative, not a real hash; yours will be a full 32 characters. If they differ by even one character, the download is corrupt or tampered. Delete it and pull it again, ideally over the torrent. Do not flash a mismatched image "to see if it works." It will not, and the failure mode is a mystery boot loop.

balenaEtcher (The Safe Path)

Etcher is three clicks: Flash from file (select the .img.gz — it decompresses automatically, no need to gunzip), Select target (your card or USB drive, and it grays out system disks to stop you nuking your OS), Flash. It validates the write afterward, which combined with your md5 check means you have verified integrity twice. For anyone who has never done this, this is the recommended route and there is no shame in it.

Rufus (Windows Power Users)

Rufus is faster and gives you more rope. Select the device, select the decompressed .img (older Rufus builds want the image decompressed first; recent 4.x handles compressed images), choose DD Image mode when prompted, and write. Rufus is the better call on Windows when you are re-flashing repeatedly and Etcher's deliberateness starts to grate.

dd (For People Who Enjoy Pain)

On Linux or macOS you can skip the GUI entirely. This is the fastest and most dangerous method — dd will happily overwrite your root disk if you fat-finger the device name. Identify the target with lsblk first and read it twice:

# 1. Find the target device. Note the SIZE column to confirm it is your card,
#    not your system disk. NEVER guess this.
lsblk

# 2. Decompress the image.
gunzip batocera-x86_64-43.1-20260530.img.gz

# 3. Write it. Replace sdX with YOUR device (e.g. sdb) -- the whole disk,
#    not a partition like sdb1. conv=fsync flushes before dd exits.
sudo dd if=batocera-x86_64-43.1-20260530.img of=/dev/sdX bs=4M status=progress conv=fsync

# 4. Force the kernel to flush any remaining buffers before you pull the card.
sync

If dd makes you nervous, that is the correct instinct. Use Etcher. Nobody hands out medals for flashing an image the hard way, and the recovery cost of a wrong device name is your entire computer.

First Boot and Initial Setup

You have a flashed card. Put it in the target device, make sure firmware will boot from it, and power on. The first boot is doing more than it looks.

The Partition Expansion

On the very first boot, Batocera resizes /userdata to fill the whole card or drive. This can take a minute or two and the screen may sit still while it happens — do not power-cycle it mid-resize, or you will end up with a data partition the size of the original image and no obvious way to know why your 128 GB card claims to be nearly full. Once it settles into EmulationStation, confirm both the version and the expansion over SSH or a terminal:

# Confirm the running version and that the data partition expanded.
$ cat /usr/share/batocera/batocera.version
43.1

$ df -h /userdata
Filesystem      Size  Used Avail Use% Mounted on
/dev/root2      119G  1.3G  112G   2% /userdata

That 119G on a 128 GB card is what a successful expansion looks like. If df reports a couple of gigabytes instead, the resize did not complete — re-flash and let it finish untouched next time.

Controller Mapping

EmulationStation greets you with a controller-mapping prompt. Hold any button on your gamepad to begin, then walk through the inputs. A wired controller is the safe first move; get the system usable before you fight Bluetooth. This mapping is stored and reused across every emulator, which is the entire point of Batocera doing it centrally instead of making you configure each core's inputs by hand.

Network and SSH

Get on the network early — through the menus (Main Menu → Network Settings) or by dropping credentials into the config. SSH is available and the default login is user root, password linux, which you should change if this box lives anywhere near an untrusted network. With networking up you can copy games over the share, scrape artwork, and run the built-in updater, none of which require touching the card again.

Adding ROMs, BIOS, and Metadata

An empty EmulationStation is a very tidy paperweight. Getting content in is two problems — files in the right folders, and BIOS images with the right hashes — plus one nicety, metadata scraping.

The Network Share Method

Batocera exposes its /userdata tree as a network share the moment it is on your LAN. From another machine, browse to the box by hostname or IP and you will find a share folder containing roms, bios, and the rest. Drop ROMs into the correct per-system subfolder:

# On Windows:   \\BATOCERA\share   (or \\THE_IP\share)
# On macOS/Linux: smb://batocera/share

/userdata/roms/snes/     -> put .sfc / .smc files here
/userdata/roms/nes/      -> .nes
/userdata/roms/n64/      -> .z64 / .n64
/userdata/roms/psx/      -> .chd / .cue+.bin / .pbp
/userdata/roms/megadrive/ -> .md / .bin
/userdata/bios/          -> system BIOS images (see below)

Copying over the network is faster and gentler on the card than pulling it out, mounting it elsewhere, and shoving it back. After a big copy, refresh the library from EmulationStation with a gamelist update rather than a full reboot.

BIOS Placement and Verification

Some systems refuse to run without their original BIOS — PlayStation is the classic offender. Batocera has a built-in BIOS checker at Main Menu → Game Settings → Missing BIOS (also surfaced in System Information) that lists exactly which files are missing and the MD5 hash each one must have. That hash requirement is the part people ignore and then wonder why their PS1 games throw errors: a BIOS with the wrong hash is treated as no BIOS at all. Place the files in /userdata/bios/ with the exact names the checker asks for, re-run the check, and only proceed once it is green.

Scraping Metadata

Once games are in, scrape them: Main Menu → Scraper. This pulls box art, descriptions, release dates, and video snippets from an online database and writes them into per-system gamelist.xml files. It is cosmetic, but a scraped library is the difference between a wall of filenames and something that looks like the console menu you were promised. Scraping is also where a live network connection from the first-boot step pays for itself.

Updating vs Re-Downloading

Here is a distinction the download page does not make for you: you do not always need to re-download. Batocera has a built-in updater, and knowing when to use it versus when to re-flash saves both time and your saves.

The Built-In Updater

Inside EmulationStation, the updater lives at START → Updates & Downloads. The official wiki page "Updates & Downloads" documents this path, and it is the correct route for staying current within a release channel. Because the OS partition is separate from /userdata, an in-place update refreshes the system without touching your ROMs, saves, or config. For a point release like moving within the 43.x line, this is almost always what you want.

batocera-upgrade and Release Channels

The same operation is available from the shell, which is handy for headless boxes or scripting. The wiki page "Current/previous/beta releases" covers upgrade guidance and the batocera-upgrade mechanism and its URL format for pointing at different channels:

# SSH in (default: root / linux), then:
ssh root@BATOCERA_IP

# See the current version:
cat /usr/share/batocera/batocera.version

# Trigger an upgrade from the shell -- the CLI equivalent of
# START -> Updates & Downloads inside EmulationStation:
batocera-upgrade

Choosing between the stable and beta channels is a real decision: stable (currently 43.1) is what you want for a machine you actually use; beta is for people who enjoy filing bug reports. The status page dated 2026-06-13 exists precisely so you can see where a release sits before you jump channels.

When to Re-Flash Instead

Re-download and re-flash when you are crossing a major version with breaking changes, when your /userdata has accumulated enough cruft that a clean slate is faster than debugging, or when the card itself is suspect. Because your data lives on a separate partition, the safe move before any re-flash is to copy /userdata off to another drive first — then you can flash a fresh image and drop your data back. That is the appliance model working as designed: the OS is cattle, your data is the pet.

Five Pitfalls That Waste Your Afternoon

Every one of these is common, every one is avoidable, and every one has burned someone this month. Read them now so you recognize the symptom later.

1. Wrong Architecture, Perfect Flash

You flawlessly wrote x86_64 to a card destined for a Raspberry Pi 5, or a bcm2711 image to a Pi 5 that wants bcm2712. The flash succeeds; the device does nothing. Fix: re-download the image whose architecture matches your exact board — consult the architecture table above — and re-flash. The filename is the tell; read batocera-[architecture]-... before you write it, not after.

2. Counterfeit or Worn SD Cards

The card boots once, then corrupts; or games stutter and saves vanish. Fake-capacity cards and cards past their write-endurance are endemic and their symptoms masquerade as software bugs. Fix: use a genuine, name-brand A1/A2 card, verify it with a capacity-test tool before trusting it, and prefer a USB 3.0 SSD on x86 hardware where you can. When a Batocera install behaves erratically for no reason, suspect the media first.

3. Skipping the md5 Check

A download truncated at 98% looks identical to a complete one until it fails to boot with no useful error. Fix: run the md5 comparison from the flashing section every time, before flashing. It costs thirty seconds and eliminates an entire category of confusing failures.

4. Interrupting First-Boot Expansion

The screen sits still during the partition resize, you assume it hung, you pull the power. Now /userdata is a sliver of your card and you cannot figure out why storage is full. Fix: leave the first boot alone for a couple of minutes. If it genuinely failed, re-flash and let the resize complete untouched. Confirm afterward with df -h /userdata.

5. BIOS Files With the Wrong Hash

You dropped a PS1 BIOS into /userdata/bios/ and games still error out. The file is present but its MD5 does not match what the emulator expects, so it is ignored. Fix: use the built-in Missing BIOS checker, match the exact required hash and filename it lists, and re-verify. "A BIOS" is not enough; it must be the BIOS.

Troubleshooting Table

When something breaks after install, work from symptom to cause to fix rather than randomly re-flashing. This table covers the failures you are statistically most likely to hit.

Symptom	Likely cause	Fix
Black screen after flashing a PC	Wrong architecture, or GPU/driver mode	Confirm x86_64 vs zen3-x86-64-v3 vs a Pi build; try the plain x86_64 image; check the monitor is on the active output
"No bootable device" on a PC	Secure Boot on, or USB boot disabled in firmware	Enter UEFI/BIOS, disable Secure Boot, enable USB/removable boot, put the drive first in boot order
Pi shows a rainbow/blank screen and stops	Wrong Broadcom build or bad flash	Pi 4 uses bcm2711, Pi 5 uses bcm2712; re-verify md5 and re-flash the correct one
Controller not detected	Unpaired Bluetooth or unmapped input	Start with a wired pad, map it at the prompt, then pair Bluetooth from Controller Settings
No sound or missing HDMI audio	Wrong audio output device selected	Main Menu → Sound Settings → Output Device; pick the HDMI/analog sink that matches your display
Games do not appear in a system	ROMs in the wrong folder or list not refreshed	Confirm files are in /userdata/roms/[system]/, then update gamelists or restart EmulationStation
"BIOS missing" in red on launch	Missing BIOS or hash mismatch	Game Settings → Missing BIOS; place the exact file with the listed MD5 in /userdata/bios/
Wi-Fi will not connect	Country/region unset or 5 GHz-only adapter issue	Set the Wi-Fi region, try a 2.4 GHz network, or set wifi.ssid/wifi.key in batocera.conf
Storage full on a large card	First-boot partition expansion interrupted	Re-flash, let the resize finish, verify with df -h /userdata
Stutter or throttling on a Pi	Overheating, or a heavy core for the hardware	Add active cooling, switch to a lighter emulator core for that system, and re-check any overclock

Advanced Tips: Shaders, Overclocks, Configs

Once it boots and plays, the interesting work starts. Batocera exposes a deep configuration surface without forcing you into it, and this is where a good install becomes a great one.

Per-System Configuration

Everything the menus set ends up in /userdata/system/batocera.conf, and you can edit it directly. The key convention is system.setting=value for per-system overrides and global.setting=value for defaults that apply everywhere. That lets you, for example, pin a specific core to one system while leaving the rest on their defaults:

# /userdata/system/batocera.conf  --  per-system emulator/core overrides
snes.emulator=libretro
snes.core=snes9x
n64.emulator=libretro
n64.core=mupen64plus-next
psx.emulator=libretro
psx.core=swanstation

# Turn a global feature on, then override it for one demanding system:
global.rewind=1
n64.rewind=0

Core choice is not cosmetic — it is the accuracy-versus-performance dial, and it is the same decision you would make configuring RetroArch by hand. If you want to understand why one N64 or PS1 core beats another on given hardware, the reasoning in our RetroArch cores guide transfers directly, because these are libretro cores under the hood.

Shaders and CRT Emulation

Flat, pixel-perfect output on a modern LCD is historically inaccurate — these games were mastered for CRTs, and shaders exist to put back the scanlines, phosphor bloom, and mask that the artists were actually drawing for. Set one globally with global.shaderset=scanlines (or a heavier CRT preset) and dial it per-system for games that need it. It costs GPU headroom, so a weak Pi may want it off for demanding cores and on for 8-bit systems. If chasing authentic scaling is your thing, note that even dedicated hardware wrestles with it — the same problem the Analogue 3D's 2x N64 upscaler was built to solve is the one your shader chain is approximating in software.

Overclocking and Cooling

On Raspberry Pi builds, Batocera surfaces overclock profiles in the menus, and they can turn a marginal system playable. The catch is thermal: a Pi 4 or Pi 5 pushed hard without a heatsink and fan will throttle, and throttling reads as stutter, which reads as "Batocera is broken." It is not — it is physics. Add active cooling before you touch the overclock, watch temperatures under load, and treat any overclock as a thing you validate, not a thing you set and forget.

A Complete Working batocera.conf

To close, here is a known-good 43.1 baseline you can adapt. It lives at /userdata/system/batocera.conf and is plain key=value text — comment lines start with #. This is not a maximal config; it is a sane one, with the settings most people actually change, annotated so you know what each line does.

# /userdata/system/batocera.conf  --  known-good 43.1 baseline

## --- Language / region ---
system.language=en_US
system.kblayout=us
system.timezone=Europe/Madrid

## --- Networking (leave blank to configure in the UI) ---
wifi.enabled=0
wifi.ssid=
wifi.key=
system.hostname=BATOCERA
system.ssh.enabled=1

## --- Global emulator behaviour ---
global.videomode=default
global.ratio=auto
global.smooth=1
global.rewind=0
global.autosave=0
global.retroachievements=0
global.bezel=default
global.shaderset=none

## --- Per-system core overrides ---
nes.core=fceumm
snes.core=snes9x
gba.core=mgba
megadrive.core=genesis_plus_gx
n64.core=mupen64plus-next
psx.core=swanstation
arcade.core=fbneo

## --- CRT look on modern panels (uncomment to enable globally) ---
# global.shaderset=scanlines

## --- Pi-only knobs, mirrored here for reference ---
# system.power.batocera.first=1

Drop that in, reboot, and adjust from the menus — every UI change writes back to this same file, so you can always diff what changed. Keep a copy of this file off the device, because it plus your /userdata/roms and /userdata/bios folders are your install. The OS image, by design, is the one part you can throw away and re-download in ten minutes.

Where to Go From Here

Everything above is anchored to primary sources. Keep these bookmarked: the official Batocera downloads and changelog for the current version and md5s; the Batocera Wiki for the Updates & Downloads and Current/previous/beta releases pages; the batocera.linux GitHub repository for the source, issues, and build details; and the libretro/RetroArch documentation for the cores doing the actual emulating underneath EmulationStation. Between those four and the config above, you have everything you need to run 43.1 correctly and to fix it yourself when something drifts.

That is the whole job: pick the right architecture, verify the hash, flash genuine media, let it expand, feed it games and the correct BIOS, and keep your /userdata safe. Do those in order and Batocera is boring in the best possible way — it just boots into games and stays out of your way. Which, for an appliance, is the highest praise there is.