MAME can look like a menu for launching old games. That is the least interesting accurate description of it. The project is better understood as an executable record of electronic machines: code that names their processors and peripherals, maps their address buses, identifies the contents of their media, and then runs the model so that its claims can be tested.

That distinction explains several things that otherwise feel unfriendly. MAME does not ship the original programs required by the machines. A collection prepared for an old release may fail an audit after researchers find a better dump. A title can remain marked imperfect or not working rather than receive a convenient shortcut that contradicts the hardware. These are not accidental rough edges around a retro console. They follow from a preservation project whose stated goal is to document how machines work, with playability serving as a way to validate the documentation.[1]

The evidence chain runs from a photographed Galaxian board to a MAME driver, from individual ROM chips to checksummed sets, and from large disks to CHD images. The practical question is not merely “Will it launch?” It is “Can another person identify the machine, verify the media, reproduce the configuration, and understand what remains uncertain?”

The preserved object is a machine

The name once expanded to Multiple Arcade Machine Emulator, but the current scope is broader. MAME absorbed work on computers, consoles, calculators, gambling machines, and other electronic systems. Its executable contains original emulator code, not the copyrighted ROM, CD, hard-disk, or other software images that users must obtain separately.[1] That separation is architectural as well as legal: the machine description and the historical media are different evidence objects.

Inside the emulator, a machine is assembled from devices rather than treated as a video file with controls. CPU devices execute instructions. Memory interfaces expose program, data, I/O, and opcode spaces. Address maps connect ranges to ROM, RAM, banks, other devices, or handler methods. MAME's memory model records data width, address width, endianness, mirroring, masking, lane selection, and even bus-contention behavior where the emulated CPU supports it.[3] A useful driver therefore has to answer questions that an ordinary launcher can ignore: Which chip responds to this address? What clock drives it? Which write changes video state? Which input line carries a physical switch?

The Galaxian board in the cover photograph makes that abstraction tangible. It is an original Midway-manufactured system board, photographed at Computermuseum Arnhem rather than rendered from a schematic.[10] Rows of packages and copper traces are not visual texture added after the fact; they are the object being described. MAME's galaxian.cpp source gathers machine configurations, memory maps, input definitions, graphics layouts, sound behavior, and ROM declarations for a family of related boards.[4]

The command line can expose the same model without opening a game. Running mame galaxian -listxml produces structured metadata that identifies the 1979 Namco system, its galaxian.cpp source, referenced devices such as the Z80 CPU, ROM entries, display, sound, input, and driver status. mame galaxian -listdevices walks the attached device tree, while mame galaxian -listsource locates the driver file.[2] The result is useful precisely because it can be inspected by a researcher, a front end, a ROM manager, or a test script instead of remaining trapped in a decorative cabinet interface.

A ROM set is a claim about provenance

An arcade board usually stores code and data across multiple read-only memory chips. MAME calls the collected dumps for one supported system a ROM set. The filenames matter less than the sizes and hashes that identify their contents; mame galaxian -listroms prints the expected records, and -verifyroms compares available files with those expectations.[2]

That audit is not a guarantee that a dump is historically perfect. It proves that the bytes match what this MAME release expects. The project's own history of ROM sets describes why the distinction matters: early dumps sometimes omitted small chips containing palette data, preserved bad reads, mislabeled regions, or confused legitimate and bootleg boards. Later access to hardware allowed contributors to replace or reclassify those records.[5] Accuracy improved, but a set that matched yesterday's model could stop matching today's.

Parent and clone relationships add another layer. Regional revisions and licensed or bootleg variants may share most of their media, so MAME can organize them around a parent set and shared device or BIOS ROMs. A failed launch may therefore mean that one required dependency is missing, not that the emulator itself is broken. The diagnostic question is concrete: Which named image, size, CRC, or SHA-1 did the current driver request, and where did MAME search for it?[2][5]

Computers and consoles complicate the picture because a machine can accept many cartridges, disks, or tapes. MAME's software lists describe known media in XML, including identity metadata and integrity hashes. Their authoring guide makes an important preservation choice: a list item should represent the original medium, not merely one collector's arbitrary filename. It also admits a boundary—analog sources such as cassette recordings may not yield one perfectly repeatable image even when two people possess equivalent originals.[6]

This is what turns a ROM catalog from inventory into provenance. A useful record ties bytes to a machine variant, media object, dumping history, and current confidence level. The hash can tell you whether two files are identical. It cannot tell you whether the first dump captured the right chip, whether the label is historically correct, or whether an undumped protection device still changes behavior.

Disks require a different evidence container

Later systems added hard disks, CD-ROMs, DVDs, and LaserDiscs. These are too large and structurally different to treat like a handful of small ROM chips loaded wholesale into memory. MAME uses CHD—Compressed Hunks of Data—for this class of media. The documentation warns against wrapping a CHD in ZIP or 7-Zip because the format is already compressed and designed for random access.[5]

CHD also supports deltas. A delta file stores differences from a parent image, which can save substantial space across related variants, but it is not independent: the non-delta parent must remain available. That is a useful operational boundary. Deduplication lowers storage cost only by creating a dependency that the archive must preserve and test.[5]

For a museum or lab, “we have the disk” is therefore incomplete. A defensible record includes the image's hash, the CHD tool and format context, any parent relationship, the machine and software-list identifiers that consume it, and the rights or access restrictions governing use. MAME supplies important pieces of that chain; it does not silently invent the missing metadata.

Improving the record can break the collection

Most application projects treat compatibility breakage as a regression. MAME has a second obligation: compatibility with evidence. If a newly dumped palette PROM shows that old colors were approximated, retaining the approximation merely to keep an old set working would preserve the error. If an original board reveals a timing dependency, a driver may become more demanding because the model became more faithful.

This is why the exact MAME version belongs in every reproducible report. The contribution guide asks bug reporters to name the version or commit, the precise system and software, BIOS and slot configuration, reproduction steps, and—when possible—a recording from original hardware.[7] Those requirements distinguish three very different failures: wrong media, wrong configuration, and wrong emulation.

The preservation cost is not theoretical. A 2024 University of Glasgow study used MAME data to examine arcade games with technological protection measures. In its sample, the authors estimated that circumvention added an average 10.6 months to preservation, totaling 628 years across 712 affected games; they also noted that the broader catalog then contained 14,377 emulated devices.[8] Those numbers are estimates about research labor and legal-technical friction, not a performance benchmark for MAME. They show how much work can sit between possessing a board and producing a defensible model of it.

Start with an audit, not a cabinet

MAME is approachable for one curious user, but adopting it as preservation infrastructure requires more discipline than installing a front end. A small pilot can stay intentionally narrow:

1. Record an official MAME version and the host operating system before importing media.
2. Run mame -createconfig, set an explicit rompath, and keep the generated mame.ini with the project record rather than relying on an undocumented default.[2]
3. Choose one legally obtained machine and media set. Export -listxml, -listroms, -listdevices, and -listsource output so the expected model is reviewable.[2]
4. Run mame <system> -verifyroms before launch. Treat missing or invalid results as evidence problems to resolve, not warnings to suppress; use -romident separately when a dump's identity is unknown.[2]
5. Record the selected BIOS, slot devices, input mapping, display path, and any per-system INI overrides. Capture a short behavioral comparison with original hardware when access permits.[7]

This workflow fits a collector documenting a few owned boards, a developer investigating one driver, or a small institution piloting interactive access. It does not promise that every catalog entry will run well on every host. CPU cost varies with the emulated hardware and the fidelity of its devices; unusual controls, multiple displays, analog sound, mechanical outputs, and timing-sensitive peripherals can require specialized setup. Status flags and driver notes should be treated as part of the record, not filtered away to make the library appear complete.

The likely failure modes are equally specific. Media prepared for a different MAME release may fail hashes. A clone may lack its parent or BIOS. A delta CHD may be separated from its base. USB controllers may enumerate differently. A modern LCD, speakers, and generic gamepad may reproduce program logic while changing the latency, geometry, sound, and bodily interaction of the original cabinet. No amount of source accuracy can reconstruct a missing ROM or substitute for measurements from hardware that no longer exists.

MAME is a component of preservation, not the whole archive

The Council on Library and Information Resources describes emulation as a growing practice across libraries, archives, museums, and galleries because it can keep historical software interactive on modern systems. Its 2025 overview also frames emulation as a workflow problem requiring shared practice, not a single executable that settles preservation by itself.[9]

That is the right boundary for MAME. The project can preserve executable knowledge of buses, devices, media identities, and machine behavior in inspectable source. An institution still has to preserve binaries or build inputs, verified media, configuration, documentation, provenance, access policy, controllers, display assumptions, and the observations that justify claims of fidelity. Physical boards remain valuable because they can falsify the code.

MAME's most durable achievement is therefore not that one computer can impersonate thousands of old machines. It is that thousands of machine descriptions can be read, challenged, revised, and run. Long after a cabinet's monitor fails and its ROM labels fade, the record remains testable—and it remains honest enough to change when the hardware proves it wrong.

Sources

1. MAMEdev, “What is MAME?” — project purpose, machine scope, source-as-documentation model, media separation, and licensing context.
2. MAMEdev, “Universal Command-line Options” — -listxml, -listroms, -verifyroms, -listdevices, configuration creation, search paths, and the Galaxian metadata example.
3. MAMEdev, “Emulated system memory and address spaces management” — address spaces, maps, widths, endianness, banks, regions, views, and bus-contention hooks.
4. MAMEdev, src/mame/galaxian/galaxian.cpp — primary source for the Galaxian-family machine configurations, maps, inputs, graphics, sound, and ROM declarations.
5. MAMEdev, “About ROMs and Sets” — dump revision history, parent/clone dependencies, BIOS and device ROMs, and CHD/delta behavior.
6. MAMEdev, “Guidelines for Software Lists” — original-media identity, hashes, XML structure, metadata, and the analog-media reproducibility boundary.
7. MAMEdev, “Contributing to MAME” — reproducible issue evidence, exact-version reporting, original-hardware comparisons, and the project's source components.
8. Kristofer Erickson and Felix Rodriguez Perez, Technological Protection Measures and Digital Preservation: Evidence from Video Games. University of Glasgow / Knowledge Rights 21, 2024 — independent study using MAME data to estimate preservation delay and labor.
9. Eric Kaltman et al., An Overview of Emulation as a Preservation Method. Council on Library and Information Resources, 2025 — independent institutional overview of emulation workflows in libraries, archives, museums, and galleries.
10. Dennis van Zuijlekom, “Galaxian arcade system board,” Wikimedia Commons — 2014 photograph of an original Midway-manufactured board at Computermuseum Arnhem.