Understanding Rev 1 and Revision Numbers in Game ROMs
When you rip a cartridge or download an older game file, you will occasionally see "Rev 1" stamped somewhere in the filename or embedded in the data itself. It means the second revision of that specific release. Rev 0 is the original. Rev 1 is the first patch issued by the publisher, usually to fix a bug that slipped past QA. Decoding it is straightforward if you know where to look. Most console ROMs store revision metadata in a predictable header offset. On Nintendo cartridges, you will find it at various locations depending on the system. SNES games typically put a revision byte somewhere in the header region, while NES cartridges sometimes encode it as part of the PRG-ROM checksum sequence rather than as a standalone number. The key is that "Rev 1" does not always literally appear as text. It is often just a byte value equal to 1, sitting next to other identification fields like maker ID, ROM size, and cart type. Here is how I usually go about reading it without spinning my wheels.
I open the ROM in a hex editor and navigate to the header region. For Super NES titles, I look around offset 0x10 through 0x20. For Genesis/Mega Drive, the header starts at 0x100 in the ROM dump and the region code, version byte, and other flags sit near the beginning. Dreamcast ISO files and GBA cartridges have their own structures. Once I locate the revision byte, I cross-reference it with known databases. The No-Intro database is the gold standard for this. If a ROM is marked as Rev 1 in No-Intro, the second byte after the title or the dedicated revision field in the CSV file will match. I remember one particularly annoying case where a GBA ROM I was working with had been repacked by someone who stripped the original header information and replaced it with a custom loader. The revision byte was completely absent, so the file showed up as an unrevisioned dump even though the game itself contained debug strings pointing to a second revision patch. What I did was search the binary for known patch signatures. GBA revision patches usually modify a block of code near the start of the ROM, and the difference between Rev 0 and Rev 1 can be identified by comparing the altered routine against an official Rev 0 dump. The workaround was a straight diff against a clean No-Intro Rev 0 file I had on disk. Within about twenty minutes I confirmed the revision and labeled it correctly. There are some things people get wrong about revision numbers that matter in practice.
The first is assuming that higher revision numbers are always better. They are not. Sometimes Rev 1 introduces new bugs or changes content in ways that break a speedrun timer or alter difficulty. There are well-known cases on SNES where a revision patch changed palette data or frame timing. If you are collecting for archival purposes, you should keep both Rev 0 and Rev 1 dumps. If you are ripping for preservation, match the revision to what is documented in the source release notes or cartridge label. Some physical cartridges literally print the revision on the sticker. The second mistake is thinking that a revision number tells you anything about the quality of the dump itself. It does not. A poorly dumped Rev 1 ROM is still a bad dump. You need to verify checksums against a trusted database before you care about revision level. MD5, CRC32, and the No-Intro verification routines are the real quality check. The revision byte is secondary metadata. Another thing to keep in mind is that not every system uses revision numbers at all. Some publishers released multiple variants under different regional codes instead of bumping the revision. A European SNES cart and a Japanese SNES cart might share the same revision byte but have completely different text, ROM images, and header data. If you are building a library and trying to sort by revision, you will run into confusion unless you also track region codes and language variants separately.
Get the Full Details
For the actual tools, HxD is fine for quick header inspection on smaller files. xxd on Linux works well if you are scripting a batch decode across dozens of ROMs. There are also command-line utilities like romcenter and clrmamepro that pull revision data automatically when you run them against a properly built dat file. If you are parsing many ROMs at once, writing a small Python script that reads the header offsets for each system and pulls the revision byte is probably the fastest route. It takes maybe an hour to set up and then you can process a folder in minutes. If you want to download a dat file to verify revisions, the No-Intro project hosts them at no-intro.org. That is the primary source most archivists rely on. Some scene distributors also maintain their own dat files, but they tend to be less rigorous about revision tracking. I have seen at least one third-party dat that mislabeled a Rev 1 as Rev 0 because the creator did not update the entry after a new dump surfaced. One more practical note. When you rename ROMs from a dat tool, the output will usually include the revision number in the filename automatically if the dat file contains that information. If it does not, you are essentially guessing based on checksum comparison alone. That is why using an up-to-date dat matters more than you might think.
If your goal is simply to identify the revision of a single ROM file without doing a full batch scan, opening it in a hex editor and searching for the known header offset for that system is the quickest path. For GBA, that means scanning the first 0x200 bytes. For SNES, it means the header region at the start of the file. For NES, the iNES header is always at offset 0 and the revision is encoded as part of the mapper and battery flag bytes rather than as a standalone number. The bottom line is that Rev 1 is just revision tracking metadata, not a measure of ROM quality or completeness. Decode it carefully, verify the checksum, and do not assume the revision number alone tells the whole story.
