MAME Check Compatibility

Josh

I have narrowed it down, using clrmamepro, to 4,600 roms however still not all of them work with MAME2010 which is to be expected as it is experimental. I accept that there is never going to be a version of MAME with 100% compatibility so is there an automated way (bash script?) to remove the games that will not work. I am happy to loose a couple hundred games.

Thanks again,
Josh

dankcushions

mame does have internal flags for games that don't work (game_not_working) in the source code, but if you want to script that you'll have to do it yourself. i manually built a dat file for mame2003 with only parent roms, and ignoring those marked as game_not_working, which leaves under 2000 roms.

all in the wiki: https://github.com/retropie/retropie-setup/wiki/Managing-ROMs#lr-mame2003

Josh

How did you use ROMLister to create a .dat file? I have found catver.ini and nplayers.ini but my MAME Gamelist is blank, this is the directory I'm getting it from:
/opt/retropie/configs/all/emulationstation/gamelists/mame-libretro
Do I need to do a scrape?
I also can't find control.ini for MAME 0.139.

Thanks,
Josh

dankcushions

@Josh said in MAME Check Compatibility:

How did you use ROMLister to create a .dat file? I have found catver.ini and nplayers.ini but my MAME Gamelist is blank, this is the directory I'm getting it from:
/opt/retropie/configs/all/emulationstation/gamelists/mame-libretro

you need the 0.139 .dat file from (you guessed it!) the wiki https://github.com/retropie/retropie-setup/wiki/Managing-ROMs
(you may need to rename the file from .dat to .xml)

Do I need to do a scrape?
I also can't find control.ini for MAME 0.139.

the one here is what i used. http://mrdo.mameworld.info/mame.php
again, you might need to rename the extension.

but before you go down this road, again i would recommend simply downloading a 0.78 set and using mame2003, which isn't experimental.

Riverstorm

I don't know if this would help but it helped me quite a bit having a visual:

https://www.flickr.com/photos/chadwilson/14197659441/in/dateposted-public/

Non-merged sets use the most space and the most files because each zip file is a standalone game ROM that can work in MAME. The advantage is you can get the exact game version you're looking for like Defender red label, white label, etc. The drawback is it takes a while to parse the files and uses quite a bit more space.

Merged sets create the fewest files as each zip has all the master, clones, bootlegs, etc. in one file. The advantage is it's easy to get the correct game like for Donkey Kong you grab dkong.zip and it will work. The disadvantage is you end up with several versions of Donkey Kong that you don't necessarily want. It kind of clutters you game list.

Split Sets are in the middle so to speak. When you download sets they are usually in this format where the master ROM set holds the common ROMs and the clones and bootlegs only hold the additional needed ROMs to run that game. In this format it's not uncommon to only have 1 or 2 ROMs in the clone or bootleg. The advantage is good use of space the disadvantage is you have to always need the master game ROM even if it's not a version you want. If you only want a 2-player version of a game but the master is a 4-player version. You will need both to run the game. The pic above really helps illustrate how they work.

MAME doesn't care which version you use and you'll end up with a different number of files and space use depending on how you parse your files but all 3 methods work for MAME.

If you don't want to use a pre-built DAT you can create your own too:

You would download the mame.exe from http://mamedev.org under the 'Previous Releases' section. If you already have the DAT which has one included in the MAME4ALL for the Raspberry Pi zip you don't need the executable. There's some very minor differences between the DAT built from the official executable and the one included in the zip. I think the creator of MAME4ALL added a few more games to the DAT but no major/popular games were added. If I remember right it's less than 6 games roughly.

If you're using the executable vs. a DAT file you'll get prompted with some questions.

Issue: Possible wrong nodump definition found.

A valid checksum for it within its parent/clone relationship was found though. Insert found checksum instead of using the 'nodump'?

I answer 'No to all' for this question. It found a checksum for a ROM that matches and it may or may not work but MAME is telling you there is no known good dump and do you want to use it. It's really a preference and it may work even (14 years since 0.37b5 was released a correct dump might exist) but I still stick with 'No to all'. You can answer each one individually if you want to see what games it's referring to and tailor it for each game. It will only ask these questions once. You would have to delete and readd the DAT as a whole you're building to change these options.

Issue: Can't merge set due to equal names for different ROM hashes.

Press yes to remove parent/clone relationship or no to force split-merge mode.

I usually answer 'No to all' for this question. Most sets are in split-merge mode and it allows equal named ROM files in both the parent and clone. Unless your specifically building a non-merged set but for ROM auditing 'No to all' is pretty common. Same as above you can answer each individually if you want and delete to change them.

Under settings there's a Path/Headers section to add a path to the samples for auditing (the download would be accurate but if you want to verify them it doesn't hurt) or you can uncheck it. You'll often see people uncheck samples and CHD's. Samples would be needed for certain games and can be downloaded from the official MAME4ALL for the Rapsberry Pi:

https://code.google.com/p/mame4all-pi/ (A link to openhandhelds.org on his page for samples).

I don't think they were using CHD's in version 0.37b5 so it will probably be a grayed out option.

Sometimes when a set is being rebuilt it will dump a ROM in the backup folder as unneeded but when you do a Rebuild and tell it to look at the backup folder it will find valid ROMs for other sets it's rebuilding so I always use the backup folder first. After exhausting all options on your local PC then go hunt them down. It seems to be more common to find individual ROM's but there are full sets available too. I always run them through a ROM check.

It seems like a lot up front but it's really nice when you know you have a full verified set that's guaranteed to work! :) Also most of what this entails would work for all ROM set types like NES, C64, etc. It really is whether there's a DAT available to verify ROM's and if the source of the DAT is reliable, as in is it accurate. The official MAME program executable (referred to above) has DAT creation built right in which makes it very reliable.

Also if you're using the executable to build the ROM's under 'Options...' there's an option called 'Support Inverted CRC32'. Check that option when building the set 0.37b5 from executable. Way back in the day they used inverted CRC's to flag no dump ROM's (no longer done this way). If that option isn't ticked you'll have a few game ROM's that will be off like pignewta.zip. It's a few games that I imagine not many play but it's one of those things when you're going for that 100% clean set and you're banging your head against the wall looking for that one missing ROM file in the zip, that's why. It took me a while to figure that one out.

One other thing to keep in mind if building your own DAT from the executable is you'll need a 32-bit OS to run it. I don't know what version that changed in (years ago). Basically you would run mame -listinfo > 0.37b5.dat in newer versions it's -listxml instead of -listinfo. I was only pointing that out because it can be a pain if you only use newer computers which are 64-bit nowadays and sometimes finding an old 32-bit OS can be a challenge.

Josh

@dankcushions The links on mrdo.mameworld.info for controls.dat are down and I can't currently find a catver.ini either (is the one on mameworld out of date or too up to date?)

Thanks for the link to the gamelist!

Josh

dankcushions

@Riverstorm
man, all that stuff lost me! i don't think half of that stuff is needed - we already have the dat files we need, you don't have to build them via the mame.exe or whatever. the wiki should have everything needed for mame on the pi. it's pretty comprehensive.

@Josh

@dankcushions The links on mrdo.mameworld.info for controls.dat are down and I can't currently find a catver.ini either (is the one on mameworld out of date or too up to date?)

looks like the direct link is down, but edit the url a bit and you find th e page with the right link - http://controls.arcadecontrols.com/

i don't know about catver.ini. just use whatever you find. all this stuff does is add metadata to your dat file so romlister can give you more options to narrow it down. none of it is mandatory, really, depending on what you want to do.

Riverstorm

@dankcushions said in MAME Check Compatibility:

@Riverstorm
man, all that stuff lost me! i don't think half of that stuff is needed - we already have the dat files we need, you don't have to build them via the mame.exe or whatever. the wiki should have everything needed for mame on the pi. it's pretty comprehensive.

Yeah, that's true, when I first started out using MAME I know it's been 15 years at least or close. I was lost and not a lot of information. The ROM sets were pretty small but I think now all the sets, CHDs and LD-CHDs and rollback bring it in at over 400GB. The Pi has prompted some wonderful tutorials. It would have been handy back then as I spent a lot of time figuring it all out. I think the guy that programs ClrMamePro is Roman and I have so much respect for the guy and how he tirelessly answers the same questions over and over with patience. Really nice guy.

I did look at the Wiki and it's fantastic. For me the visual of Merged, Non-Merged and Split sets really helped when learning.

Are you going be making a mame2010 parent only set by chance once it's out of experimental?

Cyril

Thanks for the infos. I've been quite unsuccessful using clrmamepro. The page https://github.com/retropie/retropie-setup/wiki/Managing-ROMs however mentions that the retropie version is important: "A Raspberry Pi running a RetroPie v2.4.x, v2.5.x or v2.6.x SD card image. Other images may work, but they have not been tested with these instructions."

I'm running retropie 3.7, can that make cause problems? Do I need updated dat files?

senkun

@Cyril said in MAME Check Compatibility:

Thanks for the infos. I've been quite unsuccessful using clrmamepro. The page https://github.com/retropie/retropie-setup/wiki/Managing-ROMs however mentions that the retropie version is important: "A Raspberry Pi running a RetroPie v2.4.x, v2.5.x or v2.6.x SD card image. Other images may work, but they have not been tested with these instructions."

I'm running retropie 3.7, can that make cause problems? Do I need updated dat files?

the .dat files are up to date, just make sure you use the one for your target emulator.

dankcushions

i updated the wiki to avoid the confusion.

Josh

Even after using my own, custom ROMLister .dat file a lot of the games still don't function and it has taken out some of the games that did function before...

Does anyone have an idea of what it could be? Have I just made the ROMLister XML File wrong and does changing the file extension from .xml to .dat mess anything up?

Josh

dankcushions

@Josh hmm, did you make a custom romlister file yourself? it's very possible to make one that won't work! the pre-made ones should work fine though.

sscwb

Lucky for the raspberry users, we can create scripts like this one and test all the roms.
Hope you like it.
Create this file using "sudo nano checkroms.sh" and paste the contents.
Turn it into an executable using "sudo chmod a+x checkroms.sh" and execute it using "./checkroms.sh"
(Tested on Linux Mint)

#!/bin/bash

# adjust the roms path here
for i in `ls /home/retropie/mame/roms`; do

filename=`echo "$i" | cut -d"." -f1`
echo "Testing file $i:" >> cr_output.txt

# Here we will execute mame calling each rom
mame $filename 2>> tmp.out & export APP_ID=$!

# and kill the process after 2 seconds
sleep 2

kill -9 $APP_ID

# test to see if an error occured
size=$(du tmp.out | awk '{ print $1}')
if ((size > 0)); then
echo "rom $filename is not working" >> cr_rom_error.txt
rm tmp.out
else
echo "rom $filename is OK!" >> cr_rom-OK.txt
fi
done;

# End of script

After executing this script, you'll have two files. One with he roms that did not work, and another with the roms that worked.