bsnes vs Snes9x vs RetroArch: SNES Emulation on PC [2026]

Nintendo has never sold a Super Nintendo Classic Mini in every region, never restocked the ones it did sell for long, and has shown zero interest in bringing SNES Online libraries up to full parity outside its own subscription tier. That gap is exactly why three free PC projects still matter in 2026: bsnes, Snes9x, and the SNES cores bundled inside RetroArch. All three are open source, all three run the same 25-year-old cartridge library, and all three take a different bet on what “accurate emulation” should cost you in CPU cycles.

The debate is not new, but it has sharpened. bsnes just shipped v115, tagged on GitHub as “byuu’s final release” — a quiet, permanent marker of the project’s origin under its late creator, byuu (also known as Near), who died in 2023 and whose cycle-accurate design philosophy still defines the emulator’s architecture. Snes9x pushed out 1.63 as a “mainly bug-fix” update, with Windows builds refreshed as recently as August 7, 2026. And RetroArch keeps shipping a Snes9x-based libretro core (profiled at version 1.61 in March 2026) alongside bsnes-derived cores, letting one frontend run either accuracy model depending on which core you load. This article breaks down what each option actually gets you: coprocessor support, shader pipelines, netplay stability, hardware requirements, and which one you should actually install today.

Why SNES emulation still splits into three camps

Most retro consoles converge on a single dominant PC emulator. PS1 has DuckStation. PS2 has PCSX2. The SNES never did, because the Super Nintendo’s cartridge hardware wasn’t uniform. Nintendo and its partners shipped custom coprocessor chips inside specific carts to push past the base console’s limits: the Super FX chip powered Star Fox’s polygon rendering, the SA-1 sped up Super Mario RPG and Kirby Super Star, the DSP-1 handled the 3D math in Pilotwings, and the SPC7110 and S-DD1 chips ran data compression tricks in titles like Front Mission: Gun Hazard. Emulating the base CPU and PPU accurately is one problem. Emulating a dozen bespoke coprocessors, each with its own timing quirks, is a much bigger one.

bsnes was built to solve that second problem completely, prioritizing low-level, cycle-accurate emulation of every coprocessor Nintendo ever shipped, even at the cost of raw speed. Snes9x took the opposite bet: broad compatibility and speed first, with coprocessor support layered in incrementally over two decades of community contributions. RetroArch didn’t pick a side — it wraps both lineages as interchangeable “cores,” so the actual accuracy-versus-speed decision happens per game, not per install. That three-way split is why this comparison still matters in 2026 instead of collapsing into a single default choice the way most retro platforms have.

bsnes vs Snes9x vs RetroArch: full specs comparison

Spec	bsnes	Snes9x	RetroArch (SNES cores)
Latest version	v115 (“byuu’s final release”)	1.63 (Windows builds refreshed Aug 7, 2026)	Bundles snes9x core (v1.61, profiled March 2026), snes9x_next, pocketsnes, plus bsnes-derived cores
Core design philosophy	Cycle-accurate, low-level hardware emulation	Compatibility and speed-focused	Frontend for swappable cores of either philosophy
Coprocessor emulation	Low-level emulation of all documented SNES coprocessors (Super FX, SA-1, DSP-n, ST-01n, CX4), plus optional high-level fallback modes	Broad but historically incremental coprocessor support, improved release over release	Inherits whichever core’s coprocessor support you load (snes9x-level or bsnes-level)
Save states	Yes, with undo/redo support	Yes, standard slot-based states	Yes, plus rewind and run-ahead at the frontend level
Netplay	Not a headline feature in current builds	Built in, though the project’s own GitHub tracker has logged netplay stability reports around the 1.62-1.63 line	Yes, frontend-level netplay works across supported cores
Shader support	OpenGL multi-pass pixel shaders, plus built-in filters like HQ2x and blargg’s snes_ntsc	RetroArch-compatible shaders: Cg shaders on Windows, plus added support for libretro .slangp/.slang presets	Full libretro shader stack (slang, Cg, GLSL) shared across all loaded cores
Platform support	Windows, macOS, Linux	Windows, macOS (community/legacy builds), Linux/GTK builds available via source	Windows, macOS, Linux, Android, iOS, Steam Deck/SteamOS, and consoles via homebrew
CPU demand	Higher — low-level coprocessor simulation is deliberately expensive to compute	Lower — designed to run comfortably on modest and older hardware	Depends entirely on which core is loaded
License / price	Free, open source	Free, open source (freeware)	Free, open source
Maintainer status in 2026	Community-maintained since byuu’s 2023 death; v115 marked as his last personal release	Actively maintained by a rotating open-source contributor group	Actively maintained by the Libretro team, backed by ongoing core updates from both bsnes and Snes9x upstreams
macOS-native frontend integration	Bundled in OpenEmu-Silicon (ARM64-native fork), version 1.2.2 shipped May 21, 2026	Also bundled in OpenEmu-Silicon, tracking a slightly older core revision (1.62.3) than the standalone 1.63 release	N/A – RetroArch is its own frontend, separate from OpenEmu
Extra systems supported	SNES / Super Famicom only	SNES / Super Famicom only	SNES, Satellaview, and Sufami Turbo add-on formats via the snes9x core

Pricing and total cost of ownership

None of these three tools charges a license fee, which makes a traditional pricing table almost pointless on its face. What actually varies is the hardware and peripheral spend needed to get a good experience out of each, since bsnes’s accuracy-first design pushes CPU requirements meaningfully higher than Snes9x or a lightweight RetroArch core.

Cost category	bsnes	Snes9x	RetroArch
Software license fee	$0	$0	$0
Realistic minimum CPU tier for full-speed play	Mid-range desktop CPU from the last 5-6 years recommended for consistent full speed on coprocessor-heavy titles	Runs comfortably on budget hardware, including low-power handhelds and older laptops	Matches whichever core is loaded; a Snes9x core costs little, a bsnes-derived core costs more
Companion physical hardware (optional)	Not applicable – software only	Not applicable – software only	Compatible with Steam Deck, ROG Ally, and most Android handhelds already in most gamers’ collections
Retail FPGA alternative for comparison	Analogue Super Nt (original run, now resale-only, historically priced near $189.99)	Same reference point	Same reference point
Shader packs	Free (bundled filters plus community OpenGL shaders)	Free (Cg and libretro slang shaders)	Free (full libretro shader library)
Ongoing cost	$0, community-funded development	$0, community-funded development	$0, Libretro-team maintained

bsnes: the accuracy-first choice

bsnes exists because its creator, byuu, was not satisfied with “good enough” SNES emulation. The project’s own documentation states it uses low-level emulation of all SNES coprocessors, covering chips like the DSP-n family, ST-01n, and CX4, with optional high-level fallback modes for players who want speed over precision. A project writeup on bsnes.org, “The State of Emulation, Part III,” puts it bluntly: bsnes “now supports every special chip that has ever been emulated,” with the Super FX and SA-1 implementations cited as flagship examples of that completeness, since games rarely use 100% of the coprocessor hardware available to them and bsnes still models the parts they don’t use.

That accuracy comes at a real cost. Because bsnes models coprocessor timing at a low level rather than approximating it, it demands considerably more CPU headroom than Snes9x for the same game. This tradeoff was a genuine bottleneck on 2010s-era hardware; it is far less of a limiting factor on any desktop or laptop CPU sold since roughly 2020, but it still means bsnes is not the automatic pick for someone trying to squeeze SNES emulation out of a budget mini PC or an older handheld.

The project’s current release, v115, is explicitly tagged on GitHub as “byuu’s final release” – a designation that has stuck since byuu’s death in 2023 and that the community has treated as a marker rather than something to overwrite. Development since then has continued under community stewardship on the bsnes-emu GitHub organization, which today hosts a single actively maintained repository dedicated to the emulator. For macOS users specifically, bsnes cores are also bundled into OpenEmu-Silicon, an ARM64-native fork of the popular OpenEmu frontend, which shipped version 1.2.2 on May 21, 2026 with ongoing work on save-state serialization and achievement-tracking compliance.

Snes9x: speed, compatibility, and two decades of momentum

Snes9x has been the default “just works” SNES emulator for most PC users since the late 1990s, and its 2026 release cadence shows the project has no intention of slowing down. Version 1.63, described in its own changelog as “mainly a bug-fix release,” remains the current stable build, with Windows binaries on Emulator Zone dated as recently as August 7, 2026 – evidence the project is still cutting fresh builds rather than coasting on old downloads. The Snes9x wiki confirms shader support is RetroArch-compatible, with Cg shaders working in both Direct3D and OpenGL modes on Windows, and the project has added support for libretro’s newer .slangp and .slang shader formats, closing much of the visual-fidelity gap that used to separate it from bsnes.

Snes9x’s biggest practical advantage remains hardware friendliness. Where bsnes leans on brute CPU accuracy, Snes9x was built to run acceptably on modest machines, which is a large part of why it remains the default SNES core baked into countless retro handhelds, low-power emulation builds, and Linux distribution repositories – Repology’s package tracker shows Snes9x shipped in current versions across Arch Linux, ALT Linux, Chimera Linux, NixOS, and Chocolatey as of its most recent survey. That ubiquity is also Snes9x’s weak point on the reliability front: the project’s own GitHub issue tracker has logged netplay stability reports tied to the 1.62 and 1.63 release line, a reminder that “widely deployed” and “flawless in every configuration” aren’t the same thing.

RetroArch’s SNES cores: one frontend, two philosophies

RetroArch doesn’t compete with bsnes or Snes9x so much as it absorbs both of them. The libretro ecosystem currently lists three SNES-related cores under the Snes9x lineage alone – snes9x, snes9x_next, and pocketsnes – with the primary snes9x core profiled at version 1.61 as of March 25, 2026, per the RetroBIOS core-tracking project. That core also extends coverage beyond standard cartridges to Nintendo’s Satellaview broadcast add-on and Sufami Turbo cartridge system, formats that neither standalone emulator handles out of the box. Tech Insider’s own RetroArch setup guide lists Snes9x as the recommended default SNES core, with the lighter Snes9x 2010 build as the fallback option for weaker hardware, and neither requires a BIOS file to boot.

The tradeoff is that RetroArch’s bsnes-derived cores have not always been as stable as the platform’s Snes9x cores. A GitHub issue on the libretro/RetroArch repository documents bsnes cores crashing immediately on Android when loading content, while the Snes9x core in the same environment loads without issue – a concrete example of how “more accurate” and “more reliable in this specific frontend” can pull in opposite directions. What RetroArch adds universally, regardless of which SNES core is loaded, is frontend-level rewind, run-ahead input-lag reduction, cross-platform netplay, and the full libretro shader stack (slang, Cg, and GLSL formats), none of which the standalone bsnes or Snes9x builds replicate identically on their own.

Coprocessor and enhancement chip support

This is where the three options genuinely diverge, and it’s the single biggest factor if your SNES library leans on enhancement-chip titles rather than standard cartridges. bsnes’s own documentation confirms low-level emulation of the DSP-n, ST-01n, and CX4 coprocessor families, with full, low-level Super FX and SA-1 support cited by the project as flagship examples of its “every special chip that has ever been emulated” claim. That level of completeness is why bsnes remains the reference implementation that other emulator projects compare themselves against when validating coprocessor behavior.

Snes9x has closed much of the historical gap on mainstream coprocessors like Super FX and SA-1 through incremental community contributions across its 1.5x and 1.6x release lines, though a fully itemized, current chip-by-chip parity chart against bsnes is not something either project publishes as a standing document – the fairest framing, based on both projects’ own materials, is that bsnes remains the accuracy reference while Snes9x prioritizes covering the chips that matter for the vast majority of commercially released games. For niche titles built around chips like the SPC7110 or S-DD1 (used in a handful of late-era SNES releases such as Front Mission: Gun Hazard), bsnes is the safer first choice if a game refuses to boot correctly elsewhere.

Performance and compatibility: what the available data shows

Hard, apples-to-apples FPS benchmarks for SNES emulators are harder to find than for modern GPU-bound systems, mostly because the SNES itself only needs to hit 60 frames per second, and any reasonably current CPU clears that bar for the overwhelming majority of the library without breaking a sweat. What the available project documentation, packaging data, and issue trackers do show is a consistent pattern across three independent sources: bsnes trades raw throughput for coprocessor precision, Snes9x is built to minimize resource demand, and RetroArch’s behavior depends entirely on which of the two philosophies its loaded core inherits.

Data point	Source	What it shows
bsnes coprocessor completeness claim	bsnes.org, “The State of Emulation, Part III”	Describes bsnes as supporting every special chip ever emulated, with the Super FX and SA-1 implementations singled out as complete, low-level examples
Snes9x cross-distribution packaging currency	Repology package tracker	Shows Snes9x 1.63 already live in Arch Linux extra and ALT Sisyphus repositories, alongside older 1.60-1.62.3 builds still shipping in slower-moving distros like Mageia and older ALT Linux point releases
RetroArch Snes9x core version lag	RetroBIOS core-tracking project	Profiles the bundled libretro snes9x core at version 1.61 as of March 25, 2026, roughly two point releases behind the standalone 1.63 build, showing the frontend core doesn’t always track the latest upstream release immediately
bsnes-core stability on Android/RetroArch	libretro/RetroArch GitHub issue tracker	Documents bsnes-derived cores crashing immediately on content load in the Android build, while the Snes9x core in the same environment loads without issue
Snes9x netplay stability reports	snes9xgit/snes9x GitHub repository	Logs netplay-broken reports specifically tied to the 1.62 and 1.63 release line, an issue not mirrored in bsnes’s feature set since bsnes does not market netplay as a core capability

Read together, these five data points from three independent categories of source — official project documentation, third-party packaging trackers, and public issue trackers — paint a consistent picture rather than a contradictory one. bsnes’s documentation-stated goal of full coprocessor completeness lines up with its reputation as the accuracy reference. Snes9x’s presence across nearly every mainstream Linux package repository, refreshed to current versions in the fastest-moving distros, lines up with its reputation as the pragmatic, widely deployed choice. And RetroArch’s mixed signals — faster iteration in some places, version lag in others, core-specific stability differences — reflect the reality of running two upstream projects through one shared frontend rather than any single unified engineering effort.

Installing and configuring each option

The setup effort required for each of the three differs almost as much as their underlying accuracy models. bsnes ships as a self-contained package for Windows, macOS, and Linux directly from its GitHub releases page, with no separate BIOS or firmware file needed to boot commercial SNES cartridges. First-time configuration mostly involves pointing the emulator at a ROM folder and choosing between low-level and high-level coprocessor emulation modes if you’re running on older hardware and need the extra headroom.

Snes9x’s Windows builds are similarly plug-and-play, distributed as freeware archives through sites like Emulator Zone with no installer required, though macOS users increasingly rely on either legacy zones-built binaries or the Snes9x core inside OpenEmu-Silicon rather than a dedicated first-party Mac release. Linux users have the most friction here: GTK and Unix ports exist and are actively maintained in the project’s source tree, but they are not always distributed as ready-to-run binaries, meaning some Linux users compile from source or lean on their distribution’s packaged version instead.

RetroArch has the steepest initial learning curve of the three, simply because it’s a general-purpose frontend rather than a single-system emulator. New users need to download RetroArch itself, then use its built-in core downloader to fetch whichever SNES core they want (Snes9x, snes9x_next, pocketsnes, or a bsnes-derived core), then point a content directory at their ROM collection for the playlist scanner to index. That extra setup step is exactly what buys RetroArch its cross-system flexibility, letting the same install handle SNES, Genesis, PS1, and arcade boards without separate applications for each.

# RetroArch: install a SNES core from the command line (Linux example)
retroarch --menu

# Inside the RetroArch menu:
# Load Core > Nintendo - SNES / SFC (Snes9x)
# Load Content > select your ROM folder
# Settings > Core > enable "core_option" overrides per-game if needed

The legacy of byuu and why it still shapes bsnes today

It’s difficult to write about bsnes in 2026 without acknowledging how directly its design still reflects one person’s philosophy. byuu, who also went by the name Near later in life, spent roughly two decades building bsnes (and its sister project, the multi-system emulator higan) around a single, uncompromising idea: emulation should model hardware behavior at the lowest practical level, rather than approximating outputs that merely look correct. That philosophy is why bsnes emulates coprocessor timing cycle-by-cycle instead of faking the result, and why the project’s documentation still frames coprocessor completeness as its primary achievement rather than framerate or compatibility percentage.

byuu died in 2023, and the emulation community’s response was to freeze the version he last personally shipped as a permanent marker rather than quietly incrementing past it. That’s why GitHub still tags bsnes v115 as “byuu’s final release” years later — a naming choice current bsnes maintainers have preserved through every subsequent update. Development has continued since then under the bsnes-emu GitHub organization, with community contributors maintaining the codebase, but the project’s core architecture and its “accuracy above all else” identity remain exactly what byuu built it to be. That continuity is part of why bsnes still functions as the reference implementation other emulator projects, including Snes9x’s own contributors at times, check their work against.

Common troubleshooting differences between the three

Each emulator tends to fail in different, predictable ways, and knowing which is which saves time when something doesn’t work. bsnes’s most common complaint is stuttering or slowdown on lower-end hardware during coprocessor-heavy sequences, such as Star Fox’s polygon rendering or Super Mario RPG’s Mode 7 effects; the fix is almost always switching from low-level to high-level coprocessor emulation in the settings menu, trading some accuracy for consistent full speed.

Snes9x’s most reported issue in current release cycles is netplay reliability, per the project’s own GitHub tracker covering the 1.62 and 1.63 line — if online play is the goal, testing a short session before committing to a full playthrough with a friend is worth the extra few minutes. RetroArch’s most common failure mode is core-specific rather than universal: the Android build’s documented crash on loading content with bsnes-derived cores is a good example of an issue that has nothing to do with RetroArch’s frontend code and everything to do with how a specific core was compiled for a specific platform. When RetroArch misbehaves, checking whether the same problem persists with a different core for the same system is usually the fastest way to isolate whether the frontend or the core itself is at fault.

Real-world use cases: which emulator fits which player

The right pick depends heavily on what you’re actually trying to do, not on which project has the better reputation. Here’s how the decision plays out across five common scenarios.

Preserving Super FX and SA-1 titles exactly as intended. If your priority is playing Star Fox, Super Mario RPG, or Kirby Super Star with the closest possible fidelity to original hardware behavior, bsnes is the correct default. Its low-level coprocessor emulation is the reference implementation other projects benchmark against, and the CPU overhead is a non-issue on any machine built in the last several years.

Running SNES games on a budget mini PC or an aging laptop. Snes9x’s lighter resource footprint makes it the practical choice when hardware is the constraint, not accuracy. It’s also the emulator most likely to already be packaged for your Linux distribution without needing to compile from source.

Building a multi-console retro gaming setup on one device. RetroArch is the obvious answer here, since it lets you run SNES alongside NES, Genesis, PS1, and dozens of other systems inside a single frontend with a shared control scheme, shared shader library, and shared save-state system, rather than juggling a separate standalone emulator per console.

Playing Satellaview or Sufami Turbo add-on titles. These Japan-only broadcast and cartridge-adapter formats are specifically supported by RetroArch’s snes9x libretro core, per its RetroBIOS system listing, making RetroArch the only mainstream option among the three that handles them without extra configuration.

Steam Deck or handheld PC gaming on the go. RetroArch’s native Steam Deck and Android support, combined with its rewind and run-ahead features, make it the most travel-friendly of the three, especially when paired with a frontend like EmuDeck for one-click setup across dozens of systems at once.

macOS users who want a native, modern interface. OpenEmu-Silicon bundles both bsnes and Snes9x cores into a single ARM64-native macOS frontend, letting Apple Silicon users pick their accuracy tier per game without leaving one app, with the project’s most recent release, version 1.2.2, shipping May 21, 2026.

Netplay, rewind, and quality-of-life features compared

Netplay is where the gap between “supported” and “reliable” matters most. Snes9x has built-in netplay code dating back years, but the project’s own GitHub tracker shows recent bug reports describing netplay as broken across the 1.62 and 1.63 release line, which is worth knowing before planning an online co-op session around it. RetroArch’s netplay implementation operates at the frontend level, meaning it works consistently across whichever core is loaded, and it has a much larger active user base testing it in real time through the wider libretro community. bsnes, by contrast, does not market netplay as a headline feature in its current documentation, keeping its focus on single-player accuracy instead.

Rewind support tells a similar story. bsnes includes native rewind with undo/redo save-state handling built directly into the emulator core. RetroArch adds rewind and its more advanced run-ahead input-lag reduction feature at the frontend level, applying it uniformly whether you’re running a Snes9x or bsnes-derived core underneath. Snes9x’s standalone builds are comparatively feature-light in this specific area, leaning on its RetroArch integration to pick up rewind functionality rather than shipping it natively.

Migration guide: switching between bsnes, Snes9x, and RetroArch

Save files and save states are the biggest friction point when moving between these three tools, since none of them share a common save-state format by default. Here’s how to move your library without losing progress.

Moving from Snes9x to bsnes

Back up your existing .srm save files from Snes9x’s save folder before installing bsnes – these battery-save files are the actual in-game progress and are the priority to preserve.
Install bsnes and point its game library folder at your existing ROM collection; bsnes does not require re-organizing files by default.
Copy your .srm files into bsnes’s save directory, renaming them to match bsnes’s expected filename convention if it differs from Snes9x’s.
Do not attempt to carry over Snes9x save states (.000-.009 files) – save states are emulator-specific and will not load in bsnes. Only battery saves transfer cleanly.
Test a coprocessor-heavy game first (Star Fox or Super Mario RPG are good stress tests) to confirm bsnes is running at full speed on your hardware before committing to the switch for your whole library.

Moving from a standalone emulator into RetroArch

Install RetroArch and download both the Snes9x and a bsnes-derived core through its built-in core downloader, so you can compare both without reinstalling anything.
Import your existing .srm battery save files into RetroArch’s saves folder, matching the ROM filenames exactly – RetroArch matches saves to content by filename, not by internal checksum.
Set up a content directory and let RetroArch’s playlist scanner index your existing ROM collection automatically rather than adding titles one by one.
Configure per-core overrides if you want bsnes-level accuracy for coprocessor titles but Snes9x-level speed for everything else – RetroArch supports this natively through its core association settings.
Enable shaders and rewind gradually, starting with a lightweight CRT shader, since stacking multiple shader passes on top of a bsnes core is the most common cause of frame drops on modest hardware.

Pros and cons

bsnes

Pros: the most accurate coprocessor emulation available for the SNES library; built-in rewind with undo/redo; strong shader and filter support; the reference implementation other projects benchmark against.

Cons: higher CPU demand than the alternatives; no headline netplay feature; development pace has slowed since its creator’s 2023 death, with the current release explicitly framed as his final personal contribution.

Snes9x

Pros: runs comfortably on modest and older hardware; actively maintained with fresh 2026 builds; widely packaged across Linux distributions and handheld firmware; built-in netplay and RetroArch-compatible shader support.

Cons: netplay stability reports on the current 1.62-1.63 release line; coprocessor accuracy trails bsnes for demanding titles; macOS support relies more on community and legacy builds than a first-party release cadence.

RetroArch (SNES cores)

Pros: one frontend for your entire retro library, not just SNES; lets you swap between bsnes-level accuracy and Snes9x-level speed per game; frontend-level rewind, run-ahead, netplay, and a full shader library shared across every core; native support for Satellaview and Sufami Turbo formats.

Cons: bsnes-derived cores have documented stability issues in specific environments, including crashes on Android; more configuration overhead than either standalone emulator; core versions can lag behind the latest standalone releases (RetroArch’s snes9x core sat at 1.61 while the standalone project had already moved to 1.63).

Other SNES emulation options worth knowing about

bsnes, Snes9x, and RetroArch dominate the conversation, but they aren’t the only projects still touching SNES emulation in 2026. higan, byuu’s earlier multi-system emulator and bsnes’s spiritual predecessor, pursued the same cycle-accurate philosophy across several Nintendo platforms at once rather than focusing on SNES alone; it’s effectively superseded by bsnes today but remains historically significant as the project where much of bsnes’s low-level coprocessor work originated. Mesen-S, a fork built on the accuracy-focused Mesen NES emulator codebase, carved out a smaller but dedicated following among speedrunners and tool-assisted-speedrun creators for its frame-precise debugging tools, though it has seen far less active development in recent release cycles than any of the three emulators covered here. And ZSNES, the emulator that introduced an entire generation of PC gamers to SNES emulation in the late 1990s and early 2000s, has been effectively abandoned for over a decade; its last stable release predates modern coprocessor emulation techniques entirely, and neither the bsnes nor Snes9x teams recommend it for anything beyond nostalgia.

OpenEmu-Silicon deserves a second mention here too, separate from its role as a bsnes and Snes9x host. As an ARM64-native fork of the original OpenEmu project, it represents a broader trend in 2026 emulation: rather than every platform maintaining its own siloed emulator community, frontends increasingly pull in the best available core for each system and let users switch between them without leaving one application. RetroArch pioneered that model years ago; OpenEmu-Silicon’s active May 2026 development, including work on save-state serialization and achievement-hardcore compliance, shows the same pattern taking hold on macOS specifically.

How to choose based on your existing game library

A practical way to make this decision without reading another word of comparison content: sort your ROM collection into three piles. The first pile is standard cartridges with no special chip — most platformers, most sports titles, most straightforward RPGs. Any of the three options handles this pile identically well, so the deciding factor should be hardware and convenience rather than accuracy. The second pile is games built around Super FX or SA-1, the two most common enhancement chips, covering titles like Star Fox, Yoshi’s Island, Super Mario RPG, and Kirby Super Star. bsnes is the safest default for this pile, though Snes9x’s current release line handles most of these titles acceptably well too. The third pile is the small number of commercially released games built around rarer chips like the SPC7110 or S-DD1 — if you own or plan to play any of these, bsnes’s documented completeness on coprocessor support makes it the pile-three default without much debate.

Frequently asked questions

Is bsnes or Snes9x more accurate for SNES emulation?

bsnes is the more accurate option by design. Its documentation confirms low-level emulation of all documented SNES coprocessors, and the project’s own writeup describes it as supporting every special chip that has ever been emulated, with Super FX and SA-1 cited as complete, low-level implementations. Snes9x covers the same major chips but has historically prioritized broad compatibility and speed over the deepest possible timing accuracy.

Do I need a BIOS file for SNES emulation?

No. Unlike PS1 or PS2 emulation, the SNES core in RetroArch and both standalone emulators do not require a separate BIOS file to boot games, per Tech Insider’s own RetroArch core reference table.

Which SNES emulator is best for low-end PCs?

Snes9x, or RetroArch loaded with a Snes9x-based core, is the better choice for weaker hardware. bsnes’s low-level coprocessor emulation is deliberately CPU-intensive, and while that’s rarely a problem on modern desktops, it can be a meaningful difference on budget mini PCs, older laptops, or lower-power handhelds.

Is bsnes still being actively developed after byuu’s death?

Development continues under community stewardship through the bsnes-emu GitHub organization. The most recent release, v115, is explicitly tagged as “byuu’s final release,” marking it as the last version built directly by the project’s original creator, with subsequent work continuing as community-maintained updates.

Can RetroArch run both bsnes and Snes9x cores?

Yes. RetroArch’s core downloader offers both bsnes-derived cores and Snes9x-based cores (snes9x, snes9x_next, and pocketsnes), letting you switch between accuracy-first and speed-first emulation on a per-game basis without installing separate standalone applications.

Does Snes9x support online multiplayer netplay?

Snes9x ships with built-in netplay code, but its GitHub issue tracker has logged stability reports describing netplay as broken on the 1.62 and 1.63 release line. RetroArch’s frontend-level netplay, which works across whichever SNES core is loaded, is generally the more consistently tested option for online play in 2026.

Which emulator supports Satellaview and Sufami Turbo games?

RetroArch’s Snes9x-based libretro core explicitly lists support for the nintendo-satellaview and nintendo-sufami-turbo systems alongside standard SNES cartridges, per the RetroBIOS core-tracking project. Neither standalone bsnes nor standalone Snes9x documents equivalent support for these formats as a headline feature.

Are all three SNES emulators free to use?

Yes. bsnes, Snes9x, and RetroArch are all free, open-source projects with no licensing fee, subscription, or paywalled feature tier. The only real costs involved are indirect: the hardware needed to run bsnes’s more demanding coprocessor emulation at full speed, and the time spent configuring shaders, controllers, and core overrides to your preference.

The verdict: which SNES emulator should you actually install

There isn’t a single correct answer here, and that’s the honest takeaway after comparing all three side by side. If your SNES library leans on Super FX or SA-1 titles and you want the closest thing to original hardware behavior, bsnes remains the reference implementation, and modern CPUs have mostly erased its historical speed penalty. If you’re running emulation on modest or older hardware, or you just want something that installs in under a minute and works, Snes9x’s two decades of compatibility work and its actively refreshed 2026 builds make it the pragmatic default. And if SNES is just one system in a broader retro library spanning Genesis, PS1, and arcade boards, RetroArch is the only one of the three built to be your single frontend for all of it, with the added benefit of letting you load a bsnes-accuracy core for the handful of games that actually need it.

The most practical setup for most players in 2026 is not choosing one and discarding the other two – it’s installing RetroArch as the daily driver, keeping both a Snes9x and a bsnes-derived core downloaded, and switching per game based on whether you’re chasing frame-perfect Star Fox physics or just want Chrono Trigger running instantly on a laptop that’s a decade old.