lr-mame2003 driver improvement and backport

[Riverstorm]

Sorry, I am not questioning if it should be fixed. I was just questioning the removal of those 3 files from the DAT. You said the parent ROMs with the same name will work as a hack but if we removed them from the DAT how is it able to leverage using the parent ROMs when they are not in the archive?

[grant2258]

they arent removed look in the zip hydrap2 is listed from 572 this is the only set they are removed in the code would need to be changed for this to fixed in this set. Your comparing two different sets

[Riverstorm]

I am referring to the newly generated DAT where you said the errors have all been fixed this morning. Looking below they have been removed. I have both the original DAT and the new one with corrections being removed.

	<game name="hydrap2" cloneof="hydra" romof="hydra">
		<description>Hydra (prototype 5/25/90)</description>
		<year>1990</year>
		<manufacturer>Atari Games</manufacturer>
		<rom name="05c" size="65536" crc="531ebb3b" sha1="866de3e2c747bd272c5235f9717ebeaeca90735b" region="cpu1" offset="1"/>
		<rom name="05e" size="65536" crc="6d77b124" sha1="a485a783211a052ca01aa400b3c5e59a2dba6faa" region="cpu1" offset="0"/>
		<rom name="15c" size="65536" crc="2f823b49" sha1="db457b43e528a6d447802259707a00f02bf92f2e" region="cpu1" offset="20001"/>
		<rom name="15e" size="65536" crc="cfda9f58" sha1="7b2727751978f35b57f8a56d8db7d1cd9378f6af" region="cpu1" offset="20000"/>
		<rom name="20c" size="65536" crc="a501e37b" sha1="7cf9dbe19d305304543793045cf2da934ff34d1e" region="cpu1" offset="40001"/>
		<rom name="20e" size="65536" crc="f75541ca" sha1="c3f8756b25b0d9f4d2d0e51a2fcc23f5a158ff87" region="cpu1" offset="40000"/>
		<rom name="30c" size="65536" crc="89604306" sha1="ccac6eabb174903f4ee144fce53a169daa734e07" region="cpu1" offset="60001"/>
		<rom name="30e" size="65536" crc="25221b17" sha1="bb14117f256c3db6881bb91cace297d4c636e684" region="cpu1" offset="60000"/>
		<rom name="aud.1b" size="65536" crc="e1b5188a" sha1="e9f2a78df49fa085a9363ca194e2ceb5fa5409c4" region="cpu2" offset="10000"/>
		<rom name="hydr1017.bin" merge="hydr1017.bin" size="65536" crc="bd77b747" sha1="da57e305468c159ca3d2cfae807a85e643bbf053" region="gfx1" dispose="yes" offset="0"/>
		<rom name="hydr1018.bin" merge="hydr1018.bin" size="65536" crc="7c24e637" sha1="dd9fa8a59cbd692b0d8c0e452df4fa18d770c602" region="gfx1" dispose="yes" offset="10000"/>
		<rom name="hydr1019.bin" merge="hydr1019.bin" size="65536" crc="aa2fb07b" sha1="ed5aa82d5bac112f0507be3e4e2a5bad184eceeb" region="gfx1" dispose="yes" offset="20000"/>
		<rom name="hydr1020.bin" merge="hydr1020.bin" size="65536" crc="906ccd98" sha1="6c226a5058a7432a9fc6e82e0f0608a2ae1a0963" region="gfx1" dispose="yes" offset="30000"/>
		<rom name="hydr1021.bin" merge="hydr1021.bin" size="65536" crc="f88cdac2" sha1="891426db0078cda61ff6c8c4ac323cb541c260d8" region="gfx1" dispose="yes" offset="40000"/>
		<rom name="hydr1022.bin" merge="hydr1022.bin" size="65536" crc="a9c612ff" sha1="732d4b7dd6a181fe9a692858d2a72d8994e97829" region="gfx1" dispose="yes" offset="50000"/>
		<rom name="hydr1023.bin" merge="hydr1023.bin" size="65536" crc="b706aa6e" sha1="4a0b919668047c24db77b6602edd67bf62e35464" region="gfx1" dispose="yes" offset="60000"/>
		<rom name="hydr1024.bin" merge="hydr1024.bin" size="65536" crc="c49eac53" sha1="7b5634aaee20fa8b46de871c2dc3b380fb059449" region="gfx1" dispose="yes" offset="70000"/>
		<rom name="hydr1025.bin" merge="hydr1025.bin" size="65536" crc="98b5b1a1" sha1="dfee7d334c4541eb13ee96b43d4d3e1a3c8deb72" region="gfx1" dispose="yes" offset="80000"/>
		<rom name="hydr1026.bin" merge="hydr1026.bin" size="65536" crc="d68d44aa" sha1="8fc8b82f4f90515f2af93d3f2d6903a74aac0cc9" region="gfx1" dispose="yes" offset="90000"/>
		<rom name="hydr1027.bin" merge="hydr1027.bin" size="131072" crc="f9135b9b" sha1="48c0ad0d3e592d191d1385e30530bdb69a095452" region="gfx2" dispose="yes" offset="0"/>
		<rom name="079-1040.bin" merge="079-1040.bin" size="512" crc="43d6f3d4" sha1="a072099df1db8db3589130c67a86a362e03d70ff" region="proms" dispose="yes" offset="0"/>
		<rom name="079-1041.bin" merge="079-1041.bin" size="512" crc="341dc4bb" sha1="175143e29cf9e6a4cecb43b3801356085944d168" region="proms" dispose="yes" offset="200"/>
		<rom name="079-1042.bin" merge="079-1042.bin" size="512" crc="2e49b52e" sha1="f8abffbcafe2cba7d1410175bb75ec07faac3b47" region="proms" dispose="yes" offset="400"/>
		<chip type="cpu" name="68000" clock="14318180"/>
		<chip type="cpu" name="M6502" clock="1789500"/>
		<chip type="audio" name="YM2151" clock="3579000"/>
		<chip type="audio" name="MSM6295" clock="9037"/>
		<video screen="raster" orientation="horizontal" width="336" height="240" aspectx="4" aspecty="3" refresh="60.000000"/>
		<sound channels="1"/>
		<input players="1" control="stick" buttons="6" coins="3"/>
		<dipswitch name="Service Mode">
		</dipswitch>
		<driver status="good" color="good" sound="good" palettesize="1280"/>
	</game>

[grant2258]

@riverstorm

you not listening look at the code it says no dump the driver needs updated its a driver issue that all and it should they should be removed or the driver should be fixed to use wrong roms

[Riverstorm]

@grant2258 said in lr-mame2003 driver improvement and backport:

@riverstorm

you not listening look at the code it says no dump the dirver need updated it a driver issue

Yes I saw the code. You removed these 3 files from the DAT that are part of hydrap2.zip. If I build a Non-Merged set you're saying the game will still work with the 3 missing files from the game zip?

These 3 files were removed from the DAT.

<rom name="hydr1037.bin" merge="hydr1037.bin" size="65536"  region="sound1" status="baddump" offset="0"/>
<rom name="hydr1038.bin" merge="hydr1038.bin" size="65536" region="sound1" status="baddump" offset="10000"/>
<rom name="hydr1039.bin" merge="hydr1039.bin" size="65536" region="sound1" status="baddump" offset="20000"/>

[grant2258]

@riverstorm

no the game doesnt work the driver needs fixed up for to work tahts why we got bad merges

[Riverstorm]

@grant2258 said in lr-mame2003 driver improvement and backport:

@riverstorm

no the game doesnt work the driver needs fixed up for to work

So you just removed the 3 needed files from the DAT so we wouldn't see the errors when using ClrMamePro? After you fix the code you'll be adding them back in I assume?

[grant2258]

@riverstorm

no i didnt edit the file at all thats what mame spits out this driver needs fixed its not done right. This is the point in this all when we fix the driver it will fix the dat itself when we dump the xml

https://github.com/arcadez/mame2003-plus-libretro/pull/17/commits/1e825e020fdb513b1edf3d52fd9ad0d6fc71c7c8

https://github.com/arcadez/mame2003-plus-libretro/pull/17/commits/863ed97ef07b9feea0c0b9ddac232a6109aa5c2e

for all changes with the no dumps

[Riverstorm]

I think we are just dancing now for the last several posts. I am not good enough of a programmer to make any more good points. All the files were removed from the DAT that caused any type of ClrMamePro warnings. Which did nothing except get rid of the errors for the end user when using ClrMamePro by mincing the DAT. So actually nothing was fixed. Most of them are harmless and only needed one answer to fix them all in one fell swoop the "Yes to All" option when prompted on the first profile load. One click. Then you showed me code and said it's a hack and the parent ROMs make the game work, then you said the game doesn't work, then you said the files weren't removed, then finally the driver needs fixed. I am not sure why the run around but if you need me to parse any DATs for testing let me know and I'll just let you do what you do.

[grant2258]

@riverstorm said in lr-mame2003 driver improvement and backport:

I think we are just dancing now for the last several posts. I am not good enough of a programmer to make any more good points. All the files were removed from the DAT that caused any type of ClrMamePro warnings. Which did nothing except get rid of the errors for the end user when using ClrMamePro by mincing the DAT. So actually nothing was fixed. Most of them are harmless and only needed one answer to fix them all in one fell swoop the "Yes to All" option when prompted on the first profile load. One click. Then you showed me code and said it's a hack and the parent ROMs make the game work, then you said the game doesn't work, then you said the files weren't removed, then finally the driver needs fixed. I am not sure why the run around but if you need me to parse any DATs for testing let me know and I'll just let you do what you do.

I dont know how to explain this to you baddump is a different set from the nodump you where talking about that being bad trhen you jumped onto the nodumps. your implying the roms are missing on 2 sets they arent . its a bad driver romload (hydrap2) doesnt work right because its not implemented right to to be none merged properly . its easy fixed and is a romload issue. I didnt make the driver and hack it in like that and yes it does need fixed and yes the files arent there and it will be removed or patched to work right. It all part of the process of fixing things and its not the only game that is there check the changes

[grant2258]

this is all the changed from the original mame2003+ and the changed 2003+ new dat they where removed

•   <rom name="hydr1001.bin" size="65536" region="gfx3" status="nodump" offset="1"/>
  

•   <rom name="hydr1002.bin" size="65536" region="gfx3" status="nodump" offset="0"/>
  

•   <rom name="hydr1003.bin" size="65536" region="gfx3" status="nodump" offset="20001"/>
  

•   <rom name="hydr1004.bin" size="65536" region="gfx3" status="nodump" offset="20000"/>
  

•   <rom name="hydr1005.bin" size="65536" region="gfx3" status="nodump" offset="40001"/>
  

•   <rom name="hydr1006.bin" size="65536" region="gfx3" status="nodump" offset="40000"/>
  

•   <rom name="hydr1007.bin" size="65536" region="gfx3" status="nodump" offset="60001"/>
  

•   <rom name="hydr1008.bin" size="65536" region="gfx3" status="nodump" offset="60000"/>
  

•   <rom name="hydr1009.bin" size="65536" region="gfx3" status="nodump" offset="80001"/>
  

•   <rom name="hydr1010.bin" size="65536" region="gfx3" status="nodump" offset="80000"/>
  

•   <rom name="hydr1011.bin" size="65536" region="gfx3" status="nodump" offset="a0001"/>
  

•   <rom name="hydr1012.bin" size="65536" region="gfx3" status="nodump" offset="a0000"/>
  

•   <rom name="hydr1013.bin" size="65536" region="gfx3" status="nodump" offset="c0001"/>
  

•   <rom name="hydr1014.bin" size="65536" region="gfx3" status="nodump" offset="c0000"/>
  

•   <rom name="hydr1015.bin" size="65536" region="gfx3" status="nodump" offset="e0001"/>
  

•   <rom name="hydr1016.bin" size="65536" region="gfx3" status="nodump" offset="e0000"/>
  

•   <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"/>
  

i not sure what dat your comparing to to maybe that where the confusion is coming from

[Riverstorm]

I don't believe I made any mention of "no dump" except to say I know the difference. Not anywhere in my posts, that I can think of, so that feels a bit of slight of hand on your part there to imply it. You're way to intelligent to not know what I was pointing out. I don't want to keep going on and on as I feel the productive part has been long done.

The thought was to make this the best it can be so people are eager to merge. It seems a lot of people are not "keen" to join this two branches because arcadez was, well he's a good guy but things were pretty messed up, kind of, things were quickly implemented, not fully tested, not documented, etc. I have nothing to bad to say about him as a person at all and I think he's incredibly intelligent.

I follow you guys on Github and see what you and Mark are doing is pretty in depth and takes some serious know how (love the tagging which is huge when using DatUtil) but without trust from the higher ups it's never going to happen and be branched off. As a solo project I am sure it would flourish because it can do all lr- can do plus more.

The thought is even these little errors and how they are handled I think are being watched with scrutiny and I was just trying to point things that seemed wrong in how they were handled. Make it proper vs a quick fix.

I have to say I have no hard feelings and will test whatever DAT you guys need but mum's the word, Sir Grant! ;)

[grant2258]

@riverstorm said in lr-mame2003 driver improvement and backport:

@grant2258 said in lr-mame2003 driver improvement and backport:

@riverstorm

you not listening look at the code it says no dump the dirver need updated it a driver issue

Yes I saw the code. You removed these 3 files from the DAT that are part of hydrap2.zip. If I build a Non-Merged set you're saying the game will still work with the 3 missing files from the game zip?

These 3 files were removed from the DAT.

<rom name="hydr1037.bin" merge="hydr1037.bin" size="65536"  region="sound1" status="baddump" offset="0"/>
<rom name="hydr1038.bin" merge="hydr1038.bin" size="65536" region="sound1" status="baddump" offset="10000"/>
<rom name="hydr1039.bin" merge="hydr1039.bin" size="65536" region="sound1" status="baddump" offset="20000"/>

sorry your right i meant bad dump i think your using a different dat file im just saying I would personally prefer to fix this core up properly and mame2003 weather they are separate or not. Im glad you are point this out and im trying to explain but our wires are getting crossed.

this info above points to the hydrap rom not hydrap2 well in the mame2003+ dats not sure what dats your comparing against

less mame2003-plus/mame2003.xml | grep "hydr" | grep baddump
<rom name="hydraa0.bin" merge="hydraa0.bin" size="65536" crc="619d7319" sha1="3c58f18ca5c93ae049bfca91043718fff43e674c" region="cpu2" status="baddump" offset="10000"/>
<rom name="hydr1037.bin" merge="hydr1037.bin" size="65536" crc="b974d3d0" sha1="67ecb17386f4be00c03661de14deff77b8ca85d0" region="sound1" status="baddump" offset="0"/>
<rom name="hydr1038.bin" merge="hydr1038.bin" size="65536" crc="a2eda15b" sha1="358888ffdeb3d0e98f59e239de6d7e1f7e15aca2" region="sound1" status="baddump" offset="10000"/>
<rom name="hydr1039.bin" merge="hydr1039.bin" size="65536" crc="eb9eaeb7" sha1="cd8e076b07588879f1a0e6c0fb9de9889480bebb" region="sound1" status="baddump" offset="20000"/>

checked in the new dat as well does appear to be there

[Riverstorm]

@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.

[grant2258]

@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

[grant2258]

@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
tmekprot

any 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

[Riverstorm]

@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?

[grant2258]

@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

[Riverstorm]

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.

[markwkidd]

@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.

1. Start with a clean, Full Non-Merged MAME 0.78 collection: Non-Merged in the Scanner and Rebuilder settings, plus uncheck Separate BIOS Sets in the Scanner and Rebuilder advance settings
2. Open the mame2003-plus XML DAT in ClrMamePro (for now say yes to any merge errors :) )
3. Again set the Scanner and Rebuild to Non-Merged with Separate BIOS Sets disabled
4. Run Rebuild with the MAME 0.78 Full Non-Merged collection as the source
5. Run the Scanner on the new set that is rebuilt during the previous step
6. Right click on the scanner results to save a fixdat for 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.