Home Page Forums MAME MAME Fixed software lists

Yes, if MAME lists something people want fake files for it. It's calmed down a bit since clrmame stopped making them, but it still happens.

Creating an entirely fake set makes it look like MESS/MAME supports something, when actually it doesn't because it's never been been dumped and never been verified in the emulator. This can end up having the reverse of the desired effect in that some people might think the game is already dumped (and thus not needed) and supported because it's in the exported lists, when it actually isn't. In other cases it can increase prices, because people will see the lists and think 'Hey, MESSdev want *this specific* cart, I can charge whatever I want for it'

Overall it just creates confusion.

Well, it's a pretty good guide as to what works and what doesn't. Learning from something is never a bad idea you know? It's not like I think everything done in MAME is right, and I've disagreed with, and changed policies in the past, but certain things like the handling of these cases is spot on.

I'm sure you can find examples in my recent posts of where I've said MAME standards could be better, or don't apply to MESS (when it comes to MESS needing to provide more hand-holding support for users due to more convoluted start-up sequences for example)

I don't think there an absolute "correct" way to act here.

I sure don't think the situation would be as tragic as Haze thinks it would be if those comments were explicit. After all, things like the MD undumped list I added have been public since years. That same undumped list has been, in one form or another, on No-Intro site since I started curing the dat (2004?), and there were few caring, let alone anybody creating fakes. This isn't 1999 anymore, when people maybe were proud their fakes made their way into Goodgen.

On the other hand generic "dumps we need" lists can't be rendered correctly using the NO_DUMP flag. An "undumped" list is more like a 3-in-1 list, composed of actual "undumped" list + "to be redumped" list + "I want new infos to corroborate old infos I'm almost sure about already" list.

It includes:
-undumped revisions we know for sure they exist, from trustable sources like Xacrow or Ototo (ex. World of Illusions Rev A)
-games that I strongly suggest to be redumped (ex. later Ecco Jr)
-games that we simply need redump and relative chip serial only to define correct flag and release order for the various revisions (ex. Gain Ground)

You can't render something like that with a standard do-it-all NO_DUMP flag, so those comments are a necessity.

You can argue explicit notes help exposing dumping needs to the public, but I don't think that's a crucial point yet. MESS has no MAME-like exposure yet anyway.

my opinion is that carts which need to be redumped should be marked as BAD_DUMP, but carts which are completely undumped can be documented externally from the source, e.g. on the wiki.

just my 2c

Agreed. There's already a more or less authoritative NO_DUMP list maintained by No-Intro, so we don't need to duplicate it in the source. (And I gotta agree with Haze that there are good reasons we don't NO_DUMP the heck out of MAME that also apply here).

Where there is good reason to think a dump is bad, but there is no other dump of that revision available the BAD_DUMP flag should be used, pending verification of the set.

I think completely undumped games sure have to be documented in the wiki, but seeing that they are so few after all, I'd keep them in the source too. I'm a strong supporter of the "the more exposure, the more returns" thinking, at least when the pros outnumber the cons. And the cons are almost nihil in terms of space used.

The "to be redumped" games issue is too complex to be solved with a BAD_DUMP flag. Point is, most of the requested redumps are not actual bad dumps, there's an 80%-vs-20% probability that they're really good dumps, it's only that we need to know for sure. That's even before discussing games that need a redump only to get the correct revisions order. If you put a BAD_DUMP flag, get a redump, and the redumper sees that 9 times out of 10 the redump actually matches the old one, the BAD_DUMP flag loses any meaning, and you could lose contributors.

Apart for clearly hacked things like the Ninja Gaiden proto and such, I still think a short, non-ambiguous comment is much better that a rigid BAD_DUMP flag.

That's why I said if there is good reason to believe a redump is needed, for cases like the Ecco it should be pretty obvious if some of the data is corrupt, it's only a revision of an existing set afterall.

If it does turn out to be the same the BAD_DUMP flag gets dropped, and a comment stating the the revision is buggy gets added.

What I'm saying is that, even if you extract the comments and put them all in the wiki, at least don't let it boil down to simplistic NO_DUMP and BAD_DUMP flags like in the source. Some things NEED to be verbose.

The source can be simplified, that's fine to me, but the other info-containers have to carry the full comments, reducing everything to flags leads to loss of info.

Yes, not everything can be represented with flags, although in some cases I think a few more flags would help, especially to mark known Read Protected PAL devices, MCUs with internal roms etc. Not all NO_DUMP / BAD_DUMPS are equal, even in MAME.

For more complex cases source comments are invaluable.