In short
- First confirm the unpatched ROM boots — if it doesn’t, the problem isn’t the patch.
- Most common causes: headered vs unheadered mismatch, wrong base version, or a patch applied with validation disabled.
- A white screen on GBA or black screen on SNES right after the logo usually means the base ROM was wrong.
- Keep a verified clean copy so every experiment is reversible.
Step zero: isolate the problem
Before touching the patch again, answer two questions. They split the problem space in half:
-
Does the unpatched source ROM boot?
Load the exact file you patched (or a fresh copy of it) in the emulator. If it doesn’t boot either, you have a bad dump or an emulator configuration issue — the patch is innocent. Fix the source first, then re-patch.
-
Does the patched file boot anywhere else?
Try a second emulator, or a different core in RetroArch. If it boots in one emulator but not another, the patched file is probably fine and the first emulator needs different settings (or doesn’t support a feature the hack uses).
If the source boots and the patched file boots nowhere, the patched file is bad. Continue below.
Causes, in the order to check them
Headered vs unheadered ROM (cartridge systems)
Black screen after the system logo
- Problem
- The patched ROM was built from a dump whose header state doesn’t match what the emulator (or the hack) expects.
- Likely cause
- Many SNES and Genesis dumps carry a copier header (often 512 bytes) that shifts every byte. Some hacks expect it, some expect it removed, and some emulators auto-detect it while others don’t.
- How to check
- Compare your source file’s size with the expected size in the hack’s readme — a 512-byte difference is the signature of a header mismatch.
- How to fix
- Add or remove the header to match what the hack requires, then re-patch from the corrected source. Do not patch the header on or off an already-patched file.
- Prevention
- Note the header requirement in the readme before you start, and verify file size first.
Wrong base ROM version or region
White screen (GBA) / crash at boot
- Problem
- The patch applied — possibly with validation disabled — but the result isn’t a working game.
- Likely cause
- A patch built for one revision applied to another produces a file that is structurally a ROM but semantically garbage. GBA hacks famously white-screen when the base revision is wrong.
- How to check
- Verify your source checksum against the hack’s published value. If you disabled checksum validation to force the patch, this is almost certainly the cause.
- How to fix
- Get the exact base version, re-verify, and re-patch a fresh copy with validation on.
- Prevention
- Never disable checksum validation to make a patch “work”.
Patches applied in the wrong order — or twice
Crashes, glitched graphics, softlocks
- Problem
- The game boots but crashes or glitches partway in.
- Likely cause
- Some hacks ship multiple patches (translation + bugfix, for example) that must be applied in order, each to the previous output. Applying them out of order, or applying the same patch twice, corrupts the result.
- How to check
- Re-read the readme’s patching order. Check whether you patched an already-patched file.
- How to fix
- Start from a clean copy and apply each patch once, in the documented order.
- Prevention
- Keep clean, intermediate and final files in separate, clearly named folders.
Emulator settings or core choice
“ROM image crashed” / boots on one emulator but not another
- Problem
- The patched file is fine; the emulator can’t handle something the hack does.
- Likely cause
- Hacks sometimes use expanded ROM sizes, special chips, or timing tricks that accuracy-focused emulators handle and simpler ones don’t — or vice versa.
- How to check
- Test in two or three emulators/cores. Check the hack’s readme for a recommended emulator.
- How to fix
- Use the recommended emulator, or try a different core. For flashcarts, check firmware compatibility with expanded ROMs.
- Prevention
- Read the hack’s compatibility notes before choosing your emulator.
A note on trimmed DS/3DS dumps
On Nintendo DS, a trimmed dump patched against an untrimmed expectation doesn’t just fail to apply — if validation was bypassed, it can produce a file that boots to a black screen. The NDS patching guide covers trimmed vs untrimmed in detail; the rule is the same everywhere: match the dump state the hack was built for.
Recovering cleanly
If you patched your only copy and it’s broken, all is not lost — but only if you can reproduce the source. This is why the guides insist on Backup original file and on keeping a verified clean dump separate from your working folder. See how to restore an original file for the full workflow. There is no “unpatch” button: a patch can’t be reversed without the original bytes, which is exactly what the backup preserves.
Frequently asked questions
The patched ROM boots but crashes later. Is that still a patching problem?
Often yes — a wrong base ROM can produce a file that boots and then falls apart when it reaches data that differs. But it can also be an emulator accuracy issue or a genuine bug in the hack. Test in another emulator first; if it crashes in the same place everywhere, suspect the base ROM.
My GBA hack shows a white screen immediately. What’s the most likely cause?
Wrong base revision. GBA hacks are usually built against one specific revision (often v1.0), and a v1.1 base white-screens right away. Verify your base ROM’s checksum against the hack’s readme.
Can a bad patch damage my emulator or system?
No. A bad patched ROM is just data — the worst it does is crash the emulator. It can’t harm your system. The real risk is to your files: always patch copies, never originals.
The hack’s readme says it needs a headered ROM. What does that mean?
Some cartridge dumps include a small copier header (commonly 512 bytes for SNES) added by old backup hardware. “Headered” means the hack was built against a dump with that header present. If your dump lacks it (or vice versa), add or remove it before patching — never after.