ROM Dumping and Preservation: From Cartridge to File

Before a game can be emulated at all, its contents have to exist as a file — and that file has to come from somewhere. Dumping is the process of reading the exact contents of a cartridge’s memory chips and writing them out as a binary image, byte for byte, using hardware built specifically to interface with the cartridge’s physical connector.

“Exact” is the goal, not a guarantee supplied by one successful read. A preservation workflow identifies the cartridge and board, uses a compatible electrical interface and dumping method, performs repeat acquisitions, retains logs, and compares the canonical output with trusted independent evidence.

What dumping hardware actually does

A dumping device (a dedicated cartridge reader, or a “flashcart” repurposed for reading rather than writing) connects directly to a cartridge’s edge connector and addresses its ROM chip(s) the same way the original console’s hardware would — issuing read cycles across the address bus and capturing whatever appears on the data bus, sequentially, across the chip’s entire address range:

Cartridge ROM chip: address space 0x0000–0x7FFFF (example, 512KB)

Dumper:  set address = 0x00000 → latch data byte → write to output file
         set address = 0x00001 → latch data byte → write to output file
         ...
         set address = 0x7FFFF → latch data byte → write to output file

Result: a .bin/.rom file, byte-for-byte identical to the chip's contents

For a simple, directly addressable mask ROM this is close to the logical operation, but real hardware also needs correct voltage levels, bus direction, setup and hold timing, chip-select signals, and address width. Driving a 3.3-volt device as though every pin tolerated 5 volts can damage the cartridge. A generic microcontroller sketch is not automatically a safe dumper.

Dumpers may read through the cartridge’s normal console-facing bus or connect more directly to chips on a board. The former preserves the behavior of mapper and protection logic but must know how to command it; the latter may require disassembly and board-specific pin knowledge. Prefer documented, nondestructive methods and record any physical intervention.

Mappers, bank switching, and save RAM complicate the picture

Cartridges frequently include a mapper chip — additional hardware between the console and the ROM that lets a game address far more memory than the console’s native address bus could reach directly, by switching between “banks” of ROM on request. A correct dump has to account for the mapper’s bank-switching behavior to ensure every bank actually gets read, not just whatever bank happens to be active by default at power-on. Cartridges with battery-backed save RAM (a small chip holding in-progress game data, kept alive by a coin-cell battery) add a second, separate concern: the save data is distinct from the ROM program itself, dumped and handled separately, and — for an aging cartridge — often at risk of being lost entirely once its battery finally dies.

Mapper identification cannot safely come from the label alone. Revisions and regional releases can use different boards, ROM sizes, save technologies, coprocessors, real-time clocks, or protection. Photograph labels and both PCB sides when opening is authorized and safe, then record chip markings and board revision. Do not remove an archival label or socket a soldered chip merely to make an acquisition convenient.

Save media can be SRAM, EEPROM, flash, or another nonvolatile technology, sometimes accompanied by RTC state. Dump it separately before battery replacement or repair, verify the file, and preserve which physical copy it came from. Replacing a battery without maintaining power can erase volatile-backed saves; a qualified technician should plan the procedure when unique user data matters.

Headers, metadata, and canonical output

Some emulator formats include a header not stored in the program ROM. An iNES or NES 2.0 header, for example, describes mapper, mirroring, memory, and console properties used to interpret PRG and CHR data. A copier may also have added its own historical header. These cases require distinguishing raw chip bytes, dumper output, catalog-normalized content, and emulator container.

Preserve the original acquisition unchanged, then create any normalized derivative through a documented tool and command. Hash each level separately. Renaming an extension or editing a header until a game boots is not verification; it may conceal a wrong size, missing bank, or incorrect board assumption.

Verifying a dump is actually correct

A dump can be silently wrong because of dirty contacts, marginal timing, an unsupported mapper, an incorrect size, or unstable hardware. Read the cartridge at least twice after reseating or power cycling as the platform guide requires, and compare strong hashes. Identical repeated reads show repeatability of that setup, not independent correctness; the dumper can repeat the same systematic mistake.

Preservation catalogs such as No-Intro connect hashes to release and verification evidence. A match shows the canonical bytes equal that catalog entry. A mismatch is not automatically a bad cartridge: it may be an undocumented revision, prototype, modified board, data degradation, header difference, or acquisition error. Quarantine the output, retain logs, and investigate rather than “fixing” bytes to reach an expected hash.

CRC32, MD5, and SHA-1 remain common for matching historical DATs. Record them when required, and also use a modern digest such as SHA-256 for archive fixity. A hash identifies bytes; it does not prove provenance, rights, or that the catalog’s original acquisition method was sound.

A preservation-minded acquisition sequence

Assign a local identifier and photograph cartridge, labels, serials, condition, and packaging.
Identify platform, board and likely save hardware from current dumping documentation.
Inspect and clean contacts with a material-safe method; avoid abrasive work unless conservation requires it.
Configure a supported dumper and record hardware revision, firmware, software, settings, adapters, and power arrangement.
Acquire ROM and save/RTC data separately, keeping raw logs and files read-only.
Repeat reads according to the guide and compare sizes and hashes.
Validate against a dated DAT or submit new evidence through the project’s process.
Store replicated masters, metadata, photographs, logs, and derivatives, then run scheduled fixity checks.

Test-loading is useful after integrity checks, but a title screen exercises only a fraction of banks and mapper behavior. Diagnostic tools, full-play paths, or code-level inspection may be needed for a previously unknown dump. Never write a test or save back to unique media until a verified backup exists.

Why this differs from just “downloading a ROM”

Dumping is acquisition from a specific physical object; downloading is obtaining an existing copy from another source. Copyright, private-copy exceptions, anti-circumvention rules, access policy, and distribution rights vary by jurisdiction and circumstances. Ownership of a cartridge does not automatically authorize public upload. This technical workflow is not legal advice; the legal boundaries are discussed further in BIOS files, copyright, and the law.

Why dumping quality matters more every year

Cartridge-based storage degrades — battery-backed save RAM chips eventually die, and the cartridges themselves are subject to physical wear, connector corrosion, and simple age. Every year that passes, some fraction of the remaining, never-dumped physical copies of older games become permanently inaccessible rather than merely rare. Correct, checksum-verified dumping is the only mechanism by which a game’s exact original contents survive that process at all — which is why the dumping and verification pipeline, unglamorous as it is, sits underneath essentially everything else this category covers.

Digital preservation also requires keeping more than executable bytes: manuals, box and label scans, board photographs, release context, source provenance, and repair history explain the artifact. Retain the physical cartridge under appropriate environmental conditions when possible. A dump reduces dependence on one aging object; it does not make that object or its history disposable.

Related:

Sources: