lr-mame2003 driver improvement and backport
-
@riverstorm said in lr-mame2003 driver improvement and backport:
will ren
the answer to your question is yes to all. No you dont remove the sha they are different roms the problem is they have the same name so when you do a full merge clrmame renames them. This isint a big deal because if mame doesnt find the right name it will match the crc/sha. I am showing you the xml but thats generated from the code. The bad dump isint throwing the error an error because its named the same in another set with a different crc. This baddump means there is no dump for this particular board that is different from the parent.
-
@grant2258 said in lr-mame2003 driver improvement and backport:
the answer to your question is yes to all. No you dont remove the sha they are different roms the problem is they have the same name so when you do a full merge clrmame renames them. This isint a big deal because if mame doesnt find the right name it will match the crc/sha. I am showing you the xml but thats generated from the code. The bad dump isint throwing the error an error because its named the same in another set with a different crc. This baddump means there is no dump for this particular board that is different from the parent.
Ah, sorry, there's 3 here, I missed there's a second clone. I was only comparing the parent to the first clone with the bad dump flag but matching hashes. Just to clarify you're saying "hydrap2" is a different ROM file from what's located in "hydra" and "hydrap" but it's named the same? Being a bad dump you have neither the CRC or SHA1. How is the ROM name determined on creating a merge set then? I always thought the merge tag was needed for equal names of different hashes.
<rom name="hydr1037.bin" size="65536" region="sound1" status="nodump" offset="0"/>There is nothing stopping us using 2 sets of samples just change the sample filenames and add them both.
Another option even easier is just add all the new sample ROMs to the same archive. lr-mame2003 wouldn't care if there's extra samples and it wouldn't require a name change but only adding a few extra lines to the existing DAT game sample section and both would work flawlessly. Donkey Kong for example has all unique names in both the original and the arcadez fix. Hash isn't used in samples so a merge would be fairly simple and affect nothing.
-
@riverstorm said in lr-mame2003 driver improvement and backport:
DAT gam
all that is happening is mame is processing nodumps in the xml i have fixed that there is another two roms i need to look at in detail when i have time. the new dat is in the same link. You will only have 2 bad merges now. Ill let arcadez and mark look at anything i change before it gets commited. Forgot to answer your question yes its a clone of hydra thats why the bad merge issue came about because the nodump had the same romname
https://drive.google.com/open?id=1fXvqlTYJAXKX-aP_3d_rYZxjULW1n4_m
-
ok the dat is 100% fixed for the merge errors the other problem was just the bios wasnt created so you will gave a new file called acpsx.zip. The same link for the updated file if you want to test it mr riverstorm
-
@grant2258 said in lr-mame2003 driver improvement and backport:
ok the dat is 100% fixed for the merge errors the other problem was just the bios wasnt created so you will gave a new file called acpsx.zip. The same link for the updated file if you want to test it mr riverstorm
It looks real good. The same few missing ROMs from using current MAME and rollback:
Hyper Street Fighter II: The Anniversary Edition (Asia 040202) [folder: hsf2a - size: 45mb] missing rom: hs2ax.03 [size: 524288] [CRC32: 5f3d7397] [SHA1: 96f327dd998105ad5dc46bc9d3b741805a840d68] missing rom: hs2ax.04 [size: 524288] [CRC32: 59acf108] [SHA1: e68fe233681175b29a35badab249c2b892b23af3] The King of Fighters 2003 (Decrypted C) [system: Neo-Geo - folder: kof2003d - size: 124mb] missing rom: 271-v1d.bin [size: 16777216] [CRC32: 2964f36e] Snk Vs Capcom : Svc Chaos [system: Neo-Geo - folder: svcchaos - size: 114mb] missing rom: 269-m1d.bin [size: 131072] [CRC32: fd4f0ff9] [SHA1: e97e864aaa4789d854363512986e80c0606da996]I see you removed "hydr1037.bin" from "hydrap2" (the one in question we been talking about) and of course the error is gone now. Is the game flagged as not working in the code? I guess my question is just removing it from the DAT to get rid of the error didn't really fix the issue? Basically the DAT created a non-working ROM set due to "hydrap2" now has missing ROMs? There was several ROMs in "hydrap2" with the same issue that were removed (1037, 1038 & 1039). I was just focusing on the first one in the set.
I always thought the merge tag was used to handle "equal names but different hash conflicts" and then of course the code would look for "game file 1" or "game file 2" when hashing the ROMs at startup before running the game (clone "hydrap2" in this case) depending on if the set is built as Non-Merged or Merged/Split.
If Non-Merged look for "game file 1" and if Merged look for "game file 2". It's the same file but only named different in the parent in merged mode (to avoid conflicts) vs being separate in Non-Merged mode.
<rom name="hydr1037.bin" size="65536" region="sound1" status="nodump" offset="0"/> <rom name="hydr1038.bin" size="65536" region="sound1" status="nodump" offset="10000"/> <rom name="hydr1039.bin" size="65536" region="sound1" status="nodump" offset="20000"/>This the other thing with Hydra. The parent ROM "hydra" and clone "hydrap" have a ROM with the same name, size and hash values but the clone ROM in "hydrap" is flagged as bad dump but the parent ROM "hydra" is not. Exact same file when looking at the sample pulled from the DAT below.
<rom name="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" offset="0"/> <rom name="hydr1037.bin" merge="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" status="baddump" offset="0"/>Hydra and it's clones are an odd duck.
-
@riverstorm said in lr-mame2003 driver improvement and backport:
@grant2258 said in lr-mame2003 driver improvement and backport:
ok the dat is 100% fixed for the merge errors the other problem was just the bios wasnt created so you will gave a new file called acpsx.zip. The same link for the updated file if you want to test it mr riverstorm
It looks real good. The same few missing ROMs from using current MAME and rollback:
Hyper Street Fighter II: The Anniversary Edition (Asia 040202) [folder: hsf2a - size: 45mb] missing rom: hs2ax.03 [size: 524288] [CRC32: 5f3d7397] [SHA1: 96f327dd998105ad5dc46bc9d3b741805a840d68] missing rom: hs2ax.04 [size: 524288] [CRC32: 59acf108] [SHA1: e68fe233681175b29a35badab249c2b892b23af3] The King of Fighters 2003 (Decrypted C) [system: Neo-Geo - folder: kof2003d - size: 124mb] missing rom: 271-v1d.bin [size: 16777216] [CRC32: 2964f36e] Snk Vs Capcom : Svc Chaos [system: Neo-Geo - folder: svcchaos - size: 114mb] missing rom: 269-m1d.bin [size: 131072] [CRC32: fd4f0ff9] [SHA1: e97e864aaa4789d854363512986e80c0606da996]I see you removed "hydr1037.bin" from "hydrap2" (the one in question we been talking about) and of course the error is gone now. Is the game flagged as not working in the code? I guess my question is just removing it from the DAT to get rid of the error didn't really fix the issue? Basically the DAT created a non-working ROM set due to "hydrap2" now has missing ROMs? There was several ROMs in "hydrap2" with the same issue that were removed (1037, 1038 & 1039). I was just focusing on the first one in the set.
I always thought the merge tag was used to handle "equal names but different hash conflicts" and then of course the code would look for "game file 1" or "game file 2" when hashing the ROMs at startup before running the game (clone "hydrap2" in this case) depending on if the set is built as Non-Merged or Merged/Split.
If Non-Merged look for "game file 1" and if Merged look for "game file 2". It's the same file but only named different in the parent in merged mode (to avoid conflicts) vs being separate in Non-Merged mode.
<rom name="hydr1037.bin" size="65536" region="sound1" status="nodump" offset="0"/> <rom name="hydr1038.bin" size="65536" region="sound1" status="nodump" offset="10000"/> <rom name="hydr1039.bin" size="65536" region="sound1" status="nodump" offset="20000"/>This the other thing with Hydra. The parent ROM "hydra" and clone "hydrap" have a ROM with the same name, size and hash values but the clone ROM in "hydrap" is flagged as bad dump but the parent ROM "hydra" is not. Exact same file when looking at the sample pulled from the DAT below.
<rom name="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" offset="0"/> <rom name="hydr1037.bin" merge="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" status="baddump" offset="0"/>Hydra and it's clones are an odd duck.
If you know whats going on in the backgound it makes sense the changes are here. Just for you information a bad dump does have a crc and sha. A nodump has never been dumped . This translates to we have a bad dump use hydr1037.bin from the parent set in dat file
-
@grant2258 said in lr-mame2003 driver improvement and backport:
If you know whats going on in the backgound it makes sense the changes are here.
There's plenty happening in the background that I don't understand. I am just trying to understand what doesn't make sense to me. Yes I know a bad dump vs no dump or the hash value in DAT would be truly random. :)
Explain this to me. The two files between parent/clone are 100% identical why flag one as "bad dump" and other not? Yes you showed me the code that you patched MAME so that it doesn't process baddump files.
On the other hand ClrMamePro isn't aware of the MAME code when processing a DAT. It's just building sets according to the how the DAT is built. ClrMamePro can use the "baddump" flag when processing (depending on options selected) but once complete there's no indication of bad dump in the ROM set so why the different flags on identical files shown below?
<rom name="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" offset="0"/> <rom name="hydr1037.bin" merge="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" status="baddump" offset="0"/>The other issue I see is the original DAT has hash collisions. Look at the 3 lines below. It's the same file from 3 games (1 is the parent and 2 are the clones). If you run this through ClrMamePro it will not process correctly due to insufficient information and create no entries in the parent. That's the error ClrMamePro is warning about. The lack of hash information in the "hydrap2" ROM treats it as a different hash when actually it's no hash.
Anothe way is when doing a merge set (not split) you would need to at least use the hash collision detection option which creates a whole other challenge of subdirectories of the hash collisions. Well actually all merge files and not just hash collisions. You can test this with the original DAT if you want to see it for yourself.
Your fix was to remove the offending files from the DAT so now you have an imcomplete set that doesn't work but the warnings in ClrMamePro are fixed. The better fix seems to either fix the game and get the correct information or just entirely remove the clone because you already ripped 3 files to avoid the errors.
<rom name="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" offset="0"/> <rom name="hydr1037.bin" merge="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" status="baddump" offset="0"/> <rom name="hydr1037.bin" size="65536" region="sound1" status="nodump" offset="0"/>My questions are more about "quick" fixes don't seem correct to me vs. doing it right. It's your project and I'll support it for sure as I would love to see these changes get merged to the main. To stay static and never add another game does seem silly to me when there's some nice changes that could enhance it and you and Mark have the know how to do it.
Another game over the weekend I noticed that didn't work was Alien Storm that's part of these enhancements. Donkey Kong full sound samples. Actually there's several that look good to me and would be great additions.
-
river you need to be more specific in what your asking your not making sense your saying a game that has no dump should and a bad dump should run?
-
@grant2258 said in lr-mame2003 driver improvement and backport:
river you need to be more specific in what your asking your not making sense your saying a game that has no dump should and a bad dump should run?
I can't get more specific then what I explained above. I am talking about hydra and hydrap forget about hydrap2 (for now). One thing at a time.
-
@riverstorm said in lr-mame2003 driver improvement and backport:
@grant2258 said in lr-mame2003 driver improvement and backport:
river you need to be more specific in what your asking your not making sense your saying a game that has no dump should and a bad dump should run?
I can't get more specific then what I explained above. I am talking about hydra and hydrap forget about hydrap2 (for now). One thing at a time.
mame has logic to try use good dump when it sees bad dump and thats whats happening there you seem focused on this baddump
-
@grant2258 said in lr-mame2003 driver improvement and backport:
mame has logic to try use good dump when it sees bad dump and thats whats happening there you seem focused on this baddump
Yes exactly, why flag it as bad dump when you essentially are using the same exact file as the parent?
-
im not flagging it the driver is
-
@grant2258 said in lr-mame2003 driver improvement and backport:
im not flagging it the driver is
Ok that's good enough for me. Basically it's "extraneous" information I guess is the way I would view it.
The other issue of removing entries causing warnings in ClrMamePro. Why not remove the whole clone (hydrap2) instead of 3 file entries from the clone making it a worthless set essentially?
There's other errors that seemed to be quick fixes but I would need to rerun the original DAT to see them again.
-
@riverstorm said in lr-mame2003 driver improvement and backport:
@grant2258 said in lr-mame2003 driver improvement and backport:
im not flagging it the driver is
Ok that's good enough for me. Basically it's "extraneous" information I guess is the way I would view it.
The other issue of removing entries causing warnings in ClrMamePro. Why not remove the whole clone (hydrap2) instead of 3 file entries from the clone making it a worthless set essentially?
There's other errors that seemed to be quick fixes but I would need to rerun the original DAT to see them again.
https://github.com/arcadez/mame2003-plus-libretro/blob/master/src/drivers/atarig1.c
line 561
-
@grant2258 said in lr-mame2003 driver improvement and backport:
line 561
Sorry I don't quite understand they have the same hash values as the parent and clone hydrap but marked as bad dump.
-
@riverstorm said in lr-mame2003 driver improvement and backport:
@grant2258 said in lr-mame2003 driver improvement and backport:
line 561
Sorry I don't quite understand they have the same hash values as the parent and clone hydrap but marked as bad dump.
its a hack to get it working because they dont have the good dumps thats why it says baddump on that particluar set
-
@grant2258 said in lr-mame2003 driver improvement and backport:
its a hack to get it working because they dont have the good dumps thats why it says baddump on that particluar set
I thought a game needed to verify the ROMs in the archive before launch? So the entries in the DAT for hydra2p (1037, 1038 and 1039) are extraneous and this clone will run with them removed from the DAT & ROM?
-
no its not this is what they done is say hey we have this rom but these ones are bad just use the good sound roms from the parent by adding the parents crc sha so we can play the game with the other different rom files we have that are working. its borrowing a good rom from parent to get the sound working. Its marked as bad because its not the original dump thats all so it technically is bad for that set. I hope im explaining this ok for you
-
@grant2258 said in lr-mame2003 driver improvement and backport:
no its not this is what they done is say hey we have this rom but these ones are bad just use the good sound roms from the parent by adding the parents crc sha so we can play the game with the other different rom files we have that are working. its borrowing a good rom from parent to get the sound working. Its marked as bad because its not the original dump thats all so it technically is bad for that set. I hope im explaining this ok for you
Yeah that makes sense but I only have one issue with it. RetroPie users mainly use Non-Merged sets so if I only want to play "hydrap2" and delete "hydra" I am missing the correct files to launch because we removed them from the DAT which removed them from the ROM set.
I built a DAT for arcadez original changes. When I used the drivers liked the example you showed me for a bad dump like that I would have cloned the information just as the driver shows but you removed them from the DAT.
If I am doing it wrong then this will help me understand quite a bit here.
-
I understand where you are coming from in this and its something that can be fixed. This problem is in the driver and can be addressed if people want it fixed as you can see though the author put a no dump in it that can be changed it is the correct behavior though a nodump shouldnt work. It should have been marked as unplayable or merged in properly. That what me and mark are doing at the moment we are fixing the drivers up or marking there status as not working
GAME( 1990, hydrap2, hydra, atarig1, hydra, hydrap, ROT0, "Atari Games", "Hydra (prototype 5/25/90)" )
it is a prototype ill see what mark thinks to do with this one it might not work at all ive never tried it tbh
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.