Fixing ROM patch errors

The patch carries a checksum of the ROM it was built from, and yours does not match. This is not a warning you can click past: the ROM field turns red, the Apply patch button greys out, and if the button is still live from an earlier step, pressing it returns an invalid input ROM checksum error and produces no file. The patch will not apply until the base ROM is right. Work through these in order:

1. 1

   Check for a copier header

   If the patcher offers a "remove header" checkbox, your ROM is headered. Toggle it and try again. This alone fixes most SNES and NES failures.

2. 2

   Confirm the region and revision

   USA, Europe and Japan releases are different files, and so are revision 1.0 and 1.1. Read the hack’s readme for the exact base it expects.

3. 3

   Check the ROM is not already patched

   Applying a patch on top of its own result does not give you the hack twice, and for most formats it produces a broken file. RUP is the exception: it recognises its own output and reverses the patch, handing back the original ROM. Either way, start from a clean dump.

4. 4

   Verify the ROM against a database

   Use the checksum tool and compare to No-Intro or the author’s published hash to confirm your dump is good.

The patcher reads the first bytes of a file to identify the format. This error means those bytes matched nothing it knows.

• The download was incomplete or corrupted. Re-download and compare file sizes.
• The file is actually an archive with an unusual extension. Try renaming it to .zip.
• You selected the ROM in the patch field by mistake.
• The file is a .rar or .7z archive. The patcher handles zip only; extract these first.

This is specific to xdelta patches. VCDIFF allows an optional extra compression layer, and the browser engine does not implement those decompressors. Your ROM is fine; the patch simply uses a feature that is not supported here.

• Ask the author for a patch built with xdelta3 -e -S none.
• Or apply this one with the xdelta3 command line tool on a desktop.

This is the signature of a format with no validation: IPS, PPF, xdelta and BSDiff apply to whatever you give them. If the base ROM was wrong, you get a corrupt result and no error, because there is no checksum in the patch for the tool to check against. It is worth knowing which side of that line you are on: with BPS, UPS, APS, RUP and Star Rod, a wrong base ROM is refused outright, so if one of those applied cleanly the base ROM was not the problem and you should look at byte order, the header option, or the hack itself.

Verify your base ROM’s checksum against the author’s stated value, then patch again from a clean copy.

Patching loads the whole file into memory. A 700 MB disc image needs well over a gigabyte of headroom once the output is built alongside it. Close other tabs, or use a desktop browser rather than a phone.

If your problem is not an error message but a question about how patching works at all, the ROM patching FAQ covers the shorter ones: which formats are supported, whether anything is uploaded, whether patching is legal, and how IPS and BPS differ.