RetroArch setup on the R36S gets much easier the moment you stop treating it like one mysterious app and start seeing it as part of a small handheld stack. The phrase retroarch r36s sounds simple, but what you are really configuring is RetroArch inside ArkOS, with EmulationStation handling much of the menu experience on top.
I learned this the annoying way. The first time I tuned one of these cheap little handhelds, I changed three unrelated settings, saved the wrong file, and spent longer undoing my own “improvements” than actually playing anything. That is the real first-week owner experience, and this guide is built to help you skip it.
KEY TAKEAWAYS
- RetroArch on the R36S works best when you treat ArkOS, EmulationStation, and RetroArch as separate layers instead of one giant settings blob.
- The single biggest beginner mistake is saving the wrong kind of setting in the wrong place, because global config, core overrides, remaps, and shader presets all behave differently.
- Start + Select is the usual safe exit combo on standard R36S setups, while Select + X commonly opens the RetroArch menu for deeper changes.
- A two-card setup is usually the cleaner long-term option, because it separates the OS from ROM and save storage.
- Good RetroArch tuning on the R36S is mostly about stability, readable video settings, sensible hotkeys, and avoiding random changes you cannot reverse later.
RetroArch R36S quick start
RetroArch on the R36S is usually already installed as part of the system environment, so your job is not to build it from scratch, it is to make the existing setup usable. RetroArch itself is a frontend that runs libretro cores, while ArkOS and EmulationStation handle the broader handheld workflow around it.
R36S hardware is modest, which is why setup discipline matters more than endless tweaking. The device uses a Rockchip RK3326 chip, 1GB of RAM, and a 3.5-inch 640×480 IPS screen, so sensible settings tend to beat flashy ones.
Your first goal should be boring stability. Get clean exits, predictable hotkeys, readable scaling, and settings that actually save, then start playing before you go hunting for fancy CRT presets.
Understand the stack first
ArkOS is the operating system layer on the R36S, and EmulationStation is the menu you usually see before launching games. RetroArch sits underneath that for many classic systems, which means some behavior is controlled by the frontend and some behavior is controlled by RetroArch itself.
This distinction matters because not every setting belongs in the same place. EmulationStation can handle controller and frontend behavior, while RetroArch manages things like hotkeys, shader presets, scaling, remaps, and core-specific options.
That is why random menu diving creates chaos. If you tweak a frontend-facing behavior in the wrong RetroArch menu, or save a global file when you only meant to change one system, you can make a neat handheld feel messy very quickly.
If you want the broader device context before diving deeper, my full R36S setup walkthrough covers the early boot process, menu flow, and the safe habits that stop beginner mistakes from snowballing. It pairs well with this guide because RetroArch is only one layer of the full handheld experience.
Set your baseline before you tweak
The baseline configuration in RetroArch lives in retroarch.cfg, and that file controls system-wide behavior like menu driver, hotkeys, scaling, and other broad preferences. The important catch is that this global configuration generally needs to be saved when no game is loaded.
That single rule explains a lot of “why did nothing save?” confusion. If you are inside a running game, you are usually working in the Quick Menu world, which is where overrides, remaps, shader presets, and core-specific settings make more sense.
Here is the practical way to think about it:
- Use the main RetroArch interface for baseline settings that should affect everything.
- Use core overrides when a whole emulator core needs the same behavior.
- Use content directory overrides when one ROM folder needs a custom setup.
- Use game overrides only when one specific title needs special treatment.
- Use remap files for controls, not for video or system behavior.
This separation is the difference between a clean setup and a cursed one. I keep the global file as plain as possible, then I push experiments down into per-core or per-game layers where they can do less damage.
The annoying part is that RetroArch can look like it accepted your change even when you saved it in the wrong context. In my experience, this is where people lose an hour. You change a menu setting mid-game, back out, relaunch, and everything has quietly snapped back because a content override was active or the global config was never the file being written in the first place. That is not user error so much as RetroArch being brutally literal about scope.
Save settings where they actually belong
| What you are changing | Best save method | Where to do it | Common mistake |
|---|---|---|---|
| Overall menu behavior, hotkeys, global video defaults | Save Current Configuration | Main RetroArch menu, with no game loaded | Saving while content is active and expecting it to become global |
| One system using one core | Save Core Overrides | Quick Menu while that system is loaded | Turning a platform fix into a global change |
| One ROM folder | Save Content Directory Overrides | Quick Menu with a game from that folder loaded | Forgetting the folder-specific scope later |
| One game | Save Game Overrides | Quick Menu with that game loaded | Using this for problems that affect the whole system |
| Button layout only | Save Core Remap File or Game Remap File | Controls and remap workflow | Using overrides when a remap would be cleaner |
| Screen effect or CRT look | Save Shader Preset | Shader menu after testing in gameplay | Saving a heavy preset globally before checking readability |
A clean R36S setup gets easier when you stop asking “did it save?” and start asking “what layer did I just save to?” That one question fixes more RetroArch confusion than any magic preset pack ever will.
Hotkeys that matter every day
Hotkeys are the part you will feel every single session, so they deserve attention early. On common R36S layouts, Start + Select exits a game, and Select + X opens the RetroArch menu, although some firmware variants use different combinations such as Function + Start or Function + X.
The reason these matter is simple: safe exits protect saves and reduce corruption risk. The R36S starter workflow specifically recommends exiting through the normal combo rather than forcing a reset or hard power cycle, because some RetroArch-based emulators may not behave well if the game is not closed properly.
A sensible hotkey setup usually includes the following ideas:
- One enable button, commonly Select.
- One menu toggle combo, commonly Select + X or a long Start hold depending on layout.
- One clean exit combo, commonly Start + Select.
- Save and load state buttons you can remember without thinking.
Keep it boring. The best hotkeys are the ones you stop noticing after two days.
There is also a small handheld-specific friction point people rarely mention. Combo timing matters more than you expect on cheap Linux handhelds. I have had R36S units where the menu shortcut felt dead, but the real issue was that I was pressing the buttons too quickly after a resume, or a core had grabbed input in a slightly different way. When that happens, test the combo on two different systems before rewriting your whole hotkey layout, because sometimes the shortcut is fine and your timing is the part that drifted.
If your device still feels inconsistent at this stage, this R36S review gives useful context on what the hardware does well, where the budget compromises show up, and why software cleanup matters more than raw specs. That context helps set realistic expectations before you blame every hitch on RetroArch.
Video, aspect ratio, and shaders
Video settings are where many R36S owners go from “pretty good” to “why does everything look weird now?” RetroArch gives you control over aspect ratio, integer scaling, and shader presets, but the right move is to start conservative and only add effects once the baseline image looks correct.
For general use, aspect ratio and scaling should come before shaders. RetroArch exposes core-provided aspect ratio behavior, integer scaling, and per-system video tuning, which means you can get a clean image first and then decide whether you even want scanlines, LCD grids, or color tweaks.
Shader presets are powerful, but they are still another save layer. RetroArch treats shader presets separately, and those presets can be saved globally, by core, by content directory, or by game.
That matters on a small 640×480 screen. A shader that looks clever in a menu can make text muddy in actual play, so I test with a real game screen, not a title screen, before saving anything.
My simple order of operations is this:
- Fix aspect ratio first.
- Decide whether integer scaling looks better on that system.
- Test one light shader, not five.
- Save the preset at the smallest sensible scope.
- Back out if readability gets worse.
There is a second trap here that catches people who otherwise know what they are doing. A shader preset can appear to save correctly, then fail to behave the way you expect because an existing override is already dictating part of the display stack. I have hit this on handheld builds more than once. The preset menu looked fine, the save seemed successful, and the game still launched with a different visual result. When that happens, I stop stacking fixes and check whether a core override, game override, or old preset is already in the chain. RetroArch rarely breaks without a reason, but it absolutely hides the reason inside its own layering system.
If you want a better firmware-level foundation before visual tuning, my ArkOS guide explains the cleaner base setup, better builds, and the firmware decisions that make later RetroArch tweaks much less fragile. Firmware hygiene is not glamorous, but it saves a lot of time.
Cores, overrides, and per-system tuning
Cores are the emulators RetroArch loads, and different systems may benefit from different default choices. RetroArch also lets you save behavior at the core, directory, or single-game level, which is exactly what makes the R36S manageable when one system behaves nicely and another needs extra hand-holding.
This is where overrides become your best friend. A core override is ideal when an entire system family needs the same video or latency behavior, while a content directory or game override is better when only one folder or one title needs a fix.
Control changes should usually live in remaps instead of overrides. RetroArch separates remap files from the broader configuration system, which keeps your button fixes from accidentally dragging unrelated video or menu settings along with them.
The practical rule is simple:
- Use a core override for platform-wide behavior, such as a preferred shader or rewind choice on lighter systems.
- Use a game override when a single title needs special treatment.
- Use a remap when the controls are wrong but everything else is fine.
This is also why “best settings” articles often age badly. There is no single magic profile for every core on the R36S, because different systems, ROM folders, and game quirks need different scopes of change.
One detail worth remembering is that remaps are usually the safer fix when your complaint is purely about buttons. I have seen people solve a one-game control issue with a broad override, then wonder why video behavior or menu oddities started spreading to other content that never had a problem. If the disease is “A and B are swapped,” the cure should not be “rewrite the room.”
SD cards, ROMs, BIOS, and update hygiene
Storage is not just a hardware issue on the R36S, it is part of setup quality. The device supports a dual-card arrangement, and a separate game card is often the cleaner path because it keeps the OS apart from ROMs and reduces the pain if the system card fails.
The stock card situation is where many cheap handheld headaches begin. The R36S starter workflow strongly recommends replacing the bundled card with a quality branded microSD, because the cheap included cards are prone to failure and corruption.
ArkOS also supports switching ROM storage to a second SD card through the system options, which is why a two-card layout is so common in serious setups. Once enabled, the second card becomes your practical ROM library space, while the OS stays isolated on the first card.
RetroArch setup is also easier when your file structure is tidy. RetroArch can point to BIOS, save, save-state, screenshot, and browser directories, and clean folder decisions make future maintenance much less painful.
The R36S adds one more wrinkle here: many units do not have built-in Wi-Fi, so convenient online updating is not the default experience. Manual firmware updates or an external USB Wi-Fi dongle are common workarounds, which makes it even more sensible to keep your ROM storage and firmware layers organized.
The hidden mess is not always total failure. Sometimes the handheld boots, but it boots weird. I have seen mixed-card setups where the system appeared to read one card for boot behavior and another for game data, which creates the sort of nonsense that makes you question your own memory. Menu shortcuts vanish, ROM lists go strange, or the console hangs on a black screen with just enough life to waste your evening. That is why I like a clean card strategy more than clever recovery tricks. A fresh branded OS card and a separate branded ROM card are dull choices, but they remove whole categories of fake software problems.
For the storage side of this, a reliable branded microSD card fixes more weird crashes, missing saves, and random corruption issues than most people expect. For the library side, my ROM-loading tutorial picks up right where this RetroArch guide ends, especially if you are moving to a cleaner two-card layout.
Mistakes that break a good setup
The most common mistake is saving globally when the problem is local. RetroArch has a real hierarchy, with retroarch.cfg at the baseline and overrides, remaps, core options, and shader presets layered above it, so a wrong save choice can spread farther than you intended.
The second mistake is changing too much before testing. One new hotkey, one video change, and one save method is manageable. Twelve changes in one session is how people end up convinced the handheld has a personality disorder.
The third mistake is chasing aesthetics before function. On a small screen and modest hardware, a stable core, readable scaling, and dependable exit behavior matter more than a fancy preset you will turn off two days later.
The fourth mistake is treating every system the same. RetroArch is built around cores, overrides, and system-specific behavior, so the whole point is to let SNES, GBA, PS1, and arcade titles behave differently when they need to.
Final setup checklist
A good R36S setup feels invisible. You launch, play, save, exit cleanly, and never have to wonder which menu quietly sabotaged your afternoon.
My own checklist is short:
- Confirm your exit and menu hotkeys first.
- Save baseline config only when no game is loaded.
- Use overrides and remaps instead of spraying global changes everywhere.
- Keep shaders light and readability-first.
- Move to a reliable two-card layout when possible.
That is the real win with retroarch r36s. Once the layers make sense, the handheld stops feeling cheap and chaotic, and starts feeling like a tidy little retro machine that knows its job.
