MAME import planning and verification / 2026-07-26

Use MAME -listroms before importing an arcade set on Android

Read the exact ROM, device, BIOS, parent, and disk expectations from the emulator build before moving an authorized set into Android storage.

9 minute import planMAME 0.288 command line; Android ports may expose only part of the report

Use MAME -listroms before importing an arcade set on Android

Run `mame shortname -listroms` from the exact MAME build you plan to use, save the output, and compare it with your own dump or authorized release before importing. Use `-listxml` when you need the wider machine relationship. The manifest predicts what the build expects; `-verifyroms` still supplies the pass-or-fail audit after files are placed on its configured rompath.

Do this in order

  1. 01

    Record the Android frontend or port, its embedded MAME version, the machine short name, and the provenance of your authorized source files.

  2. 02

    Run `mame shortname -listroms` with that exact MAME revision and save the complete output beside your rights note.

  3. 03

    Use `mame shortname -listxml` only when you need broader machine, clone, device, BIOS, or disk relationships that the shorter report does not explain.

  4. 04

    Compare names, sizes, hashes, status notes, and disk requirements without renaming archives or filling gaps from an unknown collection.

  5. 05

    Import the preserved source into the configured Android rompath, retaining parent, BIOS, and short-name CHD folders required by that build.

  6. 06

    Run a targeted `-verifyroms` audit or the port's equivalent, then keep the manifest, audit, build version, and import date together.

Decision and diagnostic table

Tool or recordQuestion it answersBoundary
-listromsWhat ROM and disk data does this machine definition describe?It does not prove files are present or licensed
-listxmlHow is the machine related to parents, clones, devices, and metadata?Large output needs the exact short name and revision
-verifyromsCan this build find matching required data on its search path?A good audit is not rights evidence

A manifest comes before a repair

The machine definition is the contract. Listing it before import gives you a stable expectation generated by the emulator itself, rather than a filename list copied from a forum or an unrelated DAT.

Save the command output with the build identity. If an update changes a requirement, the two manifests expose the definition change without implying that your preserved source suddenly became unauthorized or damaged.

Separate description from filesystem discovery

`-listroms` describes expected data. It does not prove Android granted access, that the configured rompath reaches the selected folder, or that a CHD sits under the correct machine short-name directory.

After import, the targeted audit joins the definition to the actual search path. Keep those two stages separate so a storage permission error is not misdiagnosed as a bad dump.

Use the smallest useful report

Start with one machine and `-listroms`. Move to `-listxml` only for a relationship or metadata question, and to `-verifyroms` only after the files are in place. This keeps a large library from hiding the first actionable discrepancy.

If an Android port does not expose these verbs, generate the report with the matching upstream revision or use the port's own machine-information and audit view. Do not substitute a current desktop report for an unidentified frozen Android core.

First-party sources

Related guides