5 ms·

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 discove

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.

derefr 4y ago
> 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. (Compare/contrast, the way that the http://www.accuraterip.com/ http://www.accuraterip.com/ database is used in audio CD ripping.) 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.
- vore 4y ago
  https://retrocomputing.stackexchange.com/a/15753 https://retrocomputing.stackexchange.com/a/15753 Apparently you can make MAME do it if you really want it to by the command line.
- fuckstick 4y ago
  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.
  - derefr 4y ago
    > Such a large wall of text 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#mame-commandline-listroms 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.)

derefr 4y ago

> 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. (Compare/contrast, the way that the http://www.accuraterip.com/ http://www.accuraterip.com/ database is used in audio CD ripping.) 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.

vore 4y ago
https://retrocomputing.stackexchange.com/a/15753 https://retrocomputing.stackexchange.com/a/15753 Apparently you can make MAME do it if you really want it to by the command line.
fuckstick 4y ago
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.
- derefr 4y ago
  > Such a large wall of text 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#mame-commandline-listroms 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.)