Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
03265 Interface Minor Always Jun 15, 2009, 20:50 Jul 20, 2017, 03:49
Tester Heihachi_73 View Status Public Platform MAME (Official Binary)
Assigned To Resolution No change required OS Windows XP/Vista/7 32-bit
Status [?] Closed Driver
Version 0.132 Fixed in Version Build Normal
Fixed in Git Commit Github Pull Request #
Summary 03265: Games with wrong CRCs don't load at all using MAME's minimal UI
Description Any game which fails loading by CRC, also fails when attempting to run from MAME's internal menu. The 'bad' games still run from the command line as normal. Came across this initially when testing out a new aristmk4.c game by simply swapping the ROMs instead of going through downloading the source, adding it and recompiling. Game booted perfectly and went into its error mode (as with eforest), but didn't even attempt to load at all through the interface.

This is most likely related to Bug 03264, as the 'missing ROM' message comes up in the same manner, even though ROMs are physically there (file names match).
Steps To Reproduce Hack a game, run it perfectly in MAME from cmd, then watch it fail when you try to load it in MAME's menu instead, even though it's still running right behind the menu!
Additional Information Tekken 2 screenshot as proof (using pre-122u2 wave ROM which fails audit).
Github Commit
Flags
Regression Version
Affected Sets / Systems
Attached Files
png file icon t2fail.png (81,461 bytes) Jun 15, 2009, 20:50
Relationships
There are no relationship linked to this issue.
Notes
3
User avatar
No.04513
Haze
Senior Tester
Jun 15, 2009, 22:11
I'm pretty sure this is by design. It's meant to be a *simple* frontend, if anything is wrong / missing it won't work.
User avatar
No.04514
Tafoid
Administrator
Jun 15, 2009, 22:24
I agree. Nevertheless, I'll leave it for Aaron to give an official + or - on this.
User avatar
No.13994
cuavas
Administrator
Jul 20, 2017, 03:49
Yeah, I think this can be closed as being by design. There are a couple of of aspects to consider.

Firstly, on the design side, allowing the system to run with bad ROM images is liable to cause bad behaviour leading to false bug reports. Thus, running with bad ROM images is considered an "advanced" operation, requiring the user to use the command line. This makes running with bad ROMs less of a "casual" operation.

Secondly, the internal UI relies on the audit class to check the status of a ROM. There isn't a huge amount of detain provided back in the result. The internal UI code just checks whether the result is "good" or "best available" and launches the system if it is. Changing the audit class API to distinguish between "missing files", "files present but bad checksum", "files present but wrong size", etc. would complicate all uses of it.