Skip to content
RetrogamingDeep Dive Published Updated 6 min readViews unavailable

MAME ROM Regions: Mapping Preserved Chips into Emulated Hardware

Read MAME ROM region definitions as hardware memory maps, including load offsets, interleaved lanes, auditing, and missing-dump metadata.

In MAME, ROM declarations describe how preserved chip images populate regions associated with an emulated device. A region is an addressable byte area used by a machine configuration; a ROM load places a named file at an offset and can specify how its bytes are grouped, skipped, or reversed. These declarations encode board wiring and device expectations, not just a list of files to concatenate.

ROM_START(example)
    ROM_REGION(0x10000, "maincpu", 0)
    ROM_REGION(0x0800, "proms", 0)
ROM_END

The example defines two named regions but intentionally omits chip files. A real driver adds load declarations with the exact length, offset, checksum, and any lane or transformation flags established by the board evidence. For example, paired 8-bit chips on a 16-bit bus may populate alternating byte positions; a word-wide dump has different placement semantics. Incorrect offsets can still produce a ROM set that audits cleanly while the emulated machine reads the wrong bytes.

Treat auditing and emulation as separate evidence

MAME’s ROM loader reads the declarative entries, checks expected file identity where checksums are available, and maps data into memory regions. A successful audit verifies files against the driver’s recorded expectations; it does not prove that the driver accurately models the original board or that a dump is authentic. Entries marked bad-dump or no-dump communicate uncertainty or absence and should not be silently converted into claims of verified preservation.

Software lists solve a related but different problem: they describe software media and relationships for systems that load many titles. Machine ROM regions generally describe firmware, chips, or board contents required by a machine configuration. Keep those layers distinct when debugging a missing file or documenting a set.

When a game fails to boot, record the exact MAME version, machine name, selected BIOS, ROM search paths, audit output, and driver source revision. Compare the region sizes, load offsets, checksums, and interleave flags with reliable board or dump documentation before editing a driver. A hash match is strong evidence about file identity relative to a declared reference, not a substitute for provenance.

A region is storage, not automatically a CPU address map

The word region invites a common debugging mistake: assuming a region named maincpu is already the CPU’s complete visible address space. It is not. A region is a named, sized block of bytes associated with a machine configuration. A device or driver can retrieve it by tag, and an address map can expose all or part of its contents at an emulated address. The address map may include mirrors, gaps, bank switching, write handlers, or other devices at neighboring addresses. Those are separate layers.

This distinction is especially useful when a ROM audit succeeds but the machine executes garbage. First ask whether the bytes were loaded into the intended region and offsets. Then inspect how the emulated device consumes that region: a fixed mapping may point at an offset, a bank may select among several entries, or a device-specific ROM interface may translate accesses. A correct file in the wrong region can be just as fatal as a wrong file, and a correctly populated region can still be exposed through an inaccurate address map.

Region tags are identifiers, not descriptions enforced by MAME. "maincpu", "gfx", or "samples" are useful conventions, but the consumer and driver define what a tag means. Similarly, the region length is a byte allocation, not proof that every byte represents a physical ROM chip. It can include address gaps, alignment space, decoded data, or bytes that are intentionally left at a defined fill value.

Read load declarations as wiring instructions

The simplest ROM_LOAD places consecutive source bytes at consecutive destination offsets. Specialized macros express other common wiring patterns. For example, ROM_LOAD16_BYTE places each source byte on alternating byte lanes in a 16-bit region; it does not mean that the dump itself is a sequence of 16-bit words. A word-swapped load changes byte ordering within words. A 32-bit lane macro expresses another bus organization. Select a macro only after confirming the chip width, bus organization, address lines, and dump order from board evidence or a well-documented driver.

The arithmetic catches many mistakes before a build. If two 8-bit chips each contain 0x80000 bytes and fill opposite lanes of a 16-bit bus, the populated span is 0x100000 bytes even though neither source file is that large. The first lane begins at offset 0 and the other at offset 1. Increasing the offset by one is not an arbitrary alignment fix; it chooses which byte lane receives that chip. A reversed lane can produce scrambled instructions or graphics while both files still pass their CRC and SHA-1 checks.

ROM_CONTINUE and ROM_RELOAD also describe different evidence. Continue consumes the next bytes in the same file at another destination offset, which can model a chip whose address lines are wired in a non-linear way. Reload reuses bytes from the same file at another destination range, commonly documenting a mirror. Neither macro repairs a bad dump. If a declaration uses one, verify the source-file length and every destination span so that no accidental overlap or out-of-range write is hidden by a plausible boot screen.

The region declaration can specify properties such as erase or inversion behavior. Those flags affect region initialization or post-processing; they are not substitutes for documenting what the physical board did. Do not infer that a file full of 0xff bytes came from a chip simply because the unpopulated region defaults to that value. Distinguish bytes supplied by a dump, bytes transformed by the loader, and bytes left as fill.

Audit in layers and preserve the evidence

Use MAME’s own audit output before changing driver code. -verifyroms checks the machine’s required ROM data against the expectations in that MAME build. A report can identify a missing file, a bad checksum, a parent-set dependency, or an absent NO_DUMP device. It cannot independently prove that the driver’s expected checksum corresponds to an authentic physical chip. The database and the dump can share the same mistaken provenance, so document the source of a new dump separately.

When comparing a board photograph or dump log to a driver, make a small worksheet for each physical chip: silkscreen label, socket, device part number, dump filename, measured byte count, hash, destination region, load offset, stride/lane, and confidence. Record uncertainty explicitly. A label that is unreadable, a chip that was not dumped, or a set whose provenance is unknown should remain uncertainty in the preservation record rather than becoming an invented checksum or a confident driver comment.

If bytes appear shifted, compare a small known pattern at the source and resulting region offsets. For an even/odd lane pair, sample adjacent destination bytes and verify they alternate between the two files as expected. If a graphics decoder consumes a region in words or bitplanes, continue the trace past the region boundary: correct loading can coexist with a wrong decode layout. Keep the test repeatable by saving the MAME version, system short name, exact ROM set name, audit transcript, driver revision, and any local patch. When the set changes between MAME releases, rerun the audit against the matching version instead of treating a new expectation as evidence that the old dump changed.

Finally, avoid publishing copyrighted ROM contents as a debugging aid. Small offsets, file sizes, hashes, and original source citations are usually enough to explain a mapping. A responsible report lets another researcher reproduce the audit without redistributing the game data itself.

Related:

Sources:

Comments