Use MAME romident or verifyroms for the right Android ROM check
Use romident when you have a file or archive from hardware you lawfully dumped and need to learn whether its contents match hashes known to that exact MAME build. Use verifyroms when you already know the target machine short name and need to audit the complete ROM dependency graph available through rompath. Identification is not a complete-set result, and either command can only compare against the definitions in the MAME version that ran it.
Do this in order
- 01
Record how you obtained the media, the hardware or authorized source, a read-only backup checksum, and the exact MAME build that will perform the comparison.
- 02
If the machine identity is unknown, run romident against a disposable copy of the file, folder, or ZIP and save every identified, non-ROM, and unidentified result without renaming the source.
- 03
If the target short name is known, use listroms first to capture the build's expected names, sizes, and hashes, including parent, BIOS, and device relationships.
- 04
Run verifyroms for that short name with the intended rompath and retain the complete output; do not reduce a missing dependency to a single filename search.
- 05
Treat partial romident matches as leads only, and treat a good verifyroms result as technical compatibility only; neither result proves ownership, distribution permission, or a correct board provenance.
- 06
Repeat the audit after a MAME-version or rompath change, keep the previous report, and repair only from your own dump or an explicitly authorized first-party source.
Decision and diagnostic table
| Starting question | Correct MAME verb | What the result does not prove |
|---|---|---|
| What is this lawful unknown file? | romident | That a complete runnable set is present |
| Is short name X complete for this build? | verifyroms X | That another MAME version expects the same graph |
| Which files does this build expect? | listroms X | That the files are present or lawfully sourced |
| May I publish or share the result? | Rights record, not an audit verb | A hash match grants redistribution permission |
Identification and set verification answer different questions
MAME documents romident as an attempt to identify files in a path, directory, or ZIP using the hashes known to the running build. Its exit states distinguish all identified, identified plus non-ROM data, partial identification, and no identification.
verifyroms begins from supported system or device definitions and checks the ROM images reachable through rompath. It is the better completion test after you know the machine short name, but it does not replace the provenance record for the physical dump or authorized source.
A partial match is evidence, not a rename instruction
One chip may be shared across revisions, parents, clones, devices, or bootleg boards. A romident match can therefore narrow an investigation without uniquely naming the complete board or proving every required image is present.
Keep original filenames and checksums in the acquisition record. Use the target build's listroms and verifyroms output to test a candidate identity instead of renaming unknown files until a frontend accepts them.
Version and path belong in every report
MAME definitions change as dumps and devices are documented. The same folder can produce different expected-file or status output after an upgrade, so the command, MAME version, rompath, short name, and timestamp are part of the evidence.
When an Android app hides command verbs, do not claim an equivalent result from a green launch button. Use a same-version audit interface if the port documents one, or perform the read-only comparison with an official desktop MAME build and keep the platform boundary explicit.
romident, listroms, and verifyroms compare technical identities; they do not authorize acquiring, keeping, sharing, or publishing commercial ROM, BIOS, device, or disk data. Use only your own lawful dump or a rights-holder-approved source and retain its permission scope separately.