The golden rule: sync the .srm, treat states as local

Everything hinges on one fact from the Snes9x readme’s own compatibility notes: .srm battery-save files are shared with all SNES emulators. A .srm is the game’s own cartridge save data in a standard form, so the same file works in desktop Snes9x, in the Android app covered below, and in other emulators besides — keep the filename matched to the ROM name and the game simply finds its saves. Save states (.000–.099) are the opposite: snapshots of one emulator’s internal state, in a format that has changed across Snes9x’s own history (the current snapshot format dates from 1.52 and is incompatible with 1.51’s), so a state written by one program or version may not load in another. Sync states between two installs of the *same* desktop Snes9x if you like — the files live in the same folder — but build your cross-device habit around the .srm, and make real in-game saves before switching devices. The .rtc clock file, where a game uses one, travels with the .srm the same way.

Where the files live on PC

By default both save systems write to the Saves folder next to snes9x.exe (.\Saves) — battery saves and states alike, as the save states guide details. The location is changeable in Snes9x’s settings, and that setting is the whole trick: point Snes9x’s Saves folder at a directory inside your synced cloud folder, and every .srm update is uploaded when you quit and downloaded before your next session on the other machine. Any mainstream sync service works for this — Google Drive, OneDrive or pCloud are all the same to Snes9x, because it just sees a folder. We make no speed or reliability claims for any of them; pick on your own preferences, and remember a synced folder is a copy mechanism, not a backup — keep an occasional separate copy of the Saves folder too, since a sync faithfully propagates deletions and corrupt files as happily as good ones.

The Android side: Snes9x EX+

Mainline Snes9x has no Android build; the Android app is Snes9x EX+ by Robert Broglia, a separate program covered on our Snes9x for Android page. EX+ uses the same .srm idea — battery saves as standard files the game reads and writes — so the practical workflow is: play on PC, save in-game, let the cloud folder sync, then on the phone make sure the synced .srm sits where EX+ looks for the game’s saves (with the same base filename as the ROM) and start the game — your in-game saves are simply there. Reverse the trip to bring progress home. Save states, per the golden rule, should not be part of the plan: use them freely on whichever device you are holding, but hop devices only at battery-save points. Before a long session on either side, a thirty-second habit saves real grief: confirm the last sync actually completed (the .srm‘s timestamp is the tell) before overwriting anything.

Filenames, and the two mistakes that break sync

The whole system stands on one humble detail: the .srm must carry the same base name as the ROM it belongs to. If the game file is renamed on one device — a “cleaned up” filename, a region tag added, a duplicate’s “(1)” suffix — the emulator on that device looks for a matching save file, does not find the synced one, and quietly starts a fresh .srm beside it. Your progress is not gone; it is in the other file, un-loaded. Keep ROM filenames identical on PC and phone and this entire class of problem disappears. The second mistake is treating sync as instantaneous: edit the save on the phone before the PC’s last upload finished, and the two files race. Save in-game, quit the emulator (the .srm is written on exit, as the hotkeys reference era of habits should remind you to do properly), watch the sync complete, then switch. If you are also setting up the desktop side from scratch, the Windows setup guide covers choosing a writable home for the emulator, which is what makes pointing its Saves folder at a synced directory painless.

A workable routine

• Set the PC’s Saves folder (in Snes9x settings) to a folder inside your sync service
• Play normally; always make an in-game (battery) save before switching devices
• Let the sync finish, then place/confirm the same .srm beside the ROM on Android
• Use save states for moment-to-moment convenience on one device only
• Keep a periodic manual backup of the whole Saves folder outside the sync

Done well, this makes the PC and phone feel like one console with two screens. The rest of the series — settings, controllers, shaders, netplay — is in the setup hub, and if saves misbehave anywhere in the chain, Snes9x saves not working is the troubleshooting companion.

Going fullscreen: Alt+Enter

The fullscreen shortcut is Alt+Enter, which toggles between fullscreen and windowed mode — it is a fixed menu accelerator in the Windows build rather than part of the remappable hotkey table. Two companion keys matter in fullscreen: Esc shows or hides the menu bar (your way back to the menus without leaving fullscreen), and the standard gameplay hotkeys — save states on Shift+F1–F10, screenshots on F12, pause — keep working; the complete list is in the hotkeys reference. If you use a controller exclusively, map your workflow so state saves happen from the pad side via the controller setup, and keep Alt+Enter itself on the keyboard.

The output method under the picture

Fullscreen behaviour sits on top of the chosen output method — DirectDraw, Direct3D, OpenGL or Vulkan, the four the Windows build registers. For fullscreen play on a current PC, OpenGL or Vulkan remain our recommendation: they are the modern paths, they scale the image with the current filtering and shader options, and they are where slang and GLSL shaders live (the shaders and filters guide maps which formats each driver takes). Direct3D is the fallback with Cg shader support; DirectDraw is legacy compatibility only. If a fullscreen image looks wrong in one driver — distorted, offset, or not filling as expected — switching output method is a legitimate first diagnostic before touching anything else.

Aspect ratio: the setting that changes how games look

The SNES’s output was displayed on 4:3 CRTs, and games were drawn with that in mind. Snes9x’s display settings let you keep the correct aspect ratio — black bars at the sides on a widescreen monitor, picture proportions as designed — or stretch the image to fill your screen, which removes the bars at the cost of visibly wider sprites and circles that become ovals. Neither is a moral choice, but only one is the picture the artists drew; our strong default is to keep the correct ratio. Version 1.63 added an aspect-ratio hotkey to the program (one of that release’s genuine hotkey additions, alongside the cheat keys) — its current binding lives in Input → Customize Hotkeys, which is where to check or change it rather than trusting a printed combo. Whichever way you jump between ratios, do it mid-game with the hotkey once, see both on your own display, and then settle.

Filtering and scaling choices

In the display settings you will also find the filtering options that decide how the low-resolution image is enlarged. Left unfiltered, SNES pixels scale into large, hard-edged blocks — exactly accurate to the source, and the look many players prefer. Bilinear-style filtering smooths those edges into a softer picture, which some players find easier on a big modern screen and others find blurry. There is no performance argument that matters here on any current machine; it is purely taste, it changes nothing about emulation accuracy or your saves, and it can be flipped freely — including per mood, since it touches no game data. Combined with a shader preset from the shaders guide, filtering is the second layer of the look; adjust one layer at a time.

Windowed play is not a failure mode

Nothing in this guide should read as “fullscreen is the correct way to play”. A window has real advantages: it sits happily beside a guide or a chat window, it makes the Esc menu-bar toggle and the preview dialogs feel natural, and it is the better choice on an ultrawide or unusually tall monitor where a fullscreen image would leave most of the glass empty anyway. Snes9x makes the choice reversible with one keystroke, so the sensible workflow is to start windowed while you set up — mapping a controller, checking saves, picking a shader — and press Alt+Enter when you settle in to actually play. If you run more than one display, keep the emulator on the screen you intend before toggling fullscreen, and if the picture lands somewhere unexpected, Alt+Enter back to the window and move it rather than fighting the settings. The display dialog’s job is to make both modes look right, not to recruit you into one of them.

A calm fullscreen checklist

• Output method on OpenGL or Vulkan before judging picture quality
• Alt+Enter to toggle fullscreen; Esc reveals the menu bar inside it
• Aspect ratio kept correct unless you deliberately prefer the stretch
• Filtering set by taste (crisp vs. smoothed), changed one option at a time
• If the image is wrong in one driver, try another output method before deeper fixes

One more combination worth knowing: fullscreen, correct aspect ratio and a CRT-style shader preset together reproduce something close to the original living-room picture, while fullscreen with the ratio stretched and no shader is the furthest point from it. Most players land somewhere between — ratio correct, filtering to taste, shader optional — and there is no prize for landing at either extreme. Choose the picture you enjoy looking at for a whole game, not the one that wins an argument.

Display sorted, the remaining tutorials — settings, saves, cheats, netplay — are gathered in the setup hub.

The three formats, at a glance

• Cg (.cg, .cgp presets) — works with both the Direct3D and OpenGL output methods. The oldest of the three ecosystems here, and the one with a prerequisite (below)
• GLSL (.glsl, .glslp presets) — OpenGL only, drawn from libretro’s glsl-shaders collection
• Slang (.slang, .slangp presets) — works with OpenGL (supported since version 1.59) and with Vulkan (since version 1.62, when the Vulkan output method itself was added), drawn from libretro’s slang-shaders collection

The file dialog tells the same story: the Direct3D shader picker accepts *.shader; *.cg; *.cgp, while the OpenGL and Vulkan pickers accept those plus the GLSL and slang extensions. If a shader file does not even appear in your picker, a format/output mismatch is the first thing to check — the shader is not broken, it is just not offered for that driver. Single shaders and multi-pass presets (the p-suffixed files bundle several passes and their settings) are both normal; most shared downloads are presets.

Cg and the NVIDIA Cg Toolkit

Cg is the special case. In the readme’s own words: “If you want to use CG Shaders in Snes9x for windows you need to install the CG Toolkit” — NVIDIA’s Cg Toolkit must be installed on the system for Cg shaders to run, in either Direct3D or OpenGL mode. That requirement is historical baggage from Cg’s origins as NVIDIA’s shader language. Nothing similar applies to GLSL or slang: choose OpenGL or Vulkan output, point Snes9x at a shader or preset from the libretro collections, and no extra runtime is involved. Unless you have a specific Cg preset you love, new users should start with GLSL or slang and skip the Toolkit entirely.

Which combination should you pick?

For a modern Windows PC, slang on OpenGL or Vulkan is the forward-looking choice: slang is the format libretro’s shader ecosystem actively develops, and Snes9x has supported it on OpenGL since 1.59 and on Vulkan since 1.62. GLSL on OpenGL is the equally comfortable alternative with a large existing preset library. Cg is a legacy-compatibility choice today — fully functional, but carrying the Toolkit prerequisite. DirectDraw, the fourth output method, is not part of this shader story at all; if shaders matter to you, you are on Direct3D, OpenGL or Vulkan. Output-method selection itself — the setting that gates all of this — is covered step by step in the best settings guide, and full-screen presentation in the fullscreen and display settings guide.

What shaders can and cannot do

A shader changes only the picture — it cannot add detail the game never drew, fix a bad ROM, or improve emulation accuracy, and claims otherwise (any “upscaling to true HD” language) should be read as marketing for the preset, not a property of Snes9x. What the good presets genuinely offer: authentic CRT simulation (scanlines, aperture grille, curvature, glow), alternative pixel-art scaling looks, or colour adjustments. Tastes differ sharply per game and per display, which is why Snes9x makes presets easy to swap: try one for a full level, not a title screen, before judging, and keep a “no shader” baseline you can return to so comparisons stay honest.

Trying presets without making a mess

Shader presets are small text files, so treat collecting them like collecting anything else from the internet: download from the libretro shader collections or other sources you trust, keep them in a folder you can find again, and add them a few at a time. When you test a preset, judge it in real gameplay at the size you actually play — a CRT simulation that looks superb paused on a title screen can smear badly in motion, and a smoothing preset can be lovely in a colourful platformer and wrong for a text-heavy RPG. Note that a preset’s look also depends on your output size and filtering choices, so compare candidates with everything else held constant. If a shader fails to load or produces a black screen, do not debug the preset file first: check the format against your output method with the table above, because nine times out of ten the preset is fine and the pairing is wrong.

A format that is gone: HLSL

Older tutorials list an HLSL shader option for Snes9x. It was a real feature once, but the changelog records its removal in version 1.57 (“Remove rarely-used HLSL shader option”), and it is not part of 1.63. If a guide’s shader advice depends on HLSL menu entries you cannot find, that is why — move to the Cg/GLSL/slang options above instead. ## Performance, briefly and honestly

Players sometimes ask whether a heavy multi-pass preset will slow the game down. The honest answer is that it depends entirely on your graphics hardware and the preset, and Snes9x publishes no figures to quote — so test on your own machine: if a preset causes stutter that vanishes when it is removed, the preset was the cost, and choosing a lighter one (or none) is the whole fix. On any reasonably modern GPU the common presets are not a practical concern, but your machine, not a website’s promise, is the authority.

Keep exploring via the setup hub, where the display and settings tutorials are collected together.

How a session works

One machine acts as the server. Its user is player 1 — the “master” — and chooses which game is played. Everyone else connects as a client and joins in order as players 2, 3, 4 and 5: netplay supports up to five players in total, mirroring the SNES Multitap. Clients connect through the Netplay menu’s “Connect to server…” option and enter the server’s IP address or host name. The bundled readme’s advice on choosing a host is simple: the server should be the fastest machine on the fastest connection, because everyone else’s experience is paced by it. All machines need TCP/IP connectivity between them, and for internet play the readme notes you need short ping times — SNES netplay of this design assumes a responsive link, not a high-bandwidth one. When a player joins late, the server brings them into sync by sending SRAM data plus a reset, or a freeze file.

Before starting, get every player’s game ready: everyone needs the same game (the host picks it, and mismatched ROMs are a recipe for a session that falls apart), and each player needs their pad mapped — the controller setup guide covers that in five minutes. Agree your save approach too: battery saves get synced by the host’s flow, and the save states and .srm guide explains which files hold what.

The port, and making the host reachable

Snes9x netplay listens on default TCP port 6096. On a home LAN that is usually all you need — clients point at the host’s local address and connect. For a friend connecting from the internet, the host must be reachable: in practice, on a typical home router that means forwarding TCP port 6096 to the host PC and giving the friend the host’s public IP address. (To be precise about sourcing: “port forwarding” is our practical how-to wording for this requirement — the readme itself documents the server model and port rather than using that phrase — and it is also how the Emulation Gametech Wiki summarises this netplay.) No account, service or VPN is involved or needed: it is a direct connection between the players’ machines, and you should be suspicious of any guide that tries to sell you one for this.

The honesty caveat — read this before planning a session

We will quote the bundled readme’s maintainer note in full, because it is the single most important fact about Snes9x netplay: “NOTE 2017 OV2: netplay has not been maintained and tested in a long time, so it might be broken.” That note still ships with version 1.63. Concretely, this means: some sessions will work fine, especially on a LAN or a low-latency internet link; others will fail to connect or will desync — the readme itself warns that client machines which cannot keep up desync the session, leaving players watching different games. Set expectations by game choice, too. Netplay of this design sends inputs between machines and expects every emulator to stay in lockstep, so it suits games where all players share one screen and one pace — racers, fighters, co-op platformers, puzzle battles. It is a poor fit for anything where a dropped connection strands hours of progress, which is another reason the checklist’s “agree what happens on a desync” step matters more for a long RPG session than for a best-of-five in a fighting game.

If a session desyncs, the realistic fixes are unglamorous: fewer players, the strongest machine hosting, wired rather than wireless connections, and the lowest-latency link you have. There is no setting that guarantees success, and no honest guide can promise you one.

A pre-session checklist

Most failed sessions are lost before the game starts, so run the boring checklist first. Everyone installs the same Snes9x version from the same source and loads the host’s chosen game once, alone, to confirm it runs. The host — the fastest machine on the fastest connection — starts the server and confirms the router forwards TCP port 6096 to that PC if anyone is joining from outside the LAN. Each player maps their controller locally, in their own copy, before connecting; netplay does not share or fix mappings. Join in order, so player numbers match what everyone expects, and agree in advance what happens on a desync: who re-hosts, and from which save. Five minutes of this is the difference between an evening of Mario Kart and an evening of router administration — and if the session still will not behave, that is the cue for the alternative below, not for buying anything.

The maintained alternative: RetroArch netplay

If netplay is your main reason for playing rather than an occasional extra, the maintained path is RetroArch netplay with the Snes9x libretro core — the libretro documentation explicitly lists the core as “Recommended for netplay”, and RetroArch’s netplay is actively developed in a way the standalone feature, by its own author’s note, is not. You still get the Snes9x emulation core; only the surrounding program changes. Our Snes9x RetroArch core guide explains how the core relates to the standalone program. Trying standalone netplay first costs nothing and keeps everything in the program covered by the setup hub — just go in with the expectations above and a fallback plan.

Entering a code in the cheat editor

Load your game, then open the cheat editor with Alt+G (the full keyboard list is in the hotkeys reference). Add a new entry and type or paste the code. Snes9x understands three input styles:

• Game Genie codes — the letter-and-dash codes published for the original Galoob device; just enter them as printed
• Pro Action Replay codes — the hex codes from the PAR ecosystem, entered as published
• Raw codes — the standard raw format xxxxxx=bb, with an optional compare form xxxxxx=cc?bb; version 1.63 additionally accepts the Address:byte input form for the same thing

Give each code a description so future-you knows what it does — “infinite lives” ages better than “code 3”. Codes can be enabled and disabled from the editor, so you can keep a library per game and switch individual effects on only when wanted. A practical caution: leave codes off until you have a clean battery save of your progress, because a code that corrupts game state gets written into your .srm like any other save — the save states and .srm guide explains how those files work and why a pre-cheat backup is cheap insurance.

How .cht files work

When you enter codes for a game, Snes9x saves them in a .cht file for that game, and auto-loads the file whenever the same game is loaded again — enter a code once and it is simply there next session, in whatever enabled state you left it. The format is not Snes9x-proprietary: per the bundled readme, .cht files are shared with higan and bsnes, so cheat collections you build in Snes9x can be carried to those emulators and vice versa. Keep that in mind when downloading code collections: a .cht offered “for bsnes” is very likely usable here too, subject to the same care about safe sources you would apply to any file.

Finding your own codes with cheat search

For effects nobody has published a code for, Snes9x includes a built-in cheat search (finder). Open it with Alt+A and the workflow runs like this: the tool snapshots a value in the game’s memory — lives, health, ammunition, whatever is displayed as a number — then you play until the value changes and search again. Each pass narrows the candidate memory addresses until only the address(es) actually holding that value remain, and you can turn a surviving address into a raw code in the formats above. It rewards patience: the cleaner the value (a small counter that only changes one way), the faster the search converges. The Mac port gained its new cheat finder in 1.63; on Windows the search is a long-standing part of the program.

Entering codes without the usual mistakes

Work through a new code methodically and it will either work or tell you why not. Enter it character for character as published — Game Genie codes include their dashes as printed, and raw codes are unforgiving of a transposed digit, because a wrong address is not an error message, it is a different location in memory that may do nothing or something strange. Enable just that one code, return to the game, and test the exact situation the code describes; a code for lives will not announce itself on a screen that never shows lives. If it works, write the description properly while you remember what it does. If it does nothing, the order of suspicion is: a typing error, the code being disabled, then a region mismatch between the code list and your ROM — the same game released in Japan, North America and Europe is three slightly different programs, and their code lists are not interchangeable. Only after those three should you suspect the code itself was published wrongly, which does happen on older lists.

Cheat etiquette and troubleshooting

• A code that “does nothing” is most often disabled in the editor, entered with a typo, or published for a different regional version of the game — code lists are region-specific, because different releases put data at different addresses
• Freeze-type effects depend on the emulator applying the code continuously; if an effect applies once and fades, check the entry is still enabled
• Stacking many codes invites interactions — enable one at a time when diagnosing
• Codes and netplay do not mix sensibly: everyone in a netplay session must be running the same game state, and cheats break that assumption
• Always keep an un-cheated .srm backup of a long-running game (RPGs especially) before experimenting

Keeping a library that stays useful

Because .cht files load automatically, your cheat library quietly becomes part of how the game boots — which is pleasant until a forgotten always-on code changes a game you wanted vanilla. Develop the habit of reviewing a game’s list in the editor whenever behaviour surprises you, and of disabling rather than deleting codes you have finished with: the entry costs nothing to keep, its description remembers what it did, and re-typing a long code from a website is nobody’s idea of fun. A tidy, described, mostly-disabled library is the end state you are aiming for.

Cheats configured, the rest of the tuning story lives in the setup hub — display settings, controllers and saves included.

One folder for everything: .\Saves

By default, both systems write to the same place: a folder called Saves in the same folder as snes9x.exe — in configuration terms, the save-state directory and the SRAM directory both default to .\Saves. That one detail explains the most common save problem: if you extract Snes9x somewhere Windows will not let it write — inside Program Files, for example — neither your battery saves nor your states can be written reliably. The location can be changed in the settings, and pointing it somewhere sensible is also the foundation of the sync workflow in our cloud save sync guide. When saves go wrong entirely, see Snes9x saves not working.

Battery saves: the .srm file

When a game offers to save — at a save point, after a level, in a menu — it is writing to battery-backed RAM on the original cartridge. Snes9x stores that data in a .srm file named after the game. The file is written out when you unload the ROM or quit, and it is loaded automatically the next time you start the same game, so battery saving needs no hotkey and no menu: just save in-game and close the emulator properly. A related file, .rtc, appears for games with a real-time clock chip and serves the same house-keeping purpose for clock data.

Save states: 10 slots × 10 banks = 100 states

A save state freezes everything — position, health, timers, randomness in flight — so you can return to the exact moment later. Press Shift+F1–F10 to save and F1–F10 to load (the full key list, including the preview dialogs on Shift+F11 and F11, is in the hotkeys reference). Those ten quick slots are only one bank: Snes9x provides 10 banks of 10 slots, up to 100 states per game, a system added in version 1.61. On disk the states are files with a three-digit extension running from .000 to .099, numbered across all banks, saved alongside the .srm in the Saves folder. Older guides claiming “9 slots” are repeating the stale bundled readme text — the current program has ten slots per bank, and 1.63 specifically fixed the QuickSave 0–9 slot shortcuts.

The .oops file: your unsaved-session insurance

There is one more file worth knowing about. If you play for a long time and quit without saving, Snes9x writes an auto-recovery freeze file with the extension .oops into the Saves folder. It is a safety net, not a saving strategy — treat it as a pleasant surprise when it rescues a session, and use real states and battery saves for anything you care about. If you do find yourself relying on it, that is a sign your Saves folder setup needs the attention described in the saves not working fixes.

What the files are, technically

The state (snapshot) format is documented by the project itself: files carry a #!s9xsnp signature and can be gzip-compressed. One consequence matters for archiving: the snapshot format in use since version 1.52 is incompatible with 1.51’s format, a reminder that states are snapshots of one emulator’s internal machinery rather than a universal save format. That is exactly why the portability story below differs between the two systems.

Which saves travel between emulators

This is where the two systems part ways. Per the bundled readme’s compatibility notes, .srm files are shared with all SNES emulators — battery saves are a standard cartridge-RAM dump, so you can move a .srm between Snes9x, other standalone emulators and the Snes9x libretro core and the game will pick up its saves (keep the filename matched to the ROM). .rtc files are likewise shared with bsnes. Save states are the opposite: tied to the emulator and its format version, so treat .000–.099 files as Snes9x-specific and never as your only copy of long-term progress — the .srm is the durable record. Back up the whole Saves folder, keep battery saves for progress that must survive a machine change, and use states for moment-to-moment convenience.

Which system should you trust, when?

Use each system for what it is. A battery save is the game’s own checkpoint: durable, portable between emulators, and written at moments the game designer chose — trust it with anything long-term, especially RPG progress measured in dozens of hours. A save state is a convenience with a shorter memory: perfect for a hard boss attempt, a branching choice, or stopping mid-dungeon, but tied to this emulator’s snapshot format and therefore the wrong place to keep your only copy of anything. The players who lose progress are almost never the ones missing a feature — they are the ones who played for weeks on states alone, or saved only in-game while their Saves folder could not be written. Ten seconds spent knowing which file holds your progress is the entire fix.

Habits that prevent lost progress

• Keep Snes9x in a writable folder so .\Saves can actually be written
• Save in-game (battery) at natural stopping points, not only with states
• Quit the emulator normally so the .srm is written out on exit
• Back up the Saves folder before moving machines or reinstalling
• Rely on .srm files, not states, for progress you move between emulators

Everything else in this series — settings, controllers, cheats, sync — is collected in the setup hub.

Save and load state keys

Older documentation — including Snes9x’s own bundled readme text — describes only F1–F9, because it predates the tenth slot. The current program defines ten save keys and ten load keys, matching the storage model of 10 slots per bank across 10 banks, which is up to 100 states per game stored as files .000–.099. The save states and .srm guide explains banks, files and backups in full.

Gameplay and system keys

A note on Tab: it is a hold-to-speed-up key by default. The program also contains a separate fast-forward toggle action, which ships unassigned — if you prefer a latching turbo, bind it yourself in Customize Hotkeys. The Pause entry is the keyboard’s actual Pause/Break key; do not confuse it with the frame-advance backslash, which only has an effect while emulation is paused.

Cheat keys

These two were among the genuine hotkey additions in the 1.63 era — along with a new aspect-ratio hotkey, whose current binding you can check (and change) in Input → Customize Hotkeys rather than trusting any printed list, ours included, once you have remapped anything. The cheat codes guide covers what to do inside the editor and search once you have them open.

The reset key — an honest answer

You will see “Ctrl+R” printed as Snes9x’s reset shortcut on many websites. It matches neither official source. The readme bundled with 1.63 says Ctrl+Shift+R resets the game; the 1.63 source code’s default key table says Ctrl+Alt+R. The two official sources disagree with each other, so the only fully honest advice is: try the readme’s Ctrl+Shift+R on a standard install, and whatever your install actually uses, you can see and change the binding in Input → Customize Hotkeys. We print it this way rather than inventing certainty the sources do not support.

Rewind: R only works after you enable it

Rewind is a real Snes9x feature — it was added in version 1.54, and holding R rewinds gameplay while the key is down. But it is disabled out of the box: the rewind buffer size defaults to 0, and a zero buffer turns the feature off, so pressing R on a fresh install simply reports that rewinding is disabled. To use it, set a non-zero rewind buffer size in the emulation settings first. How much buffer you need depends on how far back you want to be able to scrub, so start with a modest value and raise it if your rewind runs out too quickly.

Getting more from the defaults

Three habits make the default layout worth learning rather than immediately replacing. First, treat the preview dialogs (Shift+F11 and F11) as your state browser: the quick keys are faster, but the dialogs show you what is actually in a slot before you overwrite or load it, which prevents the classic accident of saving over your only good state. Second, combine pause with the frame-advance backslash when a jump or a menu timing is giving you trouble — stepping frame by frame turns guesswork into observation, and it costs nothing to try. Third, remember that Tab’s turbo is momentary by design: it is meant for skipping a cutscene or fast-walking a corridor, then letting go. If you find yourself holding it for whole games, that is what the unassigned toggle action in Customize Hotkeys is for. None of this changes any default — it is just the defaults used as their designers laid them out, quick keys for speed and dialogs for certainty.

Remapping and restoring sanity

One reference, kept honest

A final word on why this page hedges where it hedges. Hotkey lists are the most-copied, least-checked content in emulation writing: one site’s stale table becomes ten sites’ fact within a year, which is exactly how the incorrect “Ctrl+R” reset shortcut spread and how the old nine-slot story outlived the tenth slot. Everything above is stated as the 1.63 default, sourced from that release’s own readme and key table, with the one genuine disagreement between those sources shown rather than smoothed over. When in doubt, your install’s Customize Hotkeys dialog outranks every website — including this one, the moment you have remapped a single key.

Open Input → Customize Hotkeys to change any binding: select an action, press the new key combination, and confirm. This is also the recovery tool when a printed reference (including a website’s) disagrees with your machine — the dialog shows your install’s truth. If you have remapped heavily and lost track, the dialog is still the place to audit action by action. Pair this reference with the controller setup guide for gamepad mapping, and browse everything else via the setup hub.

Step 1 — Connect the controller before you start

Connect or pair your pad with Windows first, and confirm Windows itself recognises it (the USB cable is the simplest test — if a pad works wired, any remaining problem is pairing, not Snes9x). Then launch Snes9x. This ordering matters on Windows for a reason explained below: the Windows port does not hot-plug controllers the way some other platforms do, so a pad connected after the emulator is already running may simply not appear until you reconfigure it.

Step 2 — Map the buttons in Input Configuration

Open Input → Input Configuration. You will see the SNES controller’s buttons listed as fields. Click a field — D-Pad directions, A, B, X, Y, L, R, Start and Select — then press the button or direction on your pad that you want to assign. Work down the list until every field is filled, then confirm. There is no single “correct” layout; the natural mapping is to match positions: the pad’s right-hand diamond to SNES A/B/X/Y, shoulders to L/R. Keyboard keys can be mixed into the same mapping, which is handy for player two. Repeat the process for each player port you intend to use, keeping in mind that netplay and multitap games can involve up to five players (see the netplay guide).

XInput, DirectInput and HID — what Snes9x sees

Windows pads speak one of a few dialects. XInput is the Xbox-style standard: current Xbox controllers use it, and Windows presents them consistently, so mapping is painless. DirectInput is the older standard used by many retro-style and generic pads; Snes9x accepts these too. Many multi-mode pads — 8BitDo models are the classic example — can start up in different modes and appear to Windows as different device types depending on the mode, so if your pad’s name or button numbering looks odd in the configuration dialog, switching its startup mode and remapping usually resolves it. Underneath, Bluetooth gamepads reach Windows as standard HID game controllers, which is why pairing happens in Windows Settings, not inside Snes9x: once paired and connected, the pad appears in Input Configuration like any other.

The Windows hotplug truth

Here is the quirk, stated plainly because many guides get it wrong. The Windows version of Snes9x does not support hot-plugging controllers mid-session. Hotplugging was actually disabled on Windows back in version 1.56, in favour of a menu option to reconfigure joysticks; the hotplug support people sometimes cite belongs to the Linux (GTK) build, which gained it in 1.61. In practice this means: plug your controller in before launching Snes9x, and if you connect one later, use the Input menu to reconfigure joysticks so the emulator picks it up. It also means a pad that falls asleep or loses Bluetooth mid-game may need that same reconfigure step when it reconnects. Our controller not detected fixes go deeper if a pad never appears at all.

Bluetooth specifics

Pair the controller in Windows Bluetooth settings with Snes9x closed, wait for Windows to report it as connected, then launch the emulator and map as above. If you share one pad between a PC and a phone or console, remember it can only hold one active connection — a pad that “won’t connect” to the PC is often still connected to the other device. For Android play, Snes9x EX+ (the separate app by Robert Broglia, covered on our Snes9x for Android page) supports standard HID gamepads as well, and the mapping idea is the same even though the app is a different program from Windows Snes9x.

Quick checks when a pad misbehaves

• Pad connected in Windows before Snes9x launched? If not, reconfigure joysticks from the Input menu
• Multi-mode pad in a different startup mode than you mapped? Remap after switching modes
• Bluetooth pad asleep or paired to another device? Wake it, disconnect it elsewhere, re-pair
• Player-two pad mapped to the wrong port? Check each player’s configuration separately

Two players, port order and spare pads

Player one and player two have separate configuration pages, and the port a pad is mapped to is the port it plays on — a second pad mapped over the first player’s fields will fight for the same character rather than joining as player two, which is the single most common two-player mistake. Map each pad on its own player’s page, then test in a game with a two-player mode before your guests arrive. If you keep a spare pad for a second player, leave it connected (or reconnect and reconfigure it from the Input menu before starting, per the hotplug behaviour described above) so Windows keeps a stable idea of which device is which. Players three to five only enter the picture with multitap games and netplay, where each participant’s mapping lives on their own machine entirely.

Once your pad is mapped, learn the keyboard side too — the hotkeys reference covers save states, screenshots and the rewind key, and the setup hub links every companion guide.

Start with the output method — it decides everything else

The Windows build of Snes9x 1.63 registers exactly four output methods: DirectDraw, Direct3D, OpenGL and Vulkan. This single choice controls which shader formats you can use, how the image is scaled, and how the emulator talks to your graphics hardware, so pick it first and leave the other menus alone until it is set. You will find the choice in the video/display settings, and you can switch freely — changing output method does not touch your saves, states or controller mapping.

For most readers the short answer is: use OpenGL or Vulkan. Both are modern paths, both support the current shader formats (Cg, GLSL and slang — see the shaders and filters guide), and both scale the SNES’s low-resolution output cleanly to a modern monitor. OpenGL is the long-established default-style choice and the safest pick if anything looks wrong. Vulkan, added in version 1.62 (not 1.63, despite what some sites claim), is the newer alternative and is equally valid — try it if OpenGL gives you trouble, or if you want to use slang shaders through the Vulkan path.

When Direct3D and DirectDraw make sense

Direct3D is the older DirectX path. Its main reason to exist today is Cg shader support: Cg shaders work in both Direct3D and OpenGL, so if you have a favourite old Cg preset, Direct3D remains a legitimate home for it. DirectDraw is the legacy option, kept for compatibility with very old hardware and drivers. On any machine built in the last decade it offers no advantage — it is the output method with the fewest modern features, and we only mention it so you know you can safely ignore it. If a guide tells you DirectDraw is the “fastest” option for a modern PC, it is repeating advice from another era.

Frame skip: what it does and when to touch it

Frame skipping exists for machines that cannot emulate every frame in real time: the emulator drops the rendering of some frames so gameplay keeps the correct speed. On hardware that meets the readme’s modest recommendation — which is to say, essentially every Windows 10 or 11 PC still in use — the correct setting is to leave frame skipping off or on its automatic behaviour and let every frame render. Deliberately skipping frames on a capable machine only makes motion look choppier. Treat frame skip as a troubleshooting tool for genuinely weak hardware, not a performance upgrade, and be suspicious of any settings guide that promises specific frame-rate gains from it: Snes9x’s publishers state no such figures, and neither do we.

Sync and timing options

The sync-related options govern how the emulator paces itself against your display and sound card. Left at their defaults, Snes9x targets the game’s own original timing, which is what you want: a game that runs noticeably too fast or too slow is almost never a “best settings” problem but a sync or configuration fault — our troubleshooting coverage works through that case specifically. Change one sync option at a time, test with the same game, and change it back if it does not help; stacking random timing tweaks is how settings files become a mess nobody can untangle later.

Picture quality beyond the output method

With OpenGL or Vulkan selected, picture quality is mostly about what you layer on top. Shader presets can reproduce a CRT look, smooth pixel edges, or leave the image untouched — the formats and trade-offs are covered in depth in the shaders and filters guide. Window size, fullscreen behaviour and aspect-ratio handling live in the same display area and are covered separately in the fullscreen and display settings guide. Our honest recommendation for a first session: OpenGL or Vulkan, no shader, correct aspect ratio, and play for an evening before changing anything. Most “bad picture” complaints turn out to be a stretched aspect ratio, not a missing filter.

A sane baseline to start from

• Output method: OpenGL first choice, Vulkan a close second (both support modern shaders)
• Direct3D: only if you specifically want Cg shaders through the DirectX path
• DirectDraw: legacy compatibility only — skip it on modern hardware
• Frame skip: off/automatic on any current PC; a rescue tool for weak hardware, not a boost
• Sync/timing: leave at defaults unless a game demonstrably runs at the wrong speed
• Shaders and scaling: add one change at a time, after a baseline session

How to test a change properly

Emulator settings interact, so change them like you would debug anything: one variable at a time, with the same game and the same scene as your test. Note what the default was before you touch it — a screenshot of the dialog is the quickest record — then play for a few minutes, not a few seconds, because timing and sync problems often appear in motion rather than on a title screen. If a change neither helps nor hurts, revert it: a settings file full of shrug-worthy tweaks becomes impossible to reason about the first time something genuinely breaks. The baseline below is deliberately boring, and that is the point — boring settings are the ones you never have to think about again.

Finally, remember that settings never affect your save data. Battery saves and save states live in the Saves folder regardless of display choices — the save states and .srm guide explains where they are and how to back them up, and the setup hub collects every other tutorial in this series.

What you need

Very little. The official Windows readme that ships with Snes9x 1.63 lists the requirements as “Windows XP and up. DirectX 9” and recommends a semi-modern machine (800 MHz CPU for good results, 1 GHz for a near-perfect experience). If your PC runs Windows 11 or Windows 10, it exceeds those requirements many times over. Snes9x is freeware for personal, non-commercial use — it is not open source, despite what many download sites claim, and its source code is publicly available under that non-commercial licence.

You also need game ROMs. Snes9x ships with none, and this site does not provide any: the legal route is to dump cartridges you own. No BIOS file is required for normal SNES games — Snes9x emulates the enhancement chips in code, so there is no firmware step in this setup.

Step 1 — Download Snes9x 1.63 from the official source

The only current official download channel for Snes9x is the GitHub releases page of the snes9xgit/snes9x project. The project’s historic homepage, snes9x.com, has not been updated in years and hosts no current builds at all. For a 64-bit Windows PC, the file you want is snes9x-1.63-win32-x64.zip (5,328,695 bytes). Our download page links straight to that official file and publishes the SHA-256 checksum we verified against it, so you can confirm your copy is untouched.

Step 2 — Extract it somewhere writable

There is nothing to install. Right-click the ZIP and extract it, then run snes9x-x64.exe from the extracted folder. One detail matters: Snes9x writes its settings, battery saves (.srm) and save states into a Saves folder next to the executable, so put the folder somewhere your user account can write to — for example C:\Games\Snes9x or a folder on your desktop. Avoid C:\Program Files: Windows write protection there is the most common reason saves “disappear”. We cover that failure mode in detail in our guide to Snes9x saves not working.

Step 3 — Load a game

Use File → Load Game and pick your ROM. Snes9x opens .smc, .sfc, .swc, .fig and other copier formats, and it can read a ROM directly from a .zip, .gz or .jma archive as long as the archive contains a single ROM. If a game refuses to load, work through our ROM won’t load checklist before assuming the file is broken.

Step 4 — Configure your controller

Open Input → Input Configuration and click each SNES button field, then press the pad or keyboard key you want for it. Xbox controllers and other XInput pads, PlayStation pads and 8BitDo-style retro pads all work; Snes9x also accepts DirectInput devices. One Windows quirk worth knowing: unlike the Linux (GTK) build, the Windows port does not hot-plug controllers mid-game — plug the pad in before you launch, or use the Input menu to reconfigure joysticks after connecting one. Our dedicated Snes9x controller setup guide covers Bluetooth pairing and per-player mapping.

Step 5 — Know your save options

Snes9x gives you two systems. Battery saves (.srm) are the game’s own save feature, written when you save in-game and loaded automatically next time. Save states snapshot the whole machine at any moment: press Shift+F1–F10 to save and F1–F10 to load, across 10 banks — up to 100 states per game, stored as files .000 to .099 in the same Saves folder. Both systems are explained in our save states and .srm guide, and the full key list is in the Snes9x hotkeys reference.

Next steps

From here, the setup hub collects everything else: the best Snes9x settings for picture quality and performance, cheat codes, shaders and filters, netplay, and syncing your saves between PC and Android.