Viewing Issue Advanced Details
[ Jump to Notes ]
igs/pgm.cpp
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
03094 Core Major Always Apr 5, 2009, 13:36 Apr 5, 2009, 19:05
Tester mux View Status Public Platform SDLMAME
Assigned To Resolution Unable to reproduce OS Other
Status [?] Closed Driver
igs/pgm.cpp
Version 0.130u2 Fixed in Version Build Normal
Fixed in Git Commit Github Pull Request #
Summary 03094: ddp2: game audits fine but doesn't load: wrong rom information?
Description The ddp2 romset validates fine with SDLMAME 0.130u2 once one adds the ddp2_v102.u8 rom to the ddp2.zip set :

% sdlmame -verifyroms ddp2
ddp2    : ddp2_igs027a.bin (16384 bytes) - NOT FOUND - NO GOOD DUMP KNOWN
romset ddp2 [pgm] is best available
1 romsets found, 1 were OK.

However, trying to start the game results in these errors :

ddp2_v102.u8 NOT FOUND
ddp2_igs027a.bin NOT FOUND (NO GOOD DUMP KNOWN)
ERROR: required files are missing, the game cannot be run.
Ignoring MAME exception: ERROR: required files are missing, the game cannot be run.

Using ktrace (under FreeBSD) showed that after looking for <rompath>/ddp2/ddp2_v102.u8 as expected, and finding it in <romset>/ddp2.zip, it also tried to load <rompath>/pgm/ddp2_v102.u8, as if this same rom was incorrectly described as being part of the pgm romset.

Creating the <rompath>/pgm/ddp2_v102.u8 file fixed the issue (the game proceeds starting, even though it doesn't work).

This seems to indicate some error in the description of the roms of this game, though I haven't been able to find anything wrong both in pgm.c and in the XML output of the game list.
Steps To Reproduce Just try to load the ddp2 romset.
Additional Information
Github Commit
Flags
Regression Version
Affected Sets / Systems ddp2
Attached Files
  
Relationships
There are no relationship linked to this issue.
Notes
6
User avatar
No.04143
Tafoid
Administrator
Apr 5, 2009, 15:15
edited on: Apr 5, 2009, 15:16
 Not sure if the problem is with baseline. With the rom in question (ddp2_v102.u8) the DDP2 archive - the -verifyroms shows "Best Available" and MAME starts as expected. Without that 1 rom, -verifyroms will report:
d:\emulator\arcade\mame>mame ddp2 -verifyroms
ddp2    : ddp2_v102.u8 (2097152 bytes) - NOT FOUND
ddp2    : ddp2_igs027a.bin (16384 bytes) - NOT FOUND - NO GOOD DUMP KNOWN
romset ddp2 [pgm] is bad
1 romsets found, 0 were OK.
and when trying to run MAME:
d:\emulator\arcade\mame>mame ddp2
ddp2_v102.u8 NOT FOUND
ddp2_igs027a.bin NOT FOUND (NO GOOD DUMP KNOWN)
ERROR: required files are missing, the game cannot be run.
It all seems to work as expected on the windows side of things anyway. Make sure your romset matches with CRC32 and SHA1 of what MAME expects.
User avatar
No.04144
mux
Tester
Apr 5, 2009, 15:48
edited on: Apr 5, 2009, 16:11
 Well I thought the odds were that this problem would be with the baseline, since it didn't seem possible to me that a frontend could tamper with the rom loading code. But according to what you said, it looks this is actually possible...

As for the CRC-32 and SHA-1 checksums, I thought the -verifyroms option would check for this? Anyways, I checked by hand too :

% sha1 ddp2_v102.u8
SHA1 (ddp2_v102.u8) = 51eaec46c368f7cfc5245e64896092f52b1193e0
% cksum -o3 ddp2_v102.u8 | cut -d' ' -f1 | xargs printf "%x\n"
5a9ea040
which matches the information shown by -listroms :
% sdlmame -listroms ddp2
This is the list of the ROMs required for driver "ddp2".
Name            Size Checksum
pgm_p01s.rom  131072 CRC(e42b166e) SHA1(2a9df9ec746b14b74fae48b1a438da14973702ea)
ddp2_v102.u8 2097152 CRC(5a9ea040) SHA1(51eaec46c368f7cfc5245e64896092f52b1193e0)
ddp2_igs027a.bin   16384 NO GOOD DUMP KNOWN
v100.u23      131072 CRC(06c3dd29) SHA1(20c9479f158467fc2037dcf162b6c6be18c91d46)
pgm_t01s.rom 2097152 CRC(1a7123a0) SHA1(cc567f577bfbf45427b54d6695b11b74f2578af3)
t1300.u21    8388608 CRC(e748f0cb) SHA1(5843bee3a17c33648ce904af2b98c6a90aff7393)
a1300.u1     8388608 CRC(fc87a405) SHA1(115c21ecc56997652e527c92654076870bc9fa51)
a1301.u2     8388608 CRC(0c8520da) SHA1(390317857ae5baa94a4cc042874b00a811f06a63)
b1300.u7     8388608 CRC(ef646604) SHA1(d737ff513792962f18df88c2caa9dd71de449079)
pgm_m01s.rom 2097152 CRC(45ae7159) SHA1(d3ed3ff3464557fd0df6b069b2e431528b0ebfa8)
m1300.u5     4194304 CRC(82d4015d) SHA1(d4cdc1aec1c97cf23ff7a20ccaad822962e66ffa)
User avatar
No.04149
etabeta
Developer
Apr 5, 2009, 18:18
 I cannot confirm it either (SDLMAME on intel mac)
User avatar
No.04150
mux
Tester
Apr 5, 2009, 18:43
edited on: Apr 5, 2009, 18:46
 After many tests, I now know what has been happening... So, for those interested :

I originally created the .zip file using the default archive handling program shipped with the GNOME desktop environment. I added the new rom file from MAME 0.130u2 to my existing ddp2.zip. It so happens that this program (file-roller) chose to use p7zip seeing it was installed, and produced a .zip file that is somehow heavily confusing MAME.

This explains why adding roms to zip files this way used to work for me before (I didn't have p7zip installed before).

Creating a new zip file using the zip command by hand worked flawlessly. So this bug should be closed (it seems I cannot close it myself).

What's still weird to me is that the game definitely passed audit, so somehow the audit code could see the file while the loading code could not. If people are interested in knowing why, and want to improve the zip handling code in MAME, I will attach the zip file here.

Thanks to all !
User avatar
No.04151
mux
Tester
Apr 5, 2009, 18:45
 Actually, I'm not sure I should upload the zip file here since this is copyrighted material. Contact me privately if you want to get your hands on it, or just create one such file with p7zip, I guess it'll have the same effect...
User avatar
No.04152
Tafoid
Administrator
Apr 5, 2009, 19:04
edited on: Apr 5, 2009, 19:08
 No. I'll just close this bug out as something that cannot be reproduced. The notes will stay for others who might have an issue.

Problems with archivers do not equate to problems with MAME. I know there was mention of problems using the default zip archivers in various linux environments - when I can find the specific link - I'll add.

http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=49045&Searchpage=1&Main=5292&Words=unzip&Search=true#Post49045