lr-mame2003 driver improvement and backport

mediamogul

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

if you read the first book you'll know if you want to continue to the next and learn about the "Flare".

I'll give it a look for sure. I'm excited for 'Ready Player One' as well. Everyone I know keeps saying they hope it turns out better than 'Ender's Game', but that project was plagued with issues from the beginning. RPO seems to have had a mostly trouble-free production and as you say, it appears to have shaped up well. Here's hoping it'll rock the socks.

darknior

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

It looks like @gamez-fan reverted all his work and changed his name to ghost over at Github. Kind of a shame as he had implemented some nice changes and updates. Here's the completed DAT. Not that it will do much good now.

Thanks a lot :)
You really make a good work with this DAT file, it will help :)
Do you think you will continue to update it ? ...
And why not add your link to the MAME GIT page ?

It can be for users interesting to update this page : https://github.com/arcadez/-mame2003-plus-libretro/blob/master/README.md
Add you link and explain quickly what add this MAME version from the original one.

markwkidd

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

Missing ROMs:

The only way these ROMs are going to appear is if someone digs out exactly the right version of Kawaks (whether its original or coinops xbox builds) from about 2004. I don't have much hope they'll surface at large on the internet at this point.

Riverstorm

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

Do you think you will continue to update it ? ...

I think the work @gamez-fan does is great but he doesn't really have a "procedure" and that last big NMK update I had no idea what ROMs I needed to add/update. I don't need a lot of information but the ROM name and driver minimally.

I know this a gray area but if he was testing the games as he was adding them it would have saved hours to have access to the ROMs to build out a DAT. I don't think he was testing his changes even. Building from scratch is incredibly banal. I think I spent around 40 hours total on this project as so many DAT entries were done manually without the ROM sets.

Here's what one game entry looks like:

<game name="arescue">
		<description>Air Rescue</description>
		<year>1992</year>
		<manufacturer>Sega</manufacturer>
		<rom name="epr14508.7" size="524288" crc="6702c14d" sha1="dc9324f16a3e3238f5ccdade9451d6823a50b563"/>
		<rom name="epr14509.14" size="524288" crc="daa5a356" sha1="ca87242c59de5ab5f9406635bee758a855fe20bc"/>
		<rom name="epr14513.35" size="262144" crc="f9a884cd" sha1="73010fff5e0257355e08e78838c74af86ed364ce"/>
		<rom name="epr14539.6" size="131072" crc="1a1b5532" sha1="f3651470222036703b7ecedb6e91e4cdb3d20df7"/>
		<rom name="epr14540.13" size="131072" crc="c2b4e5d0" sha1="69f8ddded5095df9012663d0ded61b78f1692a8d"/>
		<rom name="mpr14496.25" size="524288" crc="737da16c" sha1="52247d9bc2924e90d040bef484a541b1f4a9026f"/>
		<rom name="mpr14497.29" size="524288" crc="ebd7ed17" sha1="2307dc28501965432d2ff55a21698efdce014401"/>
		<rom name="mpr14498.34" size="524288" crc="d4a764bd" sha1="8434a9225ed1e01e8b1cfe169268e42cd3ce6ee3"/>
		<rom name="mpr14499.38" size="524288" crc="fadc4b2b" sha1="01c02a4dfad1ab19bac8b81b61d37fdc035bc5c5"/>
		<rom name="mpr14500.24" size="1048576" crc="0a064e9b" sha1="264761f4aacaeeac9426528caf180404cd7f6e18"/>
		<rom name="mpr14501.28" size="1048576" crc="4662bb41" sha1="80774e680468e9ba9c5dd5eeaa4791fa3b3722fd"/>
		<rom name="mpr14502.33" size="1048576" crc="988555a9" sha1="355e44319fd51358329cc7cd226e4c4725e045cb"/>
		<rom name="mpr14503.37" size="1048576" crc="90556aca" sha1="24df62af55048db66d50c7034c5460330d231bf5"/>
		<rom name="mpr14504.23" size="1048576" crc="46dd038d" sha1="9530a52e2e7388437c20ebcb19bf84c8b3b5086b"/>
		<rom name="mpr14505.27" size="1048576" crc="be142c1f" sha1="224631e00c2458c39c6a2ef7978c2b1131fb4da2"/>
		<rom name="mpr14506.32" size="1048576" crc="5dd8fb6b" sha1="7d21cacb2c9dba5db2547b6d8e89397e0424ee8e"/>
		<rom name="mpr14507.36" size="1048576" crc="db3f59ec" sha1="96dcb3827354773fc2911c62260a27e90dcbe96a"/>
		<rom name="mpr14510.22" size="524288" crc="5ea6d52d" sha1="d424082468940bb91ab424ac7812839792ed4e88"/>
		<rom name="mpr14511.26" size="524288" crc="074c53cc" sha1="9c89843bbe8058123c25b7f8f86de754ddbca2bb"/>
		<rom name="mpr14512.31" size="524288" crc="9da48051" sha1="2d41148d089a75362ed0fde577eca919213ac666"/>
	</game>

When you multiply it by 90 it starts to become a fairly large file. Plus you need to tag the BIOS, clone ROMs, merge files, samples, etc.

Many of the drivers only had the CRC listed (no size or SHA1). So I would hunt for the ROM and back fill the missing information. Basing the find purely on CRC (which can lead to incorrect files) as I believe that's how ROM management tools do it. They are capable of renaming files so matches are based off hash mainly.

The other information is not critical but for completeness and it almost removes any chance of changed, duplicate or corrupted file CRCs due to all fields need to match for each ROM file (CRC, SHA1 & size). Again with access to the working ROM none of this information is needed as it's easy to generate the data from the files themselves. With a properly named ROM it's quite easy to build the main file and then add the other information.

If you read through this thread on Github it might help explain. Some suggestions were made to try and streamline the process but not even he had access to the ROMs he was making changes for. I do appreciate his work but I think he prefers to be "spontaneous" in his project and I get that too as he's doing it in his spare time.

https://github.com/libretro/mame2003-libretro/pull/300#issuecomment-355664120

EDIT: Shortly thereafter he removed his account. I think that's what Github does. Is rename it to "ghost" when deleted? I thought he changed his name at first as all his threads now say ghost. :)

Riverstorm

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

The only way these ROMs are going to appear is if someone digs out exactly the right version of Kawaks (whether its original or coinops xbox builds) from about 2004. I don't have much hope they'll surface at large on the internet at this point.

I agree I spent a lot of time looking for those last few files. Even on archive sites. I came to the conclusion they were modified originals for Kawaks, etc. For some reason many Asian sites come up in searches but I couldn't even get a hold of the programs (patch executables) to modify the original ROMs.

SuperMagicom

@markwkidd @Riverstorm I'd like to help track some of these down but, unfortunately, there's no way for anyone to contact users here privately. lol

herb_fargus

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

I'd like to help track some of these down but, unfortunately, there's no way for anyone to contact users here privately

This being the primary reason private messages are disabled on this forum.

mediamogul

Looks like I may have spoken to soon about 'Donkey Kong II Return of Jumpman'. Arcadez notes say that the latest ROM should work, but it doesn't seem to. There's so much controversy about how the current development is somewhat scattered with this core, I may just wait until the dust settles a little before trying to troubleshoot it.

@herb_fargus, while searching, I saw where the game was running for you, but outside of the implication of lr-fbalpha, you didn't mention what emulator you were using. Was it in fact lr-fbalpha? Also, are samples functional for the 'Donkey Kong' games there?

markwkidd

edit:

mediamogul

I must have had an incomplete transfer, because the game wasn't launching with lr-fbalpha either. I resent the file and it launched in both cores. However, while I've obtained the improved dkong.zip sample and it works perfectly in lr-fbalpha, it doesn't seem to work in lr-mame2003-plus.

I have to admit to being a bit confused about how the newer samples are placed for this core. I haven't seen mention of a separate location for them, so I put the sample in ~/RetroPie/BIOS/mame2003/sample/ which didn't work. I can only imagine that there's another location, as 2003/2003-plus couldn't really coexist otherwise.

As a somewhat funny side note, dkongx needs dkong as a parent ROM, so I thought I'd see if it would launch using the Pauline Edition of dkong and it did actually launch, albeit with a messed up color palette for the character and collectable item sprites.

SuperMagicom

@herb_fargus I was talking about old Xbox tools related to the old sets, not the roms themselves. ;)

markwkidd

@supermagicom Yes there is no problem posting publicly here about patch files and ROM tools or talking about them. (That's pretty much what supermagicom PM'd me over @ libretro)

No posting about ways to get copyrighted ROMs themselves though of course.

I'm going to have to take a longer look at the old NeFe tool you have. I've never patched arcade ROMs with any tool, just rebuilt ROM sets. I'm not sure right off what kind of starting ROM NeFe is looking for or exactly what it will produce! This is the tedious side of digital archival...

dankcushions

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

I have to admit to being a bit confused about how the newer samples are placed for this core. I haven't seen mention of a separate location for them, so I put the sample in ~/RetroPie/BIOS/mame2003/sample/ which didn't work. I can only imagine that there's another location, as 2003/2003-plus couldn't really coexist otherwise.

they will be in the same location as lr-mame2003: https://github.com/RetroPie/RetroPie-Setup/wiki/lr-mame2003#samples

ie: /home/pi/RetroPie/BIOS/mame2003/samples/ (note: samples not sample)

so, yes - 2003/2003-plus can't really co-exist in this regard. it would be a simple code change to make it store in mame2003-plus/samples, though, if anyone wants to do that.

mediamogul

@dankcushions

Good to know. I opened an issue.

Riverstorm

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

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

I'd like to help track some of these down but, unfortunately, there's no way for anyone to contact users here privately

This being the primary reason private messages are disabled on this forum.

Introducing a more direct way to contact, communicate and collaborate with other users that don't exclusively involve leaving them a public comment every time would be great.

Pretty much every mainstream site has the ability and also a way to disable those features it if you don't wish to utilize them.

It does feels a bit like a paranoid big brother scenario assuming it's primary reason/use would be to discuss illicit ROM activity. I have to admit I wished for the feature more than once and none of them instances was ROM related.

I read @gamez-fan comment over on Github. He's slightly torqued off and threatened to take his ball and go home if we don't do it his way. I honestly don't want to make him mad but I am not sure how to communicate with him. I get the "I did it my way" mentality and how the XBOX was more like a wild-west scenario and DATs are a waste as he put it but it also seems fair to discuss the challenges of locating these old ROMs too.

He definitely seems a little anti-DAT from his comments. It seems like a reasonable way to build/verify a ROM set for a "homebrew" project. I guess the good is from his comment he's only using official ROMs from the correct time period now and removed all the old ones which is great.

Riverstorm

Not sure if you saw this @mediamogul but it looks like he already implemented a fix.

Some games require an additional zip file with recorded sounds or music in order for audio to work correctly. Audio 'sample' files should be placed in subdirectories within /libretro system dir/mame2003-plus/ e.g.:

/libretro system dir/mame2003-plus/samples/

High score, cheat, and history metadata files should be moved from github's /libretro/mame2003-plus-libretro/tree/master/metadata and placed within /libretro system dir/mame2003-plus/ e.g.:

/libretro system dir/mame2003-plus/hiscore.dat
/libretro system dir/mame2003-plus/cheat.dat
/libretro system dir/mame2003-plus/history.dat

User-generated content is placed in sub-directories within /libretro savefile dir/mame2003-plus/ e.g.:

/libretro savefile dir/mame2003-plus/diff/
/libretro savefile dir/mame2003-plus/nvram/
/libretro savefile dir/mame2003-plus/hi/
/libretro savefile dir/mame2003-plus/cfg/
/libretro savefile dir/mame2003-plus/inp/
/libretro savefile dir/mame2003-plus/memcard/
/libretro savefile dir/mame2003-plus/snap/

mediamogul

@riverstorm

Groovie ghoulies! Thanks for the heads up.

markwkidd

Hey @Riverstorm I wanted to call your attention to this github issue: https://github.com/arcadez/-mame2003-plus-libretro/issues/2

Seems like there are some new checksums for those NeoGeo ROMs. I haven't searched for them yet but I wanted to make sure you'd seen it too :)

Riverstorm

Thanks Mark I did see it and will take a look in a few weeks. We are heading out to Trinidad for Carnival in the morning and will be down there for a few weeks.

It's going to be a challenging day tomorrow as we travel through Chicago and Miami. American Airlines sent out a wearning of inclement weather in Chicago and expect possible delays out of O'Hare. We should be good if we can stay one step ahead of it. Also our flight is out at 5:50AM so we'll be up in the middle of the night, getting to the airport, not much sleep tonight.

Here we also have a winter weather advisory tomorrow and it supposed to drop down to -6F/-21C by weeks end so it's all good if we get out ok.

I always pack a change of clothes and the basics in a carry on going through O'Hare. I've been stuck there more than once. I still prefer like Minneapolis or Denver to Dallas or even LaGuardia out of New York for international.

GreenHawk84

So are these improvements going straight to the existing lr-mame2003? Or is this a new core being developed?