MAME and MESS Officially Merge into One Unified Emulator

On May 27, 2015, MESS (Multi Emulator Super System) formally merged into MAME, unifying two long-parallel emulation projects that had, for over a decade, covered different hardware under the same underlying codebase but separate public identities.

The authoritative milestone is MAME 0.162. MAMEdev’s release announcement says MESS became an integral part of MAME and would be distributed that way. The previous-release archive shows 0.161 as the last release listing separate MAME and MESS binaries and change logs, while 0.162 presents the combined release.

What MESS covered that MAME originally didn’t

Where MAME’s original focus was arcade boards specifically, MESS extended the same underlying emulation framework to home computers, game consoles, and a wide range of other obscure historical electronics — by April 2015, immediately before the merger, MESS supported 994 unique systems across 2,106 total system variations.

The exact counts depend on how parent machines, clones, configurations, and software are categorized, so they should not be treated as a timeless measure of accuracy. The important distinction is scope: MESS applied MAME-style device modeling to systems whose software commonly lived on cartridges, cassettes, floppies, hard disks, optical media, or built-in ROM rather than one fixed arcade board set.

Computers also need keyboards, storage controllers, expansion cards, firmware choices, RAM configurations, and software lists. A machine driver can be valid while individual software requires media, setup, or peripherals not bundled with the emulator. The merge brought those complexities into the primary MAME user and development surface.

The unification effort that preceded it

The formal 2015 merger wasn’t the first attempt at bringing the two projects together — developer David “Haze” Haywood created an experimental build called UME (Universal Machine Emulator) between 2011 and 2014, specifically to prove out what a single program emulating both arcade hardware and home systems together would actually look like. UME served as a working prototype the eventual official merger could build directly on, rather than the unification happening as an untested, single leap.

MAME and MESS already shared substantial architecture and source lineage. UME demonstrated a combined target and exposed assumptions in frontends, ROM managers, build scripts, and user interfaces that expected “MAME equals arcade.” The final change was therefore governance, packaging, build, metadata, and identity work as much as a one-time source import.

What 0.162 changed technically

The 0.162 notes identify mame as the full build, while SUBTARGET=mess and SUBTARGET=arcade remained available for narrower builds. The release also warned that XML output changed, requiring frontend and ROM-management updates. That is a concrete compatibility cost of unifying the machine catalog: tools consuming metadata had to adapt.

The combined binary could expose systems through one device framework, command-line model, debugger, Lua and output infrastructure, media handling, and release cycle. Shared CPU, sound, bus, storage, and display devices no longer belonged conceptually to an “arcade” or “home” product line; they served whichever drivers used them.

Software lists became more visible

Arcade drivers often identify a fixed collection of ROM regions for one board revision. General-purpose computers and consoles load many software titles into one machine configuration. MAME software lists describe those releases, parts, media regions, compatibility features, and relationships separately from the machine driver.

That separation supports preservation: the machine model documents hardware, while lists catalog known software and required media layout. It does not distribute copyrighted images. Users must provide firmware and software lawfully, and a list hash match identifies bytes rather than granting rights.

What changed for users after the merger

Post-merger MAME includes the entirety of what MESS supported, plus the hundreds of additional systems added to MAME in the years since — meaning the historical distinction between “arcade emulator” and “computer/console emulator” mostly stopped mattering from a user’s perspective, with one unified program and one unified set of release notes covering both.

The old distinction can still appear in documentation, community habits, configuration, and subtarget builds. “Supported” also has levels: a listed machine may be working, imperfect, or not working, and individual devices can carry flags for sound, graphics, protection, or other limitations. One executable is not a claim that every system has equal maturity.

Why the unified scope matters for research

Hardware categories are porous. Arcade boards can derive from home computers or consoles; consoles share CPUs and sound devices with computers; calculators, terminals, synthesizers, and gambling machines reuse components found elsewhere. A corrected device model can improve many drivers, while a newly dumped firmware can illuminate a component used across categories.

Unified source also makes cross-system regression testing and documentation easier. A CPU timing fix can reveal drivers that depended on an old error. Central review helps ensure the fix models hardware rather than preserving accidental compatibility in one branch.

Why unifying the codebases mattered beyond just convenience

Arcade hardware and home systems share CPU cores, sound devices, storage, displays, buses, and input concepts. Because MESS was already derived from and closely tied to MAME, it is misleading to picture two wholly independent implementations maintained twice. The merger formalized one distributed product and project scope, reduced release and integration boundaries, and made common infrastructure visibly common.

For preservation history, MAME 0.162 marked a statement of intent: the reference project was about machines, not an arcade-only genre. The combined catalog could document any historically relevant digital system the framework and contributors were capable of modeling, subject to evidence and project policy.

Related:

Sources: