Batocera Download 2026: v43.1 in 12 Steps, 15 Min

Here is the entire secret of Batocera, the part the forum threads bury under 400 replies: the download is the product. There is no installer that asks where to put your Program Files. There is no account. There is no $59.99 'lifetime' upsell. You fetch one compressed disk image from batocera.org/download, write it to a USB stick, and boot your PC from that stick. Your Windows install never learns it happened. The current stable release as of this writing is 43.1 — a point release dated 30 May 2026, sitting on top of the version 43 line ('Glasswing') that shipped 8 May 2026. It costs $0.00, which is not a promotion. It is the price.

This guide takes you from an empty USB stick to a working emulation front-end in about fifteen minutes of hands-on time, plus however long your download bar takes. Twelve numbered steps do the work. The rest of the article is the stuff those twelve steps assume you already know and you don't: which image to pick, why your first boot looks broken when it isn't, where BIOS files live, and the specific ways version 43 will punish you if you upgrade an old install without reading first. We will also, because it is 2026 and someone has to, be honest about the law.

Why Batocera in 2026 (and Not RetroPie)

The pitch, minus the marketing

Batocera is a Linux distribution with exactly one job: turn a computer into a console-shaped appliance that boots straight into EmulationStation, runs your games, and gets out of the way. It is 'immutable' in the sense that the operating system lives on a read-only image while everything you care about — games, saves, configs, scraped artwork — lives on a separate userdata partition. That separation is the whole reason upgrades are survivable: you replace the OS and your data is untouched. It is also why you can run the thing entirely from a USB stick and never modify the host machine. Boot it, play, pull the stick, and the PC is a PC again.

The project was founded in 2016 and is 100% open source. Every line is in the public GitHub repository, and you are free to build your own image from it if you enjoy that sort of afternoon. It is maintained by a community, with copyright held by Batocera.linux across 2016–2026. There is no company, no Series A, no 'Batocera Pro.' When something is free and open and has survived a decade, it is usually because it works.

The license nobody reads (CC-BY-NC-SA)

Batocera is distributed under CC-BY-NC-SA — Creative Commons Attribution, NonCommercial, ShareAlike. The middle term is the one that matters and the one every marketplace seller ignores. 'NonCommercial' means you cannot legally sell a microSD card or a mini PC preloaded with Batocera. The distro is free; bundling it into a product for money is not permitted by its license, no matter how many 'Retro Game Console 20,000 Games!' listings suggest otherwise. This is a distinct problem from the games themselves being unlicensed, which they also are. Two separate laws, both broken, one cheap plastic box.

Batocera vs. RetroPie vs. Recalbox

If you have been away for a few years, your muscle memory says 'RetroPie.' Update it. RetroPie's last official image is v4.8, from March 2022, and there is still no official Raspberry Pi 5 image — you install it by hand on top of Pi OS Lite, which works but is not a download-and-flash story. We covered exactly how stuck it is in our piece on RetroPie being frozen at v4.8 with no x86 image. Batocera, by contrast, ships current images for the Pi 5, for x86_64 PCs, for the Steam Deck, and for a long list of handhelds. GitHub stars are not the whole story — RetroPie has 10,381 to Batocera's 3,084 — but stars measure history, not freshness, and 2022 was a long time ago. Recalbox is the third option and a fine one; it is friendlier and more locked-down, which some people want. Batocera sits in the middle: appliance-simple to boot, but with a real Linux underneath the moment you go looking.

Prerequisites and Hardware

Minimum and recommended hardware

Batocera will run on almost anything with a 64-bit x86 processor, but 'will run' and 'will run PlayStation 2 at full speed' are different sentences. The floor is 1GB of RAM; the project recommends 2GB, and you will want more the moment you touch anything past the fifth console generation. Storage is the number people get wrong: 16GB is the absolute minimum, 32GB is recommended, and there is a specific trap at 16GB — the in-place auto-updater refuses to run on 16GB media because it needs room to stage the new image. On a 16GB stick you are signing up for manual upgrades forever. Buy the 32GB. It is four dollars.

For the CPU, note the architecture split that version 43 leans into. The standard x86_64 image runs on any 64-bit PC. The newer, preferred x86_64-v3 image targets modern chips — roughly Intel Haswell (2013) and AMD Zen or later — and exists specifically to serve modern handhelds with capable AMD and Intel graphics. If your machine is older than about 2013, take the plain x86_64 image; the v3 image will refuse to boot on a CPU that lacks the instructions it assumes. A named example target for the v3 build is a small box like the Beelink Mini S12. A Steam Deck, an old ThinkPad, or a Raspberry Pi 5 are all equally valid hosts — just pick the matching image on the download page.

The right flashing tool (and why not dd)

You need three things: the image, a stick to write it to, and a tool to write it with. For the tool, the wiki nudges you toward Raspberry Pi Imager (v1.9 or newer) or USBImager, and it explicitly calls raw dd 'not recommended' for anyone who is not already comfortable losing a disk. This is correct. Raspberry Pi Imager decompresses the .img.gz for you, verifies the write, and — crucially — shows you human-readable device names so you do not nuke your NVMe. balenaEtcher works too. We will show the dd path later for the people who want it, wrapped in enough warnings to be actionable.

What you must supply yourself (games, BIOS, and the law)

Batocera ships no games and no BIOS files. This is not an oversight; it is the only reason the project can exist in the open without a legal team. The distro is a set of empty, labeled shelves. Filling them is your job, and the lawful way to do it is to dump your own cartridges with a device like the Retrode, then copy the resulting files across. A handful of systems also require BIOS or firmware images that are themselves copyrighted — PlayStation, Saturn, and the DS-family cores are the usual suspects — and those, too, you are expected to extract from hardware you own. We will get to exactly where they go and how to check them.

What Version 43 Broke, and What It Fixed

Emulator removals and swaps

Version 43 is an open-source purity release, and purity has casualties. The big one: DraStic, the long-serving Nintendo DS emulator, was removed because it is closed-source and therefore incompatible with the project's stated philosophy. If you have been running DS games on an older Batocera, an upgrade to 43 takes DraStic with it. The replacement is melonDS, which is open and good, but it does not read DraStic's save format blindly — so back up your DS saves and note your controller mappings before you upgrade. This is the single most common way people ambush themselves with v43.

On the 3DS side, Azahar Plus was replaced by upstream Azahar, again to align with open-source standards. Azahar is the community's post-Citra 3DS emulator; the 'Plus' fork was dropped in favor of the source project. Functionally similar, cleaner provenance.

The 3DS decryption rule (CIA and CCI)

Here is the change that will generate the most 'it worked last month' threads. In version 43, encrypted 3DS containers are no longer supported — specifically encrypted CIA and CCI files, both of which are Nintendo 3DS formats (CIA is an installable title package; CCI, sometimes carrying a .3ds extension, is a cartridge image). The emulator now accepts decrypted ROMs only. If your 3DS library is a pile of encrypted CIAs, they will simply refuse to load until you decrypt them. On the same release the .3ds extension was re-enabled, and — take note — hardware shaders were disabled by default to improve compatibility across the messy 3DS catalog. If a 3DS game renders wrong, that default is the first thing to revisit, not the last.

Assets, shaders, and Xenia

Two smaller items round out the upgrade notes. TheXTech — the open-source Super Mario engine reimplementation — now requires 1.3.7 or newer assets in version 43, so if your SMBX-style content stopped loading, update the asset pack to match. And on the Xbox 360 front, the Xenia emulator was brought up to build 1d7973a, integrated on 10 June 2025, chiefly for stability. Xbox 360 emulation remains the frontier it has always been, but the Batocera build tracks upstream more closely than it used to. All of this is logged, release by release, in the official changelog and the current and previous releases page — bookmark both before you upgrade anything.

The 12-Step Install

Everything above is context. This is the procedure. Twelve steps, each with the reason it exists, because a step you understand is a step you can debug. Budget fifteen minutes of hands-on time; the download and the first-boot expansion run on their own clock.

1. Choose the correct image on the download page. Go to batocera.org/download and select your device: PC (x86_64 or x86_64-v3), Steam Deck, Raspberry Pi 5, or one of the listed handhelds. Rationale: the image is architecture-specific. A Pi image will not boot a PC and a v3 image will not boot a pre-2013 CPU. Getting this right is most of avoiding a black screen.
2. Download the image and its checksum. Grab the .img.gz and, right next to it, the .sha256 file. Rationale: a half-downloaded or bit-rotted image flashes fine and then fails to boot in ways that look like hardware faults. The checksum is how you rule that out in ten seconds.
3. Verify the checksum. Compare the hash of your download against the published value.

   # Linux / macOS — verify the image against the published hash
   sha256sum batocera-x86_64-43-20260508.img.gz
   
   # Windows (cmd or PowerShell)
   certutil -hashfile batocera-x86_64-43-20260508.img.gz SHA256
   
   # Expected: the value printed MUST equal the .sha256 file that
   # sits next to the image on batocera.org. One wrong character
   # means a corrupt download — do NOT flash it.
   # 9f86d081884c...(64 hex chars)...  batocera-x86_64-43-20260508.img.gz

   Rationale: one mismatched character means the file is corrupt. Verifying now saves you an hour of blaming your USB port later.
4. Get a flashing tool and a 32GB+ stick. Install Raspberry Pi Imager (v1.9+) or USBImager. Use a 32GB or larger USB 3.0 stick or a reputable SD card. Rationale: 16GB boots but blocks the auto-updater; slow no-name media makes the whole system feel broken when it is just I/O-starved.
5. Identify the target device. Note exactly which disk is your stick before you write anything — confirm it by size, not by guesswork. Rationale: flashing tools and dd alike will happily overwrite your system drive if you point them at it, and a 2TB NVMe and a 32GB stick both read as 'a disk' in a dropdown.
6. Flash the image. In Raspberry Pi Imager choose 'Use custom,' select the .img.gz, select your stick, and write. For the command-line inclined:

   # ADVANCED. The wiki recommends Raspberry Pi Imager or USBImager
   # over dd for one reason: dd does not ask twice.
   
   # 1) Find the target. Read the SIZES. Your 32GB stick is the
   #    28-30GB line, not your 2TB system disk.
   lsblk
   
   # 2) Write it. Replace sdX with the DISK (e.g. sdb), never a
   #    partition (sdb1). Images ship gzip-compressed, so
   #    decompress on the fly:
   gunzip -c batocera-x86_64-43-20260508.img.gz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync
   
   # 3) Flush before you pull the stick:
   sync

   Rationale: the image is a full bootable disk, not a file you copy. It must be written block-for-block, which is what these tools do and what dragging-and-dropping does not.
7. Set the PC to boot from USB and disable Secure Boot. Enter your BIOS/UEFI (usually F2, F12, or Del at power-on), move the USB stick to the top of the boot order, and turn Secure Boot off. Rationale: Secure Boot blocks unsigned Linux bootloaders; leaving it on is a very common 'it just will not boot' cause.
8. Boot the stick and choose run-versus-install. Boot from the USB. You can run Batocera live off the stick, or use the built-in installer to write it to an internal disk. Rationale: running live modifies nothing on the host — ideal for trying it or for a permanently portable setup. Installing to disk is faster and frees the USB port. Choose deliberately; the installer erases the target disk.
9. Let userdata auto-expand on first boot. The first boot looks like it stalled or shipped with a tiny disk. It did not. Rationale: Batocera expands the userdata partition to fill your media on first boot. Wait it out; do not power-cycle mid-expansion.
10. Map your controller. When EmulationStation loads, hold any button on your gamepad and follow the mapping wizard. Rationale: the entire interface is driven by that mapping. A wired pad first is the least-drama path; Bluetooth pairing can wait until you are in.
11. Connect to the network. Open the main menu, then NETWORK SETTINGS, and join Wi-Fi, or plug in Ethernet. Rationale: the network is how you copy games via the share, scrape artwork, and pull updates. It also enables SSH, which you want.
12. Copy games and BIOS, then update gamelists. Over the network, open \\BATOCERA\share, drop ROMs into roms/[system] and BIOS into bios/, then in EmulationStation press START, then GAME SETTINGS, then UPDATE GAMELISTS. Rationale: the menu only shows systems it has found games for, and it caches that list — so new files are invisible until you rescan.

That is the whole install. The sections that follow expand steps 9 through 12, which is where the real questions live.

First Boot: Storage, Controllers, and Network

Userdata auto-expansion

The first time Batocera boots from your freshly flashed media, it resizes the userdata partition to consume all remaining space. On a 256GB SSD that is quick; on a slow 128GB SD card it can take a couple of minutes during which the screen may sit still. This is normal and it happens exactly once. The failure mode people invent here is pulling power because 'it froze,' which interrupts the resize and leaves you with a genuinely broken partition table — at which point you reflash and start over. Patience is literally the fix. After it completes you will have the full capacity of your media available under /userdata, which is where everything you add from now on will live.

Mapping a controller

EmulationStation is a gamepad-first interface, so the first thing it wants is a gamepad. Hold any button until the mapping wizard appears and walk through the prompts. Batocera recognizes the common pads — Xbox, DualShock/DualSense, 8BitDo, most generic XInput devices — out of the box, so a wired controller is usually plug-and-go. Bluetooth pads work but pairing them before you have mapped anything is a chicken-and-egg annoyance; do the wired pad first, get into the menus, then pair Bluetooth from the controller settings at your leisure. If a controller is not detected at all, that is a troubleshooting-table item below, not a reason to give up.

Getting online and into SSH

Join Wi-Fi or Ethernet from the network menu, and note that Batocera also brings up an SSH server and a network file share automatically. The default SSH login is root / linux — those exact credentials, which means anyone on your LAN who knows Batocera knows your password. Change it.

# SSH in — default credentials are root / linux.
ssh root@BATOCERA.local

# Change the password immediately on any shared network:
passwd

# Confirm the share is populated with your ROM systems:
ls /userdata/roms

The file share is the more pleasant way in for copying games: on Windows or macOS it appears as \\BATOCERA\share; on Linux, mount smb://BATOCERA.local/share. Full details are on the access Batocera via SSH wiki page.

Adding Games and BIOS the Right Way

The share/roms folder structure

Every system has a short folder name — snes, megadrive, psx, n64, nds, n3ds, and so on — and a game only shows up if its file sits in the matching folder. Put a SNES ROM in roms/nes and it will either not appear or try to boot on the wrong emulator. Here is the layout you are aiming for:

/userdata/
├── roms/
│   ├── snes/          # Super Nintendo   — .sfc .smc .zip
│   ├── megadrive/     # Genesis/Mega Drive — .md .bin .zip
│   ├── psx/           # PlayStation      — .chd (preferred) .cue+.bin
│   ├── n64/           # Nintendo 64      — .z64 .n64
│   ├── nds/           # Nintendo DS      — melonDS (DraStic gone in v43)
│   └── n3ds/          # Nintendo 3DS     — DECRYPTED .3ds/.cci ONLY (v43)
├── bios/              # firmware here; filenames + hashes must match
│   ├── scph5501.bin   # PS1 (US) — verify against libretro's list
│   └── ...
└── system/
    └── batocera.conf  # the one config file that survives upgrades

Preferred formats matter more than they used to. Disc-based systems (PS1, Saturn, Dreamcast, PSP) run best from .chd, a compressed image format that saves space and loads cleanly; cartridge systems generally accept raw dumps and .zip. Batocera's per-system pages document the accepted extensions, and the add games and BIOS page is the canonical reference.

BIOS files and matching hashes

Some systems will list your games but refuse to launch them, and the cause is almost always a missing or wrong BIOS. BIOS and firmware files go in /userdata/bios/, and — this is the part people skip — the filename and the hash both have to match what the core expects. A PlayStation core wants a specific scph file with a specific MD5; a near-copy with a different revision will not do. Batocera's built-in 'Missing BIOS' checker in the main menu tells you what you are short, and libretro maintains the authoritative name-and-hash reference at the libretro BIOS documentation. Match against that list and most 'will not launch' problems evaporate.

Where legal ROMs come from

The distro will not say it, so I will: the only unambiguously lawful way to fill these folders is to dump games and BIOS from hardware you own. Our guide to dumping SNES and Genesis carts covers the cartridge side end to end. Be realistic about scale, too — a 'complete' set for even one console runs to thousands of files, as our breakdown of a 6,041-game Miyoo library lays out. And under nearly every system, Batocera is running a libretro core; when you want to change which core a system uses or tune it, our tour of RetroArch's 200-plus cores is the map. Once files are in place, remember the last move from step 12: START, then GAME SETTINGS, then UPDATE GAMELISTS, or the menu will keep showing you yesterday's library.

Upgrading to 43.1 Without a Reflash

Check /boot before you touch anything

Because the OS and your data live on separate partitions, you can move from an older Batocera to 43.1 without losing a single save — if the upgrade completes. The most common reason it does not is a cramped boot partition: version 43's image is larger, and a /boot that was fine for version 40 can be too tight to stage the new one. A 2026 community tutorial makes the same point, and it is correct — check your boot partition size first.

# SSH in first. Default credentials are root / linux.
ssh root@BATOCERA.local

# Before ANY upgrade, confirm /boot has headroom. The v43 image
# is larger; a full /boot is the number-one upgrade failure.
df -h /boot

# Expected — you want a comfortable 'Avail' figure:
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sda1       2.0G  1.3G  680M  67% /boot

If Avail is measured in tens of megabytes, stop and reflash cleanly rather than fighting an in-place upgrade that will fail halfway.

Online vs. manual upgrade

With headroom confirmed, the online path is one command. When the updater cannot reach the network — restrictive Wi-Fi, a headless box, a mirror having a bad day — the manual path lets you feed it the upgrade file by hand.

# Online, in-place upgrade. Keeps /userdata (games + saves):
batocera-upgrade

# Offline / manual upgrade, when the updater can't reach the net:
#   1) Download boot.tar.xz from a mirror, e.g.
#      https://mirrors.o2switch.fr/batocera/
#   2) Copy it into /userdata/system/upgrade/
#   3) Then run:
batocera-upgrade-manual

# Reboot to apply. Userdata is untouched either way.
reboot

A healthy online upgrade prints roughly this:

$ batocera-upgrade
Checking for updates...
Available version : 43.1
Installed version : 43
Downloading batocera (this can take a while)...
[####################] 100%
Update downloaded. It will be installed on the next reboot.

The full manual procedure, including which file goes where, is on the upgrade manually wiki page. Remember the 16GB caveat from the prerequisites: on 16GB media the automatic updater is disabled outright, so the manual route is your only route there.

Reading the log when it fails

If the upgrade dies, do not immediately reflash and shrug. The reason is written down. Batocera logs the upgrade output, and reading it is the fastest way to tell 'the mirror timed out' (retry) from 'the checksum did not match' (re-download) from 'no space left on device' (the /boot problem again).

# When batocera-upgrade fails, the reason is in the log, not on
# screen. Read it before reflashing anything.
cat /userdata/system/logs/batocera.log

# The last 40 lines usually name the culprit — no space, bad
# mirror, or a checksum mismatch:
tail -n 40 /userdata/system/logs/batocera.log

Nine times out of ten the last dozen lines name the culprit outright, and the fix is obvious once you have read it instead of guessed at it.

Five Pitfalls That Waste Your Afternoon

These are the failure modes that turn a fifteen-minute job into a three-hour one. None of them are hard to avoid once you know they exist, which is the entire value of a list like this.

Flashing and boot pitfalls

1. Wiping the wrong drive. dd and even the friendly imagers will overwrite whatever disk you select, and a 2TB system NVMe and a 32GB stick both look like 'a disk' in a dropdown. Fix: identify the target by size before writing (lsblk), and prefer Raspberry Pi Imager, which shows human-readable names and warns on system disks. If you can, unplug other external drives entirely while you flash.

2. The black screen after boot. Two causes dominate: Secure Boot is still enabled, or you flashed the x86_64-v3 image onto a pre-2013 CPU that lacks the instructions it needs. Fix: disable Secure Boot in the UEFI, and if the machine is old, reflash with the plain x86_64 image instead of v3.

Content pitfalls

3. BIOS hash mismatches. The game is listed, it will not launch, and the 'emulator' gets blamed. Fix: run the built-in Missing BIOS check and match every file's name and hash against the libretro BIOS list. A BIOS that is the right idea but the wrong revision fails silently.

4. Encrypted 3DS ROMs after upgrading to v43. Files that loaded on your old install now do nothing. Fix: version 43 accepts decrypted 3DS ROMs only — encrypted CIA and CCI are out. Decrypt them, and if a 3DS title renders wrong, re-enable hardware shaders for it (they ship off by default in v43).

Upgrade pitfalls

5. Losing DS saves and a cramped /boot. Two upgrade traps in one: DraStic's removal in v43 can strand your Nintendo DS saves, and a full boot partition can fail the upgrade midway. Fix: before upgrading, back up your DS saves and note controller mappings so you can restore them under melonDS, and confirm df -h /boot shows real headroom. On 16GB media, expect manual upgrades only — the auto-updater is disabled there by design.

Troubleshooting Table

Symptoms, causes, and fixes

Ten of the most common Batocera install and upgrade failures, with the actual cause rather than the folklore. Work top to bottom; the ordering roughly follows the install sequence.

When the table isn't enough

If none of the above matches, two moves cover most of the long tail. First, read the log — cat /userdata/system/logs/batocera.log — because a specific error message beats an hour of guessing. Second, when an install is genuinely corrupt (interrupted first-boot expansion, bad flash), a clean reflash to a known-good 32GB stick is faster than archaeology. Your games and saves live in /userdata; if that partition is intact you can back it up over the share before reflashing.

Getting help without getting flamed

When you take a problem to the wiki, the forum, or the Discord, bring three facts: the exact image you flashed (arch and version), the device, and the relevant lines from batocera.log. 'It does not work' gets you nothing; '43.1 x86_64-v3 on a Beelink S12, batocera-upgrade fails with no space left on device on /boot' gets you an answer in one reply. The install wiki is the first stop for the boot-level problems.

Advanced Tips

The butterfly channel and staying current

Batocera has two update streams. Stable is what 43.1 is, and what you want on a machine you actually play on. Butterfly is the bleeding-edge channel that pulls the latest nightly builds — newer cores and features, and the occasional new bug to go with them. You switch channels in UPDATES settings or with the updates.type key (values stable or butterfly) in batocera.conf. Run butterfly if you like filing useful bug reports; run stable if you like your Saturday afternoons.

Shaders, decorations, and integer scaling

The look of the thing is fully in your hands. Shaders (global.shaderset) apply CRT emulation, scanlines, and the like across every system, or per-system if you prefer; remember that v43 turned hardware shaders off by default for 3DS, so that is a per-system exception, not a global one. Decorations, a.k.a. bezels (global.bezel), fill the empty sides of 4:3 games on a 16:9 screen with artwork instead of black bars. And integer scaling (global.integerscale) keeps pixels square at the cost of some border — the purist's choice. All three are toggles in the menus and keys in the config; set them globally and override where a system needs it.

Netplay, RetroAchievements, and other silicon

Two features worth turning on: RetroAchievements, which layers an achievement system over retro games (set your credentials in the config), and netplay, which lets two Batocera boxes play the same core online. Both are off by default and both are a couple of config lines away. And a note for the purists: emulation is not the only path. If you want silicon-accurate, cycle-exact timing rather than software approximation, the MiSTer Multisystem's FPGA approach is the other church entirely — more expensive, more precise, and a different hobby. Batocera's strength is breadth and convenience; know which one you actually want before you spend.

A Complete Working batocera.conf

What survives an upgrade

Nearly every setting you touch in the menus is written to a single file: /userdata/system/batocera.conf. Because it lives in userdata, it survives OS upgrades intact — which makes it both your backup strategy and your fast-recovery path. Copy this one file off the box over the share, and you can reproduce your entire configuration on a fresh flash in seconds. Lose it, and you are re-toggling menus by hand.

The annotated baseline

Below is a complete, sane baseline you can drop in and adjust. Keys are key=value; comments start with #. Fill in your Wi-Fi and, if you use it, RetroAchievements. The per-system core lines at the bottom reflect version 43's reality — melonDS instead of the removed DraStic, Azahar instead of Azahar Plus, and hardware shaders off for 3DS.

# /userdata/system/batocera.conf — a complete, working baseline.
# Format is key=value. This file is the ONE thing that survives
# every OS upgrade, so back it up.

## ---- System ----
system.language=en_US
system.kblayout=us
system.timezone=America/New_York
system.hostname=BATOCERA

## ---- Network / access ----
wifi.enabled=1
wifi.ssid=YourNetwork
wifi.key=YourWifiPassword
system.ssh.enabled=1           # default login root / linux — change it
system.samba.enabled=1         # exposes \\\\BATOCERA\\share on the LAN

## ---- Audio / video ----
audio.volume=90
audio.bgmusic=0                # kill the menu music; you're welcome
global.videomode=default
global.smooth=1                # bilinear smoothing
global.integerscale=0
global.bezel=default           # per-game decorations/overlays
global.shaderset=none          # try 'scanlines' if you like the look

## ---- Updates ----
updates.enabled=1
updates.type=stable            # 'stable' or 'butterfly' (bleeding edge)

## ---- RetroAchievements (optional) ----
global.retroachievements=0
global.retroachievements.username=
global.retroachievements.password=
global.retroachievements.hardcore=0

## ---- Netplay (optional) ----
global.netplay=0
global.netplay.nickname=Player1

## ---- Per-system cores (v43 reality) ----
snes.core=snes9x
n64.core=mupen64plus-next
psx.core=swanstation
nds.core=melonds               # DraStic removed in v43
n3ds.core=azahar               # Azahar replaced Azahar Plus
n3ds.hardware_shaders=0        # OFF by default in v43 for compatibility

Applying it

Edit the file over the network share or via SSH, then either reboot or reload settings from the menu for the changes to take. If you hand-edit over SSH, mind that some keys only take effect after a restart of EmulationStation. Keep a copy of your finished batocera.conf somewhere off the device; it is, in the most literal sense, your entire setup in one text file. When in doubt about a specific key, the wiki's per-feature pages document the exact names and accepted values — start from the install page and follow the links to each subsystem. That, plus a verified download and a 32GB stick, is the whole job.