How to compile MAME with only specific roms?

[MacGyver]

I have a list of roms but lets say that it is only 60.
How can I compile just those 60 into MAME, so that all that binary knows is those 60 roms?
So if I type mame.exe -listroms, out pops the 60.

I have tried modifying tiny.lst, I've tried painstakingly creating a list of *.cpp drivers and putting that in arcade.lst.

The arcade.lst and compiling with SUBTARGET=arcade builds just fine, even spits out a binary, unfortunately it's a normal full 11,000 rom binary and not the cut down one you would expect from my very specific list of drivers I put in the arcade.lst file. Now if I get that list wrong, or leave out a needed dependency *.cpp it won't compile, so it is using that list, it just doesn't spit out the binary you would expect, one that only know about the drivers I put in the list.

Any ideas?
Has anyone else done this?

[abispac]

long time ago i asked the same question with no luck, im just gonna keep my eye on this one to see how it develops.

[baritonomarchetto]

I think you must remove drivers of all games other than those of your interest

[nipsmg]

This is actually spelled out in the mame documentation:

https://docs.mamedev.org/initialsetup/compilingmame.html

You can do driver specific builds by using SOURCES=<driver> in your make statement. For instance, building Pac-Man by itself would be make SOURCES=src/mame/drivers/pacman.cpp REGENIE=1 including the necessary REGENIE for rebuilding the settings

[MacGyver]

This is actually spelled out in the mame documentation:

https://docs.mamedev.org/initialsetup/compilingmame.html

You can do driver specific builds by using SOURCES=<driver> in your make statement. For instance, building Pac-Man by itself would be make SOURCES=src/mame/drivers/pacman.cpp REGENIE=1 including the necessary REGENIE for rebuilding the settings

I know, I actually did one for just williams games (which builds a 52 game version of mame), but it you try that with 3900+ drivers/machines is throws a "command line too long".

I think it might actually be working with the flt files as subtargets after all, it's just that it is still 10,000 roms too long. It is at 13,000 down from 42,000, I just can't tell if it's all the clones keeping it high, or the fact that it's building just generic non-mess and not my thinner one  that doesn't include non-working roms.

[Howard_Casto]

Other than a smaller exe size, there's no real benefit to removing drivers from mame.  It's a fairly pointless exercise. 

[MacGyver]

Other than a smaller exe size, there's no real benefit to removing drivers from mame.  It's a fairly pointless exercise.

I want to be able to manage the insanity that is the 44,000 games and the crazy amount of roms that each of those want.

Once I built the arcade.flt file to my liking (with only the drivers I want, and the remarks for the specific roms that the drivers build that I don't want, I was done.

I can build a 0.220 with just the lightgun games for my Linux box, and when .339 comes out that fixes something in that list, I can just build the .flt file on that source and out pops my custom binary that will tell me exactly what roms my list is missing for the new build.

For me it makes it more manageable, and when I use a rom manager or a list generator against a custom binary, it only spits out the list I want. No broken, no clones unless they are US and then no parent if I want to use the clone. I can build my non-merged rom set without it becoming insane in size.

My XML file is 900k not 250,000k like a full mame build would be.

When I run -verifyroms, my list is manageable and easy to resolve.

I didn't need a full new version of MAME and all the issues that come with it, I just need something I can throw lightgun games at now that I can use both my Aimtraks in Linux.

I attached the custom build list (remove the .txt off the name) so that anyone else that wants to make custom builds can see a working example. Or they can use it to build a lightgun only mame 0.220 build.  Whatever.
It goes in the source folder under "mame0220s\src\mame" and has the build command for a quad core at the top.

[Robbbert]

The way it was done in the old days was to remove or comment out all the unwanted stuff from mame.lst

But since there's about 36,000 games, you might be there awhile.

Or, just remove everything from mame.lst then add in the games you need. You don't need the spacing, the "source" lines or special formatting. Just one line per game.

[MacGyver]

The way it was done in the old days was to remove or comment out all the unwanted stuff from mame.lst

But since there's about 36,000 games, you might be there awhile.

Or, just remove everything from mame.lst then add in the games you need. You don't need the spacing, the "source" lines or special formatting. Just one line per game.

Can confirm that will work in Windows, Linux, not so much, it doesn't build an executable and spits out about 60 errors on the same mame.lst that works in Windows.  It did this with the arcade.flt and its weird driver method but it could be resolved by finding the dependencies that it thinks it wants and removing the extra roms that creates, but the mame.lst either has a name or doesn't, not a lot of things you can manipulate there.

Here is the linux output from the same simple mame.lst hat works in Windows.

Code: [Select]

Building driver list...
107 driver(s) found
Compiling generated/mame/mame/drivlist.cpp...
Linking mame64...
../../../../linux_gcc/bin/x64/Release/mame_mame/libsony.a(zn.o): In function `taito_fx1b_state::base_config(machine_config&)':
zn.cpp:(.text+0x3b51): undefined reference to `taito_zoom_device::taito_zoom_device(machine_config const&, char const*, device_t*, unsigned int)'
../../../../linux_gcc/bin/x64/Release/mame_mame/libsony.a(zn.o): In function `taito_fx1b_state::main_map(address_map&)':
zn.cpp:(.text+0x63e5): undefined reference to `taito_zoom_device::reg_data_w(address_space&, unsigned int, unsigned short, unsigned short)'
zn.cpp:(.text+0x640f): undefined reference to `taito_zoom_device::reg_address_w(address_space&, unsigned int, unsigned short, unsigned short)'
zn.cpp:(.text+0x6439): undefined reference to `taito_zoom_device::sound_irq_w(address_space&, unsigned int, unsigned short, unsigned short)'
zn.cpp:(.text+0x64cc): undefined reference to `taito_zoom_device::sound_irq_r(address_space&, unsigned int, unsigned short)'
zn.cpp:(.text+0x65b3): undefined reference to `taito_zoom_device::shared_ram_r(address_space&, unsigned int, unsigned char)'
zn.cpp:(.text+0x6625): undefined reference to `taito_zoom_device::shared_ram_w(address_space&, unsigned int, unsigned char, unsigned char)'
../../../../linux_gcc/bin/x64/Release/mame_mame/libsony.a(zn.o): In function `delegate_generic_class* delegate_base<void, address_space&, unsigned int, unsigned short, unsigned short>::late_bind_helper<taito_zoom_device>(delegate_late_bind&) [clone .part.392]':
zn.cpp:(.text.unlikely+0x13aa): undefined reference to `typeinfo for taito_zoom_device'
../../../../linux_gcc/bin/x64/Release/mame_mame/libsony.a(zn.o): In function `delegate_generic_class* delegate_base<void, address_space&, unsigned int, unsigned short, unsigned short>::late_bind_helper<taito_zoom_device>(delegate_late_bind&)':
zn.cpp:(.text._ZN13delegate_baseIvJR13address_spacejttEE16late_bind_helperI17taito_zoom_deviceEEP22delegate_generic_classR18delegate_late_bind[_ZN13delegate_baseIvJR13address_spacejttEE16late_bind_helperI17taito_zoom_deviceEEP22delegate_generic_classR18delegate_late_bind]+0x4): undefined reference to `typeinfo for taito_zoom_device'
../../../../linux_gcc/bin/x64/Release/mame_mame/libsony.a(zn.o): In function `delegate_generic_class* delegate_base<unsigned short, address_space&, unsigned int, unsigned short>::late_bind_helper<taito_zoom_device>(delegate_late_bind&)':
zn.cpp:(.text._ZN13delegate_baseItJR13address_spacejtEE16late_bind_helperI17taito_zoom_deviceEEP22delegate_generic_classR18delegate_late_bind[_ZN13delegate_baseItJR13address_spacejtEE16late_bind_helperI17taito_zoom_deviceEEP22delegate_generic_classR18delegate_late_bind]+0x4): undefined reference to `typeinfo for taito_zoom_device'
../../../../linux_gcc/bin/x64/Release/mame_mame/libsony.a(zn.o): In function `delegate_generic_class* delegate_base<unsigned char, address_space&, unsigned int, unsigned char>::late_bind_helper<taito_zoom_device>(delegate_late_bind&)':
zn.cpp:(.text._ZN13delegate_baseIhJR13address_spacejhEE16late_bind_helperI17taito_zoom_deviceEEP22delegate_generic_classR18delegate_late_bind[_ZN13delegate_baseIhJR13address_spacejhEE16late_bind_helperI17taito_zoom_deviceEEP22delegate_generic_classR18delegate_late_bind]+0x4): undefined reference to `typeinfo for taito_zoom_device'
../../../../linux_gcc/bin/x64/Release/mame_mame/libsony.a(zn.o): In function `delegate_generic_class* delegate_base<void, address_space&, unsigned int, unsigned char, unsigned char>::late_bind_helper<taito_zoom_device>(delegate_late_bind&)':
zn.cpp:(.text._ZN13delegate_baseIvJR13address_spacejhhEE16late_bind_helperI17taito_zoom_deviceEEP22delegate_generic_classR18delegate_late_bind[_ZN13delegate_baseIvJR13address_spacejhhEE16late_bind_helperI17taito_zoom_deviceEEP22delegate_generic_classR18delegate_late_bind]+0x4): undefined reference to `typeinfo for taito_zoom_device'
../../../../linux_gcc/bin/x64/Release/mame_mame/libsony.a(zn.o): In function `std::unique_ptr<device_t, std::default_delete<device_t> > emu::detail::device_type_impl_base::create_driver<taito_fx1b_state>(emu::detail::device_type_impl_base const&, machine_config const&, char const*, device_t*, unsigned int)':
zn.cpp:(.text._ZN3emu6detail21device_type_impl_base13create_driverI16taito_fx1b_stateEESt10unique_ptrI8device_tSt14default_deleteIS5_EERKS1_RK14machine_configPKcPS5_j[_ZN3emu6detail21device_type_impl_base13create_driverI16taito_fx1b_stateEESt10unique_ptrI8device_tSt14default_deleteIS5_EERKS1_RK14machine_configPKcPS5_j]+0x12a): undefined reference to `vtable for device_finder<taito_zoom_device, true>'
../../../../linux_gcc/bin/x64/Release/mame_mame/libsony.a(zn.o): In function `std::unique_ptr<device_t, std::default_delete<device_t> > emu::detail::device_type_impl_base::create_driver<gdarius_state>(emu::detail::device_type_impl_base const&, machine_config const&, char const*, device_t*, unsigned int)':
zn.cpp:(.text._ZN3emu6detail21device_type_impl_base13create_driverI13gdarius_stateEESt10unique_ptrI8device_tSt14default_deleteIS5_EERKS1_RK14machine_configPKcPS5_j[_ZN3emu6detail21device_type_impl_base13create_driverI13gdarius_stateEESt10unique_ptrI8device_tSt14default_deleteIS5_EERKS1_RK14machine_configPKcPS5_j]+0x12a): undefined reference to `vtable for device_finder<taito_zoom_device, true>'
collect2: error: ld returned 1 exit status
mame.make:268: recipe for target '../../../../../mame64' failed
make[2]: *** [../../../../../mame64] Error 1
Makefile:1132: recipe for target 'mame' failed
make[1]: *** [mame] Error 2
makefile:1349: recipe for target 'linux_x64' failed
make: *** [linux_x64] Error 2

Here is Windows build on the same list

Code: [Select]

Building driver list...
Emitting mamevers.rc...
107 driver(s) found
Compiling resources scripts/resources/windows/mame/mame.rc...
Compiling generated/mame/mame/drivlist.cpp...
Linking mame64.exe...
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: missing --end-group; added as last command line option


[Robbbert]

Seems that your linux build might be a little out of date, or you tried adjusting it incorrectly.

Make sure that the line MAME_DIR .. "src/mame/audio/taito_zm.cpp" exists (it's at about line 4087 in the current arcade.lua file).

[Howard_Casto]

It's a lot easier to just generate an admittedly huge and cumbersome list.xml and then filter that rather than altering mame itself.  Like I said, there isn't much point to it. 

[MacGyver]

Seems that your linux build might be a little out of date, or you tried adjusting it incorrectly.

Make sure that the line MAME_DIR .. "src/mame/audio/taito_zm.cpp" exists (it's at about line 4087 in the current arcade.lua file).

The mame source  is new from the official page and the build environment is up to date, Linux mame just really seems to hate building custom versions.
And as you can see the file is there. It will build a complete version and an arcade  and tiny version with no problems. The Linux system just doesn't seem to do dependencies correctly, at least not like the Windows versoin.

[MacGyver]

It's a lot easier to just generate an admittedly huge and cumbersome list.xml and then filter that rather than altering mame itself.  Like I said, there isn't much point to it.

It was a pain, but it is more like a crossword puzzle than anything, the challenge is the game, even if you need help with a word every now and again. And in the end I was able to get it to work the way I wanted, and my xml is manageable and my roms are perfect.

[makya]

for the record, you can use RomLister to make an lst file easily.

[fleskebacon]

Sorry for the necro, but I'm kind of noob, and I've been playing with this for a couple of days now. This thread gave me the best clues, so I thought it would be a good idea to get my conclusions out here, for future reference.

I just made a new .flt file, which can be done quite simply with mame -listsource <list of roms>, which then prints out all the needed drivers. The output file then just needs some simple editing to get rid of the rom names and then the duplicate lines. Making the initial list of your roms can be done in many ways. This was, by far, the easiest way I found. The .flt-file can be saved for next Mame version and re-used, or you can generate a new one in two minutes, to be on the safe side. Then compile with SUBTARGET=your-newly-generated-flt-file.

It should be noted that I achieved absolutely nothing with this, other than a smaller mame.exe, slightly faster compile time, and and last but not least: the satisfaction of knowing that I only compiled what I'm going to use. The smaller .exe *may* load a bit faster on my humble setup, but that might as well be placebo - I haven't done any measurements.

Romlister, though a bit outdated, can still be very useful in many ways for generating different types of romlists.

[Haze]

There really are no benefits to this.

Performance doesn't change
Loading times only change if you have a terrible Antivirus that attempts to analyze the whole executable

If you care about a minimal list, then your frontend should be doing that; even if you strip out the non-arcade stuff you're going to have some questionable sets otherwise - it's something more suited to external lists, which frontends can use.

Even if you have a complete ROMset and only care about part of it storage is laughably cheap, even for SSD these days and that's overkill.  You can buy 18TB spinning drives without breaking the bank.

The only MAME version you should ever really need is the latest official one which will always do the best possible job of anything you ask it; everything else (filters etc.) should be external.

Even in terms of overall MAME performance, not much has changed in the last 10 years; a new version with support for more systems performs just as well as a 10 year old version with support for fewer.  My own development PC is 10 years old, and only now am I considering upgrading it because we want to be able to push MAME to the next level.

If anything it's kinda sad that MAME got stuck in requiring PCs from about 10 years ago.

[fleskebacon]

I'm aware of all this. But with Mame being kind of a research project itself, I really enjoy compiling my own executable, and experimenting some on my own. I added and removed some other small features as well, and as an amateur it is quite satisfying to look a bit into the inner working of things like this.

So I gained a lot of knowledge and insight. Other than this, I achieved very little. But for me, these are huge benefits.

(And an SSD isn't at all overkill if you want a completely silent setup.)