lr-mame2003 driver improvement and backport
-
@grant2258 said in lr-mame2003 driver improvement and backport:
this info above points to the hydrap rom not hydrap2 well in the mame2003+ dats not sure what dats your comparing against
Sorry that was a wrong paste but was meant for illustrative purposes. Even though the no dump belongs to hydrap2 it effects hydrap too because ClrMamePro doesn't know what to do with them.
When I asked if you could create a non-merged set for hydrap2 and run it you know the answer was no it wouldn't work. It was there I figured you were just messing because you started pointing fingers at everything else. You wrote the code to remove the files which removed the errors. You can talk code all day but you know you have to add the files back after the fix at the end of the day or you'll be missing sound ROMs to work correctly. It seemed like a quick hack to make it look like things were fixed.
I am approaching from the end user building a set with the provided DAT but noticed several files were removed upon checking how it was fixed. I figured you having the bigger picture understanding as you say and would have said yep I removed the files to fix those errors and will add them later but until the code fix I hacked the DAT. That really doesn't sound very good. :) Anyway heading out for the day. Have a good evening.
My original statement kind of verifies what I was trying to say/asking in the beginning:
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.
Another 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 incomplete 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.
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, etc). I was just focusing on the first one in the set.
Here's how ClrMamePro see the errors for just this parent/clone set. Their are other sets but all errors are gone now. Notice how hyrdap "bad dump" ROMs are pulled down with the hydrap2 "no dump" ROM set.
Set: Hydra (prototype 5/14/90) Name: hydrap ROM: hydr1037.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/14/90) Name: hydrap ROM: hydr1038.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/14/90) Name: hydrap ROM: hydr1039.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1001.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1002.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1003.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1004.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1005.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1006.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1007.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1008.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1009.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1011.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1012.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1013.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1014.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1016.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1038.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. Set: Hydra (prototype 5/25/90) Name: hydrap2 ROM: hydr1039.bin Issue: Can't merge set due to equal names for different hashes Clone files will be named differently if full merge mode is used. -
@riverstorm said in lr-mame2003 driver improvement and backport:
seem
I was going on the assumption that you thought i edited this out manually. I pointed out to you in the code in the driver show the driver needs fixed. That what I was trying to do. Im not arguing about it im trying to explain why its happening. If something is listed as nodump it should be treated as not being there for a logic perspective.
I could patch it up and see if mame accept it but we are still finalizing this all up. I hope the point does come across though i thought we where discussing another set its something me and mark and arcadez will have to discuss. Well on good thing came of this we all know why the bad merge happened and why its now time to decide do a quick hack and keep bad merges or fix them.
not trying to be smart here just pointing out in the code is using nodump for that particular rom and using a rom name collision is why i loads and caused the error. it is fixable riverside but there is no point in fixing it if we keep on using the old quick way hack and just live with the errors on crlmamepro. Its no me doing the quick hack fix its the driver.
I fixed the driver issue and dumped the dat posted on github check there for whats changed if you want to see riverstorm let me know if there is any problems with the non merge set i use split sets
one thing i would like to address though riverside your views on this change to the dat removing nodumps as a quickfix to fix the dat errors . It isint a quick fix its pointing out there is an issue with the driver romloads and the rom doesnt work. The quickfix here to me is "oh say yes to all errors and thatll fix hydra" or manually edit the dat to get it working
-
@riverstorm i put it back to the way it was hydra is fixed well should be just say yes to the other errors like normal as before. I will personally test any effects on non merged sets personally as see what we should do about this long term the other drivers will just need fixed up like I done with hydra this needs done either way though to make good dats
edit:
I fixed the bad driver romloads should be no errors in the dat now the nodumps are all still included make sure the following sets work for you when testing.
hydrap2
omega
chinagat
saiyugou
tmekprotany problems let me know. This is the way the dat is staying the old way it was, consider this beta1 only changes will be games added. Unless something else pops up i think we are good to go
-
@grant2258 said in lr-mame2003 driver improvement and backport:
This is the way the dat is staying the old way it was, consider this beta1 only changes will be games added. Unless something else pops up i think we are good to go
Just to let you know I don't mind if hydra and clones work. In fact I don't even know the game. :) I was just focused on DAT correctness/completeness portion of the discussion.
I never put much thought into whether it was a manual process or automatic but seeing the commit and it was released shortly prior I figured it was automatic. Not sure that changes much.
I spent quite a bit of time working on a DAT of the original changes arcadez did and I spent a lot of time modifying the DAT and loading it over and over so you kind of get an idea of what causes ClrMamePro to balk.
I saw the hydra entries were removed and I figured that doesn't seem like a fix really. The errors it was causing only really pertain to a merge set. In split or non-merged set it will just remove the parent/clone relationship.
I did come from a programming background and I've yet to meet a programmer not dialed to detail so I figured you were pulling my leg a little on some of the questions I was asking.
I wish I had more time to focus/learn programming as I do enjoy it but at the end of the day I usually spend time with family until our youngest goes to bed. Then I work out, which I ramped up to 7 days these past few years. I round robin weight, cardiovascular, even some yoga (I used to think it was for sissies and pansies but it's great for core) as it's tougher to maintain muscle mass as we age.
My oldest is married now and could have kids anytime but my youngest well I hope to stay fairly active at least through her informative years. She's at an age where we race through department stores..."Come on Dad, let's race!" and I don't much care if I look silly watching her run and cat call while laughing as long as I am active with her. Nothing like life through the eyes of a child. So pure, innocent & enthusiastic. Then eat, maybe a little on the computer, read or whatever and sleep. We have pretty "boring" week but I actually like my home life.
RetroPie "testing" allows for the whole family to play. I prefer MAME and ScummVM, the wife likes NES and SNES and Lexi likes it all. Programming well not really a group activity but I did some pretty fun overclocking this past weekend as we spent the whole weekend at home.
Anyhow, off track, I will pull down the new DAT later today for testing. I was wondering if their would be any benefit to creating a difference a difference DAT between mame2003-plus and lr-mame2003. Not at a ROM file level but at a set level.
Basically any ROM set that has at least one ROM file in the archive that is different create a DAT entry for the whole set. I have an idea how I would go about it and I don't think it would be to difficult. It wouldn't be as eloquent as a program. The thought it would allow a folder of just changed ROMs vs a whole set which would save several GB. Thoughts on that or a waste of time?
-
@riverstorm said in lr-mame2003 driver improvement and backport:
of ju
Well sets will change a little in the driver i updated in some cases chingat for example but its no new roms it will fix on a rebuild i posted on the github page what i done. I wasnt pulling your leg at all sorry if i gave that impression. I was just trying to tell you the problem was at the driver level it shows itself before we even touched the dat with bad merges. I hope you understand what i meant now if you re read it. I myself dont have as much free time as i used too but i used to program in mame years ago so am familiar with some of its workings. The problem simplified is no dump doesnt display the crc and sha and when the filename clashed it cause the merge error instead of merging
-
Yeah I understand. I do have a habit or rereading threads hoping some crystal ball clarity and tone will come through writing that just never happens...what are they trying to explain/say! ;) I surprisingly don't text except for emergencies even though work requires 24/7 phone availability, I don't care about social media and prefer a phone call or even better yet come darken my doorstep for a beer/coffee whatever even unannounced is fine. I love technology but like "time away".
I think we are loosing some interpersonal and face-to-face communication skills in the digital age. Simply how to sit around and shoot the breeze face to face without feeling anxious. Hopefully we don't all end up agoraphobic working out of clones like Surrogates. :)
Did you have any thoughts on a difference DAT between lr-mame2003 and mame2003-plus? I have a habit of building complete Non-Merged sets, zipping them up and storing but with all the sets RetroPie supports it's a bit space consuming. It might be useful though for emulator swapping/testing but then again most of the sets are additions it seems.
-
@riverstorm said in lr-mame2003 driver improvement and backport:
Anyhow, off track, I will pull down the new DAT later today for testing. I was wondering if their would be any benefit to creating a difference a difference DAT between mame2003-plus and lr-mame2003. Not at a ROM file level but at a set level.
That is what I did and posted earlier, but is out of date now. I don't have much time to read the forums or work on emulation for another week or two but this is my process.
Please excuse me if you already know this, since it sounds like you've spent plenty of time with ClrMamePro too.
- Start with a clean, Full Non-Merged MAME 0.78 collection:
Non-Mergedin the Scanner and Rebuilder settings, plus uncheckSeparate BIOS Setsin the Scanner and Rebuilder advance settings - Open the mame2003-plus XML DAT in ClrMamePro (for now say yes to any merge errors :) )
- Again set the
ScannerandRebuildtoNon-MergedwithSeparate BIOS Setsdisabled - Run
Rebuildwith the MAME 0.78 Full Non-Merged collection as the source - Run the
Scanneron the new set that is rebuilt during the previous step - Right click on the scanner results to save a
fixdatfor all selected issues
The fixdat only has records for the individual ROMs and samples that one needs to track down in order to upgrade a MAME 0.78 set to a MAME 2003+ set.
- Start with a clean, Full Non-Merged MAME 0.78 collection:
-
@markwkidd said in lr-mame2003 driver improvement and backport:
The fixdat only has records for the individual ROMs and samples that one needs to track down in order to upgrade a MAME 0.78 set to a MAME 2003+ set.
Ok, well, shoot, your method is much easier and quicker. I created two separate sets, and then torrentzip to create a consistent hash (which I always do). Taking it further you could WinMerge the differences moved to a new folder and run it against DatUtil.
-
I did run the new DAT it works fine except the few same missing ROMs that have always been there.
You guys may know this already but I thought I would share it just in case it was helpful pertaining to DATs. When I said you can remove the SHA1 yesterday it was not explained well. I should have said "field".
Now that hydrap2 has the same hash values as hydra and hydrap you can still use the "no dump" flag on hydrap2 if it is really no dump and not bad bump. It will be fine. Basically if hydrap2 is more accurate as "no dump" it can be flagged that way and leave hydrap as "bad dump". ClrMamePro has no issue with doing it that way.
Just to use a few examples that are illustrative only. The two lines below would be consider the same to ClrMamePro. Notice the only difference is the status? hyrdap can be "baddump" and hydrap2 can be "no dump".
<rom name="hydr1037.bin" merge="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" status="baddump" offset="0"/> >rom name="hydr1037.bin" merge="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" status="no dump" offset="0"/>Sticking with the same two line these will also be considered a match and the same. Notice the SHA1 is removed but to ClrMamePro this is still 100% match and will not produce warnings on profile load.
<rom name="hydr1037.bin" merge="hydr1037.bin" size="65536" crc="b974d3d0" region="sound1" status="baddump" offset="0"/> <rom name="hydr1037.bin" merge="hydr1037.bin" size="65536" crc="b974d3d0" region="sound1" status="no dump" offset="0"/>One last example using the same two lines. Everything is identical except the size field is missing in one of the lines. The two lines below are NOT a match and will throw an warning in ClrMamePro. I used this flexibility to my advantage for locating obscure ROM files that were hard to find.
<rom name="hydr1037.bin" merge="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" status="baddump" offset="0"/> <rom name="hydr1037.bin" merge="hydr1037.bin" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" status="no dump" offset="0"/>The only requirement is the name, size, crc & sha1 match but you can remove any or all fields (except name I think it has to remain) as long as it's consistent among the parent and all clones.
Merge tags are excluded from the parent for obvious reasons.
-
@riverstorm said in lr-mame2003 driver improvement and backport:
"no dump" it can be flagged that way and leave hydrap as "bad dump". ClrMamePro has no issue with doing it that way.
Just to use a few examples that are illustrative only. The two linemame ouputs nodumps with no crc or sha its has to be changed to badump or goodump in the driver to output the sha mr river thats why i removed the no dumps in the first place then added them back on because it was thought as a quick fix . I still think they arent needed but wont do any harm so will leave then in.
-
check the changes to the datfile on github there is a history of what has changed there is a history button at the bottom. It will save you doing a lot of diffs https://github.com/arcadez/mame2003-plus-libretro/blob/master/metadata/mame2003.xml. post any issues there its easier for us to find the information all input is good :)
-
@grant2258 said in lr-mame2003 driver improvement and backport:
I still think they arent needed but wont do any harm so will leave then in.
I guess what I don't understand is why not leave them as "no dump" and just answer the warnings in ClrMamePro? That's what they are (no dump) and it's 100% accurate. The official set does have these errors in abundance. I can't even remember that last time or ever I saw a perfectly clean set. These errors are normal and ok even if they can be confusing when you first see them.
A couple of sets I see that were in lr-mame2003 but have been removed from mame2003-plus.
- Cabal (US set 2) (cabal2)
- Urashima Mahjong (urashima)
check the changes to the datfile on github there is a history of what has changed there is a history button at the bottom. It will save you doing a lot of diffs
Sounds good.
-
@markwkidd said in lr-mame2003 driver improvement and backport:
The fixdat only has records for the individual ROMs and samples that one needs to track down in order to upgrade a MAME 0.78 set to a MAME 2003+ set.
@markwkidd - I was thinking about this last night and it's incredibly accurate down to the individual ROM's. What I was proposing is slightly different.
If you take an existing lr-mame2003 set and run it through you get exactly what's missing down to the ROM. So take for example "game a" needs "rom 1", "rom 2" & "rom 3" to run. After I run the lr-mame2003 set through with the mame2003-plus DAT it builds "game a" adding "rom 1" & "rom 2" but it can't find "rom 3" because it was updated for mame2003-plus.
If you create a set with that diff DAT now I have ROMs in 2 partial sets that still need to be merged to make a working set.
What I want to do is say "game a" is missing any file then I want to create the DAT entry that includes the whole game doing this for the whole set. For example "game a" is missing "rom 3" then I would create a DAT entry "game a" with roms 1, 2 & 3.
So let's say I am running mame2003-plus and I want to run "game a" all I need to do is copy it from my new folder and it's playable but with your DAT "game a" is not playable until the two partial sets have been merged.
I am not sure I am explaining that well as it's a slight difference but makes the ROMs more usable and lr-mame2003 it still 100% accurate for the ROMs that are transferable are in the set with the newly added or changed ROM sets if copied over an existing set. Completely new sets will obviously be ok as they aren't overwriting anything but just being added to the game roms folder.
-
hiya mate is the way mame outputs the nodump there is no crc and sha1 and thats the way it should be the hydra prototypes are both missing dumps as well as chinagat (parent rom). These games borrow other sets roms to work so they are considered badumps for that set . See the latest mame does it the same way to keep the parent clone relationship. It makes extra files if your using spilt sets that are not needed. It also causes merge errors . If it makes you feel better ill make you a data with no tags in for your personal use. The only other alternative is remove the prototypes because they both missing roms or make the prototype unplayable
latest mame
https://github.com/mamedev/mame/blob/master/src/mame/drivers/atarig1.cpp
line 670 hydrap2
someone posted a issue about two set being missing on the github im sure arcadez will add them back
-
@grant2258 said in lr-mame2003 driver improvement and backport:
These games borrow other sets roms to work so they are considered badumps for that set .
It's been real and it's been interesting but not real interesting. :) If you can borrow set roms and make it (hydrap2) work then it might become an instant classic for me! ;) I'll be the first in line to test it.
In the first revision removing them was your answer. (I think I would have left them as "no dump" as long as the parent is working.)
The second revision you marked the 19 "no dump" ROMs files as "bad dump" and pulled them down from the parent. Again I would have just left them as "no dump" so they align with the original lr-mame2003 DAT and it reflects proper.
As it sits now over half your ROM files (19 to be exact) are not original. You can call it a hack or hybrid or hacked prototype or hacked hybrid prototype or whatever feels comfortable for you but it doesn't seem that important to get a, as far as know, unpopular prototype working.
No need to create a special DAT. You know that's only a flag and has no bearing on the set build unless certain options are enabled? If you can get it working why change the flags to "no dump". You understand how ClrMamePro works?
Also just because it's flagged as "no dump" (in the DAT) doesn't mean you can't keep the parent/clone relationship. Of course "no dump" doesn't have a crc or sha1 because one doesn't exist.
I guess you can give a go and we'll see what you can do.
Cheers, mate! ;)
-
I know how clrmame works im not coming at it from clrmame pro im coming at it from mame. If you mark nodump in mame the dat wont output the crcs and you loose the parent clone relationship when building the roms. Thats why your loosing the parent/child relationship which is using the roms from hydra from the prototypes(the errors on the original dat). Im my first revision yes i removed the nodumps and said the drivers needed fixed and i fixed the drivers and put the no dumps back in at your request of being a quick fix.
ps the nodump borrows there roms from hydra as bad merges its what the drivers is doing as bad way originally. Im not sure what your issue is
what really confuses me is your happy to say nothing about hydrap doing this the way it originally was
-
If you wish to see a good example of parent/clone relationship with "no dump" ROMs as part of the set check out hydra and hydrap2 in the lr-mame2003 DAT. It's a good example and implemented proper the way it should be. Known files have the correct field information and "no dumps" are marked accordingly.
Thats why your loosing the parent/child relationship which is using the roms from hydra from the prototypes(the errors on the original dat).
This is only partially true. When working in "full merge" mode. Reread the warning you still not understanding it. You don't loose the parent/clone relationship in split or non-merged with hydra and hydrap2 the warning is ONLY for full merged mode but again this is still irrelevant due to the fact they are "no dump" ROMs and no ROM file exists to add to the parent in full merge mode. The error warning is a bit cyclic but it is true and how it presents itself.
If you mark nodump in mame the dat wont output the crcs
Of course it can't output the crc because it doesn't exist. In addition you wrote the commit to not process "no dump" flagged ROMs.
I think whoever created the 0.78 DAT did it correctly. You should be able to do the same or they can help with the code to get a proper DAT output? They added in the known ROM file information (name, size, crc, hash) and added "no dump" to the unknown ROMs because the information was not known at the time of DAT creation. Hence see hydra & hydrap2 in the lr-mame2003 DAT on how that works.
I respectfully am going to bow out here as this is doing no good and if you edit that post one time it might explode!
-
https://github.com/grant2258/mame2003-libretro/commits/master/metadata/MAME 0.78 XML.dat
mark edited this file to fix it originally. There is no new files with the fix hydra fix and the parent clone is correct form split sets it the way this roms should be with what i changed.
you should take this subject up with mark if you believe the bad merges are right again it was hand edited to be fixed before as well as chinagat to be fixed
-
-
Could you also put a Samples DAT for mame2003plus on the Github so we can get an exact set ?
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.