MAME Input Recordings: Deterministic Playback, Desyncs, and Reproducible Evidence

A video of an arcade run shows what appeared on one screen. It does not let an emulator replay the exact control stream, inspect where simulation diverged, or render the same run with diagnostic overlays. MAME’s input recording format, commonly stored as an INP file, records the emulated input sequence so the machine can be run again from the beginning.

The recording is much smaller than captured video and can become strong regression evidence. It is not a save state and does not contain a self-sufficient copy of the machine. Playback remains deterministic only when every relevant source of initial and evolving state agrees with the original run.

Record names the input stream, not a movie

The command-line option -record writes an input recording while MAME runs the selected system. -playback feeds a recording back to the emulated machine. -exit_after_playback is useful in automated runs because the emulator exits when the recording ends instead of waiting at an idle game screen.

mame pacman -record evidence/pacman-baseline.inp
mame pacman -playback evidence/pacman-baseline.inp -exit_after_playback

Use an explicit filename and preserve MAME’s output from both commands. Do not overwrite the only known-good recording during a new capture. An INP represents control state over emulated time; it does not store the final screen as a video file.

Playback reconstructs the machine from its environment

MAME loads the selected machine, ROM set, device configuration, and persistent state, then applies recorded inputs. If the machine begins from different NVRAM, memory-card, configuration, BIOS, or software-list content, identical button events can lead to a different result.

Some machines depend on real-time clock values, randomized behavior, analog calibration, or device timing that changed between emulator versions. A recording that played perfectly on its creation build can desynchronize later even when the visible game name is unchanged.

Preserve the exact MAME version, machine short name, BIOS selection, software identifier, ROM audit result, command line, and relevant configuration. Hash the INP and all small accompanying state files. Legal ROM access remains the operator’s responsibility; do not package copyrighted machine data merely for convenience.

NVRAM is a frequent hidden input

Arcade systems store audits, settings, high scores, calibration, region choices, or progression in NVRAM. A run recorded after the machine initialized that state may not replay against an empty directory. The reverse can also fail when old NVRAM changes the boot path.

Create a dedicated MAME data directory for reproducibility, initialize it deliberately, and archive the allowed non-ROM state needed by the test. Avoid using the everyday profile where unrelated play sessions can alter NVRAM between captures.

Document whether the baseline begins from factory state or a supplied state directory. A verifier should be able to remove all generated files, recreate that baseline, and reproduce the same terminal result.

Configuration changes alter the input graph

MAME maps host controls to emulated input fields. Remapping buttons, changing controller types, enabling different devices, or altering analog sensitivity can change how a recorded sequence reaches the machine. Machine options can also add or remove emulated hardware.

Keep a minimal configuration file with the recording and compare the effective command line during playback. Disable unrelated plugins and scripts. If a plugin intentionally contributes input, version its source and declare it part of the recording environment.

Host keyboard layout is usually less important once MAME has captured its emulated input state, but the capture itself still depends on correct mappings. Validate controls before starting a long run.

A desync is a result, not a reason to force playback

Desynchronization can appear as a character dying early, an attract sequence taking a different branch, a checksum differing, or MAME reporting that playback ended unexpectedly. Do not splice new input into the file or ignore the first divergence to obtain a preferred final screen.

Return to the earliest reproducible mismatch. Compare emulator build, machine configuration, state directories, ROM audit, and command output. Bisect MAME versions if the recording is a regression test. The first build that diverges is more useful to developers than a description that a much later build “feels wrong.”

An INP can reveal nondeterminism in an emulation driver. It can also reveal an incomplete preservation bundle. Keep those hypotheses separate until evidence identifies which state differs.

Render video from playback when humans need it

MAME can write video or image sequences with options such as -aviwrite or -mngwrite. Run those during playback to produce a viewable artifact from the preserved input stream. This avoids burdening the original capture machine with video encoding and lets the same INP be rendered with diagnostic overlays.

mame pacman \
  -playback evidence/pacman-baseline.inp \
  -aviwrite evidence/pacman-baseline.avi \
  -exit_after_playback

The video is secondary evidence. Record its MAME version and settings because rendering, artwork, shaders, cropping, and audio resampling can change without changing emulated input behavior.

Automated tests need an external oracle

Successful playback only means MAME consumed the input stream to its end. It does not prove the machine reached the intended score, screen, or memory state. A regression harness needs an oracle: a frame hash at a controlled point, an emulated-memory check exposed by test tooling, a known log event, or an approved screenshot comparison with deterministic rendering.

Avoid a single full-frame pixel hash when harmless renderer changes are expected. Select a stable machine-state signal where available, or mask declared display regions. Store expected results next to the environment manifest and require review when updating them.

Run playback without throttling only if the driver remains deterministic in that mode. A faster host should change wall-clock duration, not emulated timing, but a bug or external device integration can violate that expectation.

Preservation includes the recipe

A useful archive contains the original INP, cryptographic hash, MAME build identity, machine and software names, required command line, configuration, non-copyrighted persistent state, ROM audit summary, expected end condition, and license or provenance notes. It also records which files are intentionally omitted.

Replay the bundle on a second host before declaring it portable. Then schedule periodic verification against the pinned build and selected newer builds. Keep a failure report rather than replacing the baseline automatically.

MAME input recordings are compact because they rely on deterministic reconstruction. Their evidentiary value comes from preserving everything the file leaves out and from treating the first desync as data. With a clean state directory, pinned machine definition, audited inputs, and an external oracle, an INP becomes a reproducible experiment rather than a mysterious replay file.

Related:

Sources: