Home Page Forums Archives MAME OS X ROM Management suggestion

For a newcomer to Mame OS X the Rom management works kind of weird, and keeps people from trying the program I feel.

My idea:
On startup load all ROMS in the ROM folder, and start auditing just the found ROMS. Now it works to the whole ROM list of all ROMS available. Not only does it take much much time, it also disables a quick start of a game in your rom folder (for newbies)

Also the search metaphore can be questioned. What ammount of ROM's do people probably have? Legally up to 50 maybe (if you buy the Atari and Konami packs). How many do you really play? The only use of search is for those who illegaly download the 5000 ROM Mame megapack on bittorent. It think it is another reason for turning the game list into a representation of your rom folder, instead of a doing a full audit of all possible available titles.

FWIW, you can play a game while it audits. The audit will stop, then resume after the game exits.


If you don't want the search, by all means, customize your toolbar, and remove it. Or hide the toolbar completely, if that floats your boat. I find the search is handy in the "All" tab, so it's not going anywhere.


I need to post this either in a sticky or on the MAME OS X site. You cannot just list the .zip files without an extension, as there is not a one-to-one mapping between game and .zip file. You'd be missing lots of games. Pac-Man is the definitive example. There *is* no pacman.zip. And there's no way, as far as I know to take a list of .zip files and find out which games those correspond to. That would be ideal 'cuz then we could just audit those games.

Oh, and audit is slow. I know. There's an open bug on this. Sorry. I only get a few hours a month to hack on MAME OS X. I probably won't fix this until I make MAME OS X Leopard-only.

-Dave

Well how works MacMame in this respect then? I like its ROM handling much better. You name Pac Man. The original is puckman.zip btw. With Mame OSX I see all offsprings. In MacMame I could trash all offsprings, and just keep the original working. No others show up, yet some ROM's remain in the ROM folder as they are needed.

Question: Is there a way to clear up the audit list by hand? Now many games show up in 4 or 5 "versions" where only the best would be enough.

So where exactly is the correlation? Does auditing the games involve reading the contents of each zip file and comparing them to the listxml data? Or is it the opposite - reading the listxml data and looking for something specific in the zip files?

It's actually much more complicated than that. I do have a pacman.zip file. Not everybody merges their ROMs. If not for merging, you could just grab a list of ROM files.

But you're right. Short of verifying each game that has a driver, you can't just derive a list of games in a reliable manner. I've been wrestling with this for some time while working on my own front-end. It's actually why I un-merged my ROMs.

FYI, AdvanceScan...part of the AdvanceMAME project, works perfectly for this (un-merging).

So let me try to understand this. Let's say I am working on a front-end for my arcade machine. If I want to display a menu of roms that I have in my ROMs folder, the easiest way is to un-merge my rom sets?

What about the reverse scenario. If I look at the output from the listxml switch, Pac-Man looks like this:
I have a merged set, so I should first look to see if a pacman.zip exists (taken from name="pacman"). If it doesn't, I should look at puckman.zip (taken from romof="puckman")?

Do I have the basic idea right?

What I do with EMUlaunch is map the zip file to name="*". Inside the <game> node is the <description> node which contains the name of the Game. So puckman.zip is actually catalogued with the following:
<game name="puckman" sourcefile="pacman.c">
<description>PuckMan (Japan set 1, Probably Bootleg)</description>
</game>

packman.zip is:
<game name="pacman" sourcefile="pacman.c" cloneof="puckman" romof="puckman">
<description>Pac-Man (Midway)</description>
</game>

Listxml is about a 27MB xml file last I checked. So if you are creating a front end and want to include listxml in your application, you may want to strip the file to only the info you need (which is what I do for EMUlaunch to get the listings like you see above. The only disadvantage of this is the dact that you run the risk of listxml being outdated in your app so make sure to give users the option to update this file themselves (which is unlikely but still).