Romsets for MAME2003 and FBA should be non-merged or splitted?

Libretro Lakka
#1

Hello, Guys

would rebuild my arcade-romsets for lakka with CMP here is my question… can i use a splitted romset (parents are complete .zip files with everything needed, and clones are .zip files with only their unique files, saving disk space) or must be a non-merged romset (parents and clones in their own stand-alone .zip files. This removes clone’s dependencies on parents, meaning you can take ANY of these .zip files (even the clones), put them in the appropriate ROM directory, and they should work)

and should i merge the “bios-roms” into each game or have to store them seperatly in the roms-folder ?

p.s. : wish you a merry christmas

#2

I copy bios files to system folder

#3

My understanding is that the MAME and FBA cores can both handle Non Merged and Split sets. I have never heard of moving the BIOS files into the Lakka system folder or manually adding the BIOS files to a Non Merged ROM zip, although that may work too. I think most users just keep the BIOS zips in the ROM folder with the games, as is done with standalone MAME.

#4

if i place the bios-files in rom-folder the names of the Bios-files will appeare in the generated playlists?

#5

If you’re using the AHK arcade playlist script, it should not add BIOS files to the playlist. If it’s the Lakka playlist generator, that should also not be adding BIOS files to the list. It would be a bug needing to be fixed if either generator did so, in other words. :slight_smile:

#6

In Lakka, for now, we decided to use Split romsets.

This may change in the future, but for now, if you want your roms to scan, use split.

1 Like
#7

FBA needs the bios inside the rom folder, and is able to run split, non-merged, and merged sets. I talked about arcade sets scanning in retroarch a few months ago on github (the current way is just no good for arcade sets : it relies on the fact you got a specific set and i think it needs to be torrentzipped too), but no one replied.

2 Likes
#8

Arcade scanning is not an easy problem to solve in RetroArch…

1 Like
#9

Well, i don’t know what is feasible, but i did several suggestions.

#10

I’m not sure either of what is possible. It will require experimentation.

#11

i think the support of splitted romsets is still a nice feature. save a lot of disc-space and had sometimes (when playing clones) even faster loadtimes.

#12

On my side, I prefer when we can get roms individually without taking care of getting the parent.

But it looks like more people agree with you and prefer to keep the whole romset anyway.

#13

Is there really no way to check only the zip name ? If we don’t check the content, both split and non-merged will be supported, whatever compression software was used. I don’t think it is retroarch’s job to check if rom’s content is good or bad, and anyway at the moment it doesn’t really work.

#14

I am pretty sure that the reason why RetroPie started recommending Non-Merged MAME sets was constant support posts on their forums from people having trouble with trying to use clones without parents.

It may be that the RetroArch/Lakka MAME emulation userbase is smaller, is more proficient with MAME ROM management, or is more likely to prefer having a complete set and doesn’t try to filter out games as much as the RetroPie users.

I have been studying the RetroPie forums in this matter, and whatever the reason they have had many more user problems with parent/clones than I see posted in the libretro forums. (Here it is mostly just people with the wrong ROM versions altogether.)

#15

I think the reason is all those ads saying you can build a retroconsole with a raspberry pi for around 50 bucks, retropie is extremely popular to people new to emulation thanks to this, so there are a lot of issues, especially since most people on internet don’t like to read, and mame/fba roms without reading any documentation is kinda hard.

2 Likes
#16

Non merged roms are clearly more intuitive for beginners

1 Like
#17

A new attempt to sum up the relationship between RA validation and native MAME validation after I spent time lately working with lots of MAME metadata for offline arcade playlist tools:

Three approaches to validating ROMs are coded directly into MAME, each with increasing precision. It seems like the RetroArch DB currently offers two different ‘engines’ (CRC and Serial), neither of which is anything like MAME’s approach.

MAME.exe Method 1: Always at execution, the MAME execututable/core ensures that the ZIP file has the exact filename of one of the titles it supports. Filename matching is therefore what most or all MAME frontends do to generate playlists or scrape metadata for ROMs. No real protection against mismatched MAME versions.

MAME.exe Methods 2 and 3: zip contents manifest and CRC dat MAME can export what it knows about the correct ROMs a DAT file (functionally equivalent to the pregenerated DATs available at ProgettoSNAPs etc). This provides two other approaches which are used to validate ROMs by programs like clrmamepro. 2) The filename list/manifest for each file in a supported ROM zip can be used to match/validate ROMs 3) The CRC of each of the ROM files within the ZIP is used to to validate the ROM.

If ZIP files store a contents manifest with CRCs as part of their header as was mentioned earlier, it seems not impossible to have a third scanning method aligned with MAME’s own scheme for validation. That’s easy for me to say though, because “Method 1” has been working well for my purposes. I don’t know about the ZIP format. :wink: