You’ve got a stack of old game cartridges, a Pi sitting in a drawer, and a vague notion that you can turn it into a working emulation machine. But when you start looking at setup guides online, you hit a wall: fragmented instructions, outdated dependencies, people arguing about the “best” way to do it, and screenshots from operating systems that no longer exist.
The truth is that RetroArch on Raspberry Pi is genuinely powerful—you can run hundreds of games across dozens of systems with accurate emulation cores. But the setup is less straightforward than people make it sound, and the wrong decisions early on will cost you hours of troubleshooting or a system that works poorly and feels like a hobby project rather than a functional device.
Over the last two decades, I’ve built more emulation systems than I care to admit, debugged networking issues, dealt with audio sync problems, and watched people give up because they installed the wrong OS or didn’t understand why their controller wasn’t being recognized. The good news is that the Raspberry Pi emulation ecosystem has stabilized significantly. The bad news is that “stable” doesn’t mean “obvious,” and setup decisions made in the first 30 minutes will determine whether you spend a couple of hours on this or several days.
What We’re Actually Building Here
RetroArch is an emulation frontend—think of it as the operating system for playing retro games. It’s not a single emulator; it’s a framework that wraps multiple emulation cores (like SNES9x for Super Nintendo, Stella for Atari, Mupen64Plus for Nintendo 64) into a unified interface with consistent controls, configuration, and settings management.
On a Raspberry Pi, RetroArch gives you stable, reasonably accurate emulation of systems from the Atari 2600 through the original PlayStation—though performance and accuracy vary significantly depending on which system you’re emulating and which Pi generation you’re running.
What you’ll learn in this guide: the exact sequence of decisions you need to make before the first installation, how to install RetroArch cleanly on a current Raspberry Pi OS, how to properly configure controllers and video output, why audio sync matters and how to fix it, and the specific performance tuning that actually makes a difference.
The Hardware Foundation: Why Your Pi Version Matters
Emulation is compute-heavy. The original Raspberry Pi Zero and Pi 1 can run NES and SNES games, but 3D emulation is essentially off the table. A Raspberry Pi 4 with 4GB RAM running SNES or Genesis handles things easily. The Pi 5 is overkill for everything except N64 and Dreamcast.
Here’s the physics: emulation requires your Pi to simulate the CPU, GPU, sound hardware, and cartridge hardware of a 30-40-year-old system in software. An original Atari 2600 had a 1.19 MHz processor. Your Pi’s CPU runs at 1.5+ GHz. Even accounting for the overhead of software emulation and the fact that modern processors are more efficient, you’d think older systems would be trivial to emulate. The catch is that real-time performance is crucial. If your emulation frame misses its deadline—typically 60 or 50 times per second depending on the system—your audio and video sync, and your controls become unresponsive.
A Raspberry Pi 3B+ can manage NES, SNES, Genesis, and Game Boy comfortably. For anything more complex—N64, PSX, Dreamcast—you need a Pi 4 with at least 2GB RAM, ideally 4GB. If you’re running on a Pi Zero or Pi 1, limit your collection to systems pre-1990, and understand that some games will skip frames.
Storage matters too. Retro games are small individually, but 500-game libraries add up. You’ll want a microSD card of at least 32GB, ideally UHS-II compatible. Older U1-rated cards are slow enough that game loading becomes noticeably sluggish. Spend $10 extra on a card that’s actually rated for the speed you need.
Operating System Choice: The Setup Decision That Costs Hours
You have three realistic options: Raspberry Pi OS (the official distribution), RetroPie, or Batocera.
Raspberry Pi OS is the clean, minimal starting point. You get a Linux desktop, standard package management, and you install RetroArch from the ground up. This takes longer, gives you maximum control, and leaves your system usable for other tasks.
RetroPie is a pre-configured operating system built specifically for emulation. It includes RetroArch pre-installed with common cores, pre-configured controllers, optimized performance settings, and a ROM management system. It’s faster to get running but less flexible if you want to customize or use your Pi for non-gaming tasks.
Batocera is a portable Linux distribution focused solely on gaming. It’s newer than RetroPie, more actively maintained, and has a cleaner UI. It’s also less flexible if you want to customize deeply or run other software.
My recommendation for a first-time build: use Raspberry Pi OS. Yes, it’s more steps. But you’ll understand how the system actually works, troubleshooting becomes intuitive, and you avoid being locked into whatever design decisions a pre-built image made two years ago. If you’re building your third emulation machine and just want something running in 20 minutes, RetroPie saves time. For this guide, I’m assuming you want to understand what’s happening.
Installing Raspberry Pi OS and Initial Configuration
Download the Raspberry Pi Imager from the official website and install Raspberry Pi OS (the current version, either 32-bit or 64-bit depending on your Pi generation). Use a microSD card reader to write the image.
On first boot, you’ll be walked through the setup wizard. Set your timezone, create a user account (don’t use the default Pi account; it’s a known security issue), and enable SSH if you want to manage the system remotely.
Update your package manager and installed software before doing anything else:
sudo apt update && sudo apt upgrade -y
This ensures you have the latest security patches and bug fixes. On a fresh Pi, this usually takes 5-10 minutes.
Allocate GPU memory. Emulation uses the CPU more than the GPU, but some systems (particularly N64 and PSX) benefit from higher GPU allocation. Edit the boot configuration:
sudo nano /boot/firmware/config.txt
Find the line gpu_mem= (if it doesn’t exist, add it). Change it to gpu_mem=256 for a Pi 4 or gpu_mem=128 for a Pi 3. Save and exit (Ctrl+X, then Y, then Enter).
Reboot:
sudo reboot
Installing RetroArch from Source
RetroArch is available in the Debian repositories, but the version is often outdated. We’ll compile from source to get the latest stable release with all features enabled.
First, install build dependencies:
sudo apt install -y build-essential git libasound2-dev libflac-dev libfreetype6-dev libogg-dev libopus-dev libsdl2-dev libvorbis-dev libxkbcommon-dev pkg-config zlib1g-dev
Clone the RetroArch repository and build:
git clone https://github.com/libretro/RetroArch.git
cd RetroArch
./configure --enable-alsa --enable-freetype
make
This takes 10-15 minutes depending on your Pi model. Once complete:
sudo make install
This installs RetroArch into your system path. You can now launch it from the desktop menu or by typing retroarch from any terminal.
Next, install the emulation cores (the actual emulators). Launch RetroArch and navigate to Main Menu → Online Updater → Core Updater. Download at least these essential cores:
- Nestopia (NES emulation)
- Snes9x (Super Nintendo)
- Genesis Plus GX (Sega Genesis)
- Gambatte (Game Boy)
- Mupen64Plus-Next (Nintendo 64)
- PCSX ReARMed (PlayStation 1)
Each core downloads as a shared library file (.so) to your system. This is the actual emulation code that RetroArch will load when you select a game.
Understanding Controller Configuration
This is where most people hit their first real wall. RetroArch doesn’t automatically detect USB controllers. It requires explicit configuration, and if you map your controls incorrectly, nothing works.
Connect your controller via USB and launch RetroArch. Navigate to Settings → Input → Input User 1 Binds. RetroArch will scan for connected controllers automatically.
You’ll see a list of virtual buttons: D-Pad Up, D-Pad Down, Left, Right, A, B, X, Y, Start, Select, and various shoulder buttons. For each button, RetroArch waits for you to press the corresponding physical button on your controller.
Map every button, not just a subset. If you leave buttons unmapped, games won’t respond to them, and you’ll assume the controller is broken.
After mapping, test your configuration: navigate to any loaded game and hold a button. RetroArch should register it on screen. If it doesn’t, your mapping didn’t save—go back and redo it.
Save your configuration explicitly: Settings → Configuration File → Save Current Configuration. RetroArch has a habit of losing input configurations on reboot if you don’t explicitly save them.
Video Output and Display Configuration
Emulated games output at their original resolutions (320×224 for SNES, 320×240 for Genesis) to a modern display that expects 1080p or higher. This requires scaling—mathematically enlarging the image to fill your screen.
RetroArch offers multiple scaling methods. Navigate to Settings → Video → Scaling.
Integer Scaling enlarges the image by whole number multiples (2x, 3x, 4x). This preserves the original pixel appearance—pixels stay square—but may not fill your entire screen. This is the correct choice for pixel-art games where visual fidelity matters.
Linear Filtering uses interpolation to scale smoothly, filling the screen but blurring the image slightly. Useful for 3D systems like N64 where the original game is already blurry.
Bilinear Filtering is a middle ground—less blur than linear, more flexibility than integer scaling.
Most enthusiasts prefer integer scaling for 2D systems, bilinear for early 3D. Start with integer scaling and adjust if the image feels too small on your display.
Check Full Screen in Video settings. This eliminates the desktop border and gives you more visual real estate. Make sure your refresh rate is set to 60 Hz (for NTSC systems) or 50 Hz (for PAL systems). Mismatching refresh rate causes audio and video sync issues.
Audio Sync and Why It Matters More Than You Think
Audio sync is probably the most misunderstood aspect of RetroArch setup. When audio and video drift out of sync, the experience is immediately wrong—audio lags behind video, or leads it, creating a disorienting disconnection between what you hear and see.
The physics: your Pi generates video frames at 60 Hz (every 16.7 milliseconds). Audio is generated at a sample rate, typically 48 kHz, meaning 48,000 samples per second. These two clocks are not synchronized at the hardware level. Your HDMI output, your audio output, and your emulation clock all run at slightly different speeds.
RetroArch solves this by using audio sync—it adjusts emulation playback speed slightly (imperceptibly, usually ±0.5%) to keep audio and video locked together. Without this, over a few seconds, audio drifts visibly out of sync.
Go to Settings → Audio and enable Audio Sync. The sync quality depends on your sample rate consistency. If your Pi’s audio clock is stable, sync works flawlessly. If it’s unstable (older models sometimes have this issue), you’ll hear crackling or occasional dropouts as the system corrects itself.
Set your audio output to ALSA (on Settings → Audio → Audio Driver). ALSA provides direct hardware access and is more reliable than PulseAudio for real-time audio.
Volume should be set to 100% in RetroArch settings—use your amplifier or display volume to control actual output. This prevents audio clipping and gives you consistent levels across different games.
ROM Management and Directory Structure
RetroArch expects ROMs (game files) in specific directories. Create a folder structure on your microSD card or USB storage:
Emulation/ ├── roms/ │ ├── nes/ │ ├── snes/ │ ├── genesis/ │ ├── gb/ │ ├── n64/ │ └── psx/ └── bios/
Copy your ROM files into the appropriate subdirectory. Make sure filenames don’t have special characters or excessive spaces—some cores have issues parsing them.
The BIOS folder is crucial for systems that need firmware to boot. PlayStation 1 and N64 require BIOS files (legally, you must own the original hardware to dump these files yourself). Obtain them legally, then place them in the BIOS folder.
Configure RetroArch to know where these directories are: Settings → File Browser → Browse File Path and specify your ROMs directory. Then Main Menu → Scan Directory to auto-populate your game library.
Performance Tuning: Making Games Actually Run Smoothly
On lower-end Pi hardware, some games will stutter unless you optimize a few settings. This is where understanding the actual bottlenecks matters.
Frame Skip (Settings → Video → Frame Skip) allows RetroArch to skip rendering frames to maintain audio timing. This keeps audio in sync but makes gameplay look choppy. Enable it only if you’re getting constant audio dropouts; frame skipping should be a last resort.
Run Ahead (Settings → Latency) is a more sophisticated approach. It runs the emulation a few frames ahead of display, predicting controller input and reducing perceived input lag. This is computationally expensive but makes control feel more responsive. For Pi 3 or lower, this often makes performance worse, not better. Pi 4 can handle 1-2 frames of run-ahead without dropping performance.
VSync should be enabled (Settings → Video → VSync). VSync synchronizes the emulation output to your display’s refresh rate, preventing screen tearing and keeping everything locked together. On a Pi running at 60 fps to a 60 Hz display, VSync is essential.
If a specific game stutters constantly, check which core is emulating it. Some cores are more efficient than others. Genesis Plus GX is more optimized than Blastem. PCSX ReARMed (PlayStation) is light-years faster than Mednafen on a Pi 3. Try alternative cores if available.
Network Configuration and Remote Access
If you’re setting up your RetroArch machine in the living room but want to manage games from your computer, SSH is invaluable.
On your Pi, enable SSH: Open a terminal and run sudo systemctl enable ssh && sudo systemctl start ssh. Your Pi will now accept remote connections.
From another computer on your network, you can transfer ROMs, configure settings, and restart RetroArch without physically touching the Pi. Use an SFTP client like FileZilla to drag-and-drop files easily.
If you’re adding ROMs frequently, consider mounting a network share. This eliminates copying files between machines altogether.
Troubleshooting the Most Common Issues
Controllers not responding: You mapped them in RetroArch, but games don’t register input. First, verify the controller actually works: go to Settings → Input → User 1 Input Descriptors. Hold buttons and watch for activity. If nothing shows, either the controller isn’t properly connected or RetroArch didn’t detect it. Unplug and replug the USB. If a specific button doesn’t register, go back to Settings → Input → User 1 Binds, delete that binding, and remap it.
Audio crackling or dropouts: This is usually audio clock instability. In Settings → Audio, reduce the sample rate to 44.1 kHz (if it’s at 48 kHz). This sometimes helps. If the issue persists, disable Audio Sync temporarily to isolate whether the problem is sync-related or a hardware driver issue. On older Pi models, this is sometimes unfixable without upgrading hardware.
Games running at incorrect speed: If a game is noticeably fast or slow, it’s usually a refresh rate mismatch. Check Settings → Video → Refresh Rate. NTSC games (North American, Japanese) need 60 Hz. PAL games (European) need 50 Hz. If your display won’t support 50 Hz, you’ll need to either find a 60 Hz ROM dump or accept slight speed error.
Cores won’t load or crash on game start: Your BIOS files may be missing or incorrectly named. PSX requires scph1001.bin (or a compatible alternative). N64 and Dreamcast also require specific BIOS dumps. Download them, verify their names exactly match what the core expects, and place them in the BIOS folder. If you’re unsure of the correct filename, check the core’s documentation on the libretro GitHub.
Game save files disappearing: RetroArch stores saves in ~/.config/retroarch/saves/ by default. If you’re moving ROMs to different folders, saves might not follow. Configure an explicit save directory: Settings → Saving → Save/Load Folder. Point it to a consistent location, and all new saves will go there regardless of where the ROM file lives.
Why Modern Emulation Beats Flashcarts on Older Hardware
If you’re familiar with the retro gaming community’s other options—flashcarts like the Everdrive or Flashcart—you might be wondering why bother with emulation at all. The answer lies in the actual performance and flexibility trade-offs.
Everdrive and similar devices are ROM cartridges that play game files on original hardware. They’re perfect for preservation and have zero compatibility issues because they’re literally running on real systems. But they’re expensive ($150-300+), limited to a single system, and the experience depends on your original console’s condition.
RetroArch on a Raspberry Pi costs $50-150 for the hardware and offers access to hundreds of games across 20+ systems, instant save/load states, cheat codes, ability to apply modern improvements like widescreen patches, and the ability to adjust performance and visual filtering real-time. You get consistent, reliable performance across the entire library instead of hunting down clean original hardware.
There’s a role for both. Flashcarts are ideal if you have original hardware and want the authentic experience. RetroArch is better for collecting and accessibility. The modern retro gaming hobbyist often uses both—original hardware for deep engagement with specific games, emulation for breadth across many systems.
Advanced Configuration: Overlays, Shaders, and Per-Game Settings
Once basic setup is working, RetroArch offers deep customization. You can apply visual filters (shaders) that simulate CRT monitors, add on-screen overlays that frame games with bezel art, and configure specific games to use different settings than the default.
Shaders are particularly useful. A good CRT shader makes pixel-art games look like they’re displayed on a period-accurate television—slightly soft, with scanlines visible, the way people actually played these games in the 1980s and 90s. Navigate to Settings → Video → Shaders and experiment. On a Pi 3, complex shaders reduce performance. On a Pi 4, most shaders run without issue.
Overlays are aesthetic—they overlay artwork around the game image to look like the original hardware bezel. Download overlay packages from libretro’s GitHub repository and extract them to ~/.config/retroarch/overlays/. Then load them per-game: Main Menu → Game Options → Video Overlays.
Per-game overrides let you save custom settings for specific ROMs. If one game runs poorly with your default settings, you can tweak its configuration and save it only for that file. Settings → Custom Per-Core or Per-Game Settings works here.
Understand that overlays and shaders are purely visual—they don’t affect the actual emulation or gameplay. They’re nice quality-of-life improvements but not necessary for the system to function.
Building a Real Game Library Without Guessing
Once RetroArch is working, you’ll want games. The obvious temptation is to dump entire ROM databases online and load everything. Don’t.
You’ll end up with thousands of games you’ll never play, most of which won’t work correctly on a Pi anyway. N64 and PSX games are particularly fickle—some run perfect, others have audio sync issues, graphics glitches, or input lag.
Start with known-good ROM dumps of games you actually want to play. Verify they work on your specific setup before adding more. If you want a pre-curated collection, the libretro community has published “best of” lists for each system with verified compatibility.
Also, understand the legal position: ROMs of games you own are generally considered acceptable for personal backup. ROMs of games you don’t own are copyright infringement, legally speaking. I’m not here to judge your choices, but understand the actual legal and ethical landscape you’re navigating.
When to Stop Tweaking and Actually Use the Thing
RetroArch is endlessly customizable, and there’s a real danger of spending 20 hours optimizing settings and never actually playing games. At some point, “good enough” is good enough.
A basic setup that works—integer scaling, audio sync enabled, controllers mapped, default performance settings—will handle 95% of your use cases. The remaining 5% of advanced optimization (run-ahead, per-game overrides, complex shaders) is for people who are comfortable with Linux configuration and actually want to pursue that level of detail.
Set your expectations realistically: NES and SNES will look and sound perfect on a Pi 3. Genesis and Game Boy will be flawless. N64 will be playable but slightly less polished than the original hardware (some games have minor audio desync or graphical issues). PSX will work well for most games, terribly for a few. Dreamcast is hit-and-miss and requires a Pi 4.
Emulation is a compromise between convenience (one box, hundreds of games, instant saves) and fidelity (original hardware, perfect accuracy, no configuration). RetroArch on a Pi gives you 90% of the convenience with 95% of the accuracy, and that’s legitimately good.
Start with the setup I’ve outlined, load 10-15 games you genuinely want to play, and use it for a week before tweaking anything. You’ll discover real problems (audio issues, controller lag) versus perceived problems (my shader isn’t perfectly CRT-accurate). Real problems deserve fixes. Perceived problems are usually bikeshedding.
Conclusion: From Configuration to Actual Gaming
RetroArch on a Raspberry Pi is a genuinely impressive achievement—affordable, flexible, accurate emulation of systems from the 1970s through early 2000s, all in a machine the size of a credit card. The setup is straightforward once you understand the basic architecture: OS → RetroArch → cores → ROMs → controllers → configuration.
The most common mistakes come from skipping steps (installing an outdated version, using a pre-built image without understanding it, not enabling audio sync) or expecting it to be plug-and-play. It’s not magic, it’s engineering. Spend 2-3 hours on setup following the sequence in this guide, verify each step works, and you’ll have a system that runs smoothly and reliably for years.
The actual experience—loading a favorite childhood game, having it run perfectly, saving at a tough point and continuing later—justifies the initial configuration effort. Good emulation done right is genuinely indistinguishable from playing the original hardware in most cases.