How to interpret your ROM-checker result
Read identity and integrity as separate checks
This tool inspects GBA-style headers and known signatures. Its game-name lookup covers FireRed, LeafGreen, Emerald, Ruby and Sapphire. An unrecognized game code stays not documented; it is not automatically a damaged game. This is not a general Nintendo DS or Game Boy Color identifier.
| Result | Useful for | Does not establish |
|---|---|---|
| Internal title and game code | Recognizing the header’s claimed identity. | That the entire file is clean or unchanged. |
| Region and revision | Comparing visible header details with creator requirements. | A full-file match to the intended patch input. |
| Header checksum | Checking the small header checksum. | Integrity of all game data. |
| Size | Finding a basic difference between expected and actual files. | That equal-size files contain identical bytes. |
| CRC32 and SHA-1 | Comparing whole-file values with a known reference of the same type. | Compatibility without a relevant reference value. |
| Save and RTC signatures | Finding known strings in the file. | Actual runtime behavior or successful save migration. |
The result is a set of clues with different scopes. Read the maker’s requirement alongside them rather than turning one reassuring label into a conclusion about everything else.
Why header agreement can still fail a patch check
The catalog comparison checks one recognized game, one explicit region and one revision. A stated region mismatch blocks agreement. Missing or conflicting region or revision labels do not produce a positive result; “English” alone is not a region. The checker does not have a complete creator-hash database.
Illustrative case: matching header, different data
Two local files can report the same game and revision while one has already been modified. If their full-file values differ, the shared header description does not resolve which input the creator’s patch expects. Compare the intended reference or the patch’s required source checksum before proceeding.
Use CRC32 against CRC32 and SHA-1 against SHA-1. Renaming a file changes its label, not its game bytes. Do not manually edit a header or remove data just to make a displayed identity look right.
A UPS or BPS patch can supply an input-size and checksum requirement to the local patcher. If that check rejects your input, follow the checksum-error guide. A header match does not override a failed patch-input check.
Save type and clock results are signatures, not a play test
The checker scans for known EEPROM, SRAM and Flash strings. An EEPROM signature cannot distinguish its two listed sizes here. Multiple save signatures make the actual choice uncertain. If none are found, the result is not proof that the game never saves.
The RTC field looks for the known SIIRTC_V signature. Finding it does not test your emulator’s clock settings. Not finding it does not establish that a modified game contains no other time-handling code.
For an existing playthrough, use the game’s normal save and confirm Continue after a normal exit. Moving a save to another core or version is a different task from identifying the game header. The update page explains how to read the catalog’s save-compatibility status before making that change.
Choose the next step from the result
- For a ZIP result, extract it and select the actual game file.
- For a patch result, supply your own required base game here and use the patcher for the patch.
- For an unrecognized or invalid result, verify that you selected a supported GBA file. This checker is not the right validator for a DS, GBC or standalone project.
- For a game, region or revision mismatch, return to the creator’s exact base instructions.
- When the header fields agree, still verify the creator’s full-file reference and language before patching.
Keep a short record: project, creator requirement, game code, revision, byte size, CRC32 or SHA-1, and the exact error if patching fails. Your file remains local; you can share those observations for diagnosis without sharing the game file itself.
These explanations describe this tool’s implementation, reviewed 15 Oct 2026. They do not certify a file’s origin, every ROM format or hardware compatibility. Use the full patching guide to continue once your inputs are established.
A base label such as FireRed (USA) 1.0 means header revision 0; 1.1 means revision 1. A project version such as 2.0 is not treated as a base revision. Missing revision requirements stay unknown.