Game developers wanted to keep selling new cabinets to arcades. Arcade owners wanted to maximize ROI and reuse assets with new/modified games, which some enterprising engineers were able to provide. Ms Pac-Man started this way: https://en.m.wikipedia.org/wiki/Ms._Pac-Man
I’ve yet to find a beat them all as good as the two D&D from capcom. I’m really surprised they didn’t keep the franchise, those games were such a huge hit when they got out..
MAME has always confused me with its mode of operation. Why is there a game list with specific required hashes built into the code? Why refuse to run an unrecognized version of a game?
Most other emulators seem to just try to emulate whatever you happen to give them.
Because arcade consoles differ a lot from direct-to-consumer consoles, where the hardware configuration is much less uniform than, say, a Game Boy Advance which has the same parts in the console and the parts in the cartridge are mostly the same from game to game.
The article itself alludes to this:
It’s easy to think of game cartridges as just being a single thing, but arcade game boards typically have a large number of chips. Why’s that? It’s partly technical; specific chips can be connected directly to particular regions of the system’s hardware, like graphics or sound, which means that even though it’s less flexible than an all-in-one ROM, it has some performance advantages too. The two chips I dumped here are program code for two different CPUs: one for the 68000 CPU in the system itself, and one for the ARM7 CPU in the game cartridge.
Fair enough, but something like the Neo Geo took cartridges internally, no? Excluding cartridges with special bits on them (and I kinda doubt there's that much unique hardware on a system that mostly had fighting games) there shouldn't be anything that specific per game on that system.
And yet MAME is just as picky with those as it is with anything else.
Another good reason is to prevent the accidental use of bad dumps. A number of the systems supported in MAME have been redumped multiple times as it was discovered that bitrot had set in on chips, or the dumper made mistakes, or any of a dozen other things happened.
This is also why your older dumps of e.g. Pac-Man for MAME 0.02 won't work on a modern MAME build-- we didn't have the color data PALs dumped, some of the early ROMs were later proven to be bad dumps, and so forth.
Locking it down to specific "best we know of as of this moment" prevents people from easily using materials we know to be incorrect, which in turn also prevents people from sending invalid bug reports.
> Locking it down to specific "best we know of as of this moment" prevents people from easily using materials we know to be incorrect
One big downside I would see is that it somewhat inhibits the creation/growth of an arcade-machine romhacking scene. (Unless there's some explicit provision in MAME for loading arbitrary patches on top of the known-good game versions.)
> which in turn also prevents people from sending invalid bug reports
Something to consider: some other emulators do this not by burning hashes into the code, but rather by downloading at runtime (tracking via RSS or the like) an independently-maintained known-good-dumps-hashes DB.
This approach enables a separation of responsibilities between "building good emulator software" vs "archiving and conserving specific games" — with one of the touted advantages usually being that that the database of good dump hashes can then be used for things other than just powering one specific emulator. It can be shared by many emulators, and other ecosystem tools; and it can even be used by anthropologists to study the "family trees" of game releases.
Also, when emulators besides MAME that use such techniques, detect that a game has a known-bad hash, they don't prevent you from playing it. They just tell you really loudly that you're about to play a bad dump (implicitly, disclaiming all liability for your doing so.) Like a modern web browser's "insecure" warning when retrieving a page over a non-HTTPS connection.
Such a large wall of text - when if you actually spent a few minutes actually using MAME you’d know it warns about bad dumps and then allows you to proceed anyway.
You’d also know that dumping the database in MAME is very straightforward. The compelling counter argument to the perceived “separation of responsibilities” - is there is one source of truth.
I don't know who you usually talk to, but my previous reply was ~200 words. Three tweets. I think you've never seen a real wall of text before. Allow me to now demonstrate :)
> when if you actually spent a few minutes actually using MAME
To be petulant for a bit: Why would I? There's no arcade game I have ever had the desire to play (didn't grow up in the right era to have nostalgia for them); and so, despite tinkering with emulators / contributing to emulator development in general, I've never had any reason to use MAME. (Read its source code to borrow architectural ideas for other emulators? Yes, quite a few times. Run it? No, never.)
The only interest I have in MAME is technological; and in that respect, I was trusting the explanation of the GP poster (whose authoritative phrasing implied them to be a contributor to the MAME project.) So when they said:
> Locking it down to specific "best we know of as of this moment" prevents people from easily using materials we know to be incorrect
— which strongly suggests not "allowing you to proceed anyway" — well, why wouldn't I believe that that's what happens?
But now, to actually rebut the spirit of this argument: how would you imagine I would learn this from MAME in only "a few minutes", without having a bad dump on hand to provide MAME with? As, presumably, you'd never see this dialog if you don't specifically trigger it by handing the emulator a bad dump as a ROM-chip asset for a game and then telling it to try running it.
Should I be downloading good dumps and then POKEing them in a hex editor to find out what happens? That doesn't sound like "a few minutes." Sounds more like something you'd only know if you're very involved indeed in MAME emulation, either deeply, on the game-archiving side; or for a long time — at least a decade or more — since back when sites archiving ROM dumps didn't care about the verified-ness of said dumps.
Going off the StackExchange thread linked in a sibling reply here, there seems to be no actual click-through in the UI version of MAME; rather, the way you are enabled to "run the game anyway" is by running the game from the command line — not something you'd be doing in your first few minutes spent tinkering around with MAME. (Thus, presumably, the GP's phrasing: "prevents people from easily using [...]".) Meaning that this is (much) less discoverable than you're implying; and, in fact, that my original suggestion — that this should be made to work more like a click-through browser security warning on the UI side, rather than being a full-stop blocker — is entirely a plausible and warranted change.
> You’d also know that dumping the database in MAME is very straightforward.
Would I? Again, sounds like something you'd only know if you're intimately involved in the MAME ecosystem.
Given that I spend my day professionally figuring out how to make production deployments out of undocumented alpha-quality software, I am able to educated-guess my way through Google, and then the MAME wiki, to finding this CLI subcommand — https://docs.mamedev.org/commandline/commandline-all.html#ma... — but that's not something I ever would have run into by just poking around.
> The compelling counter argument to the perceived “separation of responsibilities” - is there is one source of truth.
When the database is independent of the emulator, but there is only one such database that everyone agrees to use, that is also "a single source of truth." The database is effectively upstream of the emulator, like a library. The single source of truth is the canonical version at some URL pointed at by some RSS feed; the emulator's local copy is a mere cache, and one that would be invalidated by any change to the upstream database.
More importantly, though, is the practicality of the two setups.
A standalone database — or even a database living as a data file inside a release of a project — is just data, and therefore able to be extracted + transformed by anyone with the right file-encoding library to work with that data.
A database that's burned into the code of a project, where you must run the program itself with some flags to get the DB out, means that for any downstream project that wants to track the database for its own releases, this downstream project must acquire a copy of, and then run the upstream project, within its own build infrastructure. Which, for projects that would otherwise be simple CLI utilities, can massively bloat the build dependencies required of the project. (Some romset-verifier tool might just need libc to build; but for the fact that it needs to run MAME to extract its DB, and so now requires every library MAME requires to run, to build.)
---
I do think I know what you're getting at here, though — right now, the "database" is effectively extracted from known-good-hash literals that are used in the game logic to reference loading those ROM-chip assets; whereas if the DB were separate, then these hash literals in the code would become a second "source of truth."
But that's not what I was suggesting, because that's not what any other emulator does.
Rather, in other multi-asset-per-game emulators (e.g. BSNES/Higan), the code just calls an emulator-runtime function to load any available verified version of a given symbolically-named asset. The emulator grabs the asset by its symbolic name, and then hashes it, and checks that that hash is a known-good one in its DB, before loading the asset from the file and handing the asset-handle back to the code. If it's not a good dump of that asset — of which there can be multiple(!) — then the game logic gets an error back from the load function. Not that other emulators have per-game logic — MAME is pretty unique for that — but if they did, that per-game logic wouldn't embed any hashes. It'd just embed references to the symbolic names of per-game assets, and then trust the known-good-assets DB for the verification part.
And yes, this can be extended to constraining certain "releases" of games (where IIRC in MAME each release of the arcade cabinet is its own "game", usually a C++ subclass of an abstract base "game" in the code) to only allow matching on the particular releases of assets that were used by that release of the game. Namely, by having the known-good-assets DB keyed by which symbolically-named release(s) a given dump of a given asset is to be considered known-good for. Then the whole ecosystem of symbolic asset names, symbolic release-version games, and known-good / known-bad hash-sets of the products of those, evolves outside of any particular emulator. The per-game logic of an emulator like MAME would have to mirror the community's agreed-upon symbolic asset names + symbolic release-versions, but not the hash-sets themselves.
And even then, the symbolic asset names could be mostly conventional, e.g. by assigning each ROM chip asset a name based on its mapped memory base-address + optional bank number; each microcontroller firmware or TTL-logic gate-array asset a name based on what kind of chip it is plus its index position on the board given a standardized board orientation basis + raster scanning strategy; etc. You'd only have to explicitly "go find out" the names the community ended up with for the really weird stuff, like boards with stacked DIP chips; but for everything else, the MAME developers could blindly derive the same name the archival community would end up independently deriving.
(...or, y'know, MAME per-game logic could be mostly abstracted into a declarative chip-wiring digraph + memory mapping/banking/mirroring tables + etc file-format, that can be compiled back to the current procedural C++ code — leaving only things like MMIO address<->register registrations for per-game class files, happening in MAME-provided delegate modules called into by the build-time-generated per-game class file. And then these extracted-out declarative arcade-board "specification" files could also live independently of MAME, as the core of the aforementioned database, being used by both MAME and the archival community as the source of truth for naming board-revisions + symbolic assets referenced by those boards. I doubt this will ever happen, though.)
I'm not complaining about it, though? I'm arguing against this statement in isolation:
> Locking it down to specific "best we know of as of this moment" prevents people from easily using materials we know to be incorrect, which in turn also prevents people from sending invalid bug reports.
Which, whether it actually pertains in fact to MAME or not — not my concern here — would be a bad idea on its face, and one that I would want to discourage other emulator developers (who may well be reading this thread) from getting the idea is "a thing that is okay to do because MAME does it."
Work on obscure games sometimes trickles down to get the more popular stuff working or improved. Popularity of a game doesn’t much correlate to its functioning or accuracy. The starry background in Galaga was broken for years. Sometimes the mamedevs just don’t have a way of fixing a problem (encryption, missing dumps) or the performance isn’t there yet (N64, consoles since the PS2).
