Installation of Mamedev MAME

mitu

@George said in Installation of Mamedev MAME:

Looks like MAME is compiling. I modified /etc/default/distcc so that STARTDISTCC was set to true, but I still get "failed to distribute" warnings. It seems mostly to happen on .c files and not .cpp files though, which is odd.

Sometimes distcc (the client) would refuse to distribute the compilation, depending on the compiler options, so this might not be related to the service status, but locally on what the compiler requests. I remember I tried this when trying to cross-compile (using the same method, via distcc) lr-mess, distcc would refuse to distribute compiler lines that included -x cpp or -x c - this was later fixed in distcc (https://github.com/distcc/distcc/commit/09656168b2a981484fba1814b02de0f12ecf2407), but the version from 18.04 might not include that improvement.

George

Awesome. The cross-compiling is complete for both rpi1 and rpi2 builds. I now have two files:

stretch/rpi1/emulators/mame.tar.gz
stretch/rpi2/emulators/mame.tar.gz

I guess I have to copy the tgz files over to each respective Pi, but I think I'll need to look up how to install as binary as I didn't add that as an option in the script. I'll see if I can find some info out on the original cross-compiling post, but any pointers would be very helpful!

Thanks again for all the help!

- George

mitu

@George said in Installation of Mamedev MAME:

I guess I have to copy the tgz files over to each respective Pi, but I think I'll need to look up how to install as binary as I didn't add that as an option in the script.

You don't have to - just need to make sure your install step returns all the files needed to be installed in md_ret_files. The cross compile would take those files and create the archive and upload them to the RetroPie server (via rsync), then the setup script would detect if there's binary upload (archive) on the RetroPie's server and offer the option to install from binary.

After the binary archive is downloaded, it's unpacked in the install folder (/opt/retropie/emulators/mamedev) and then the configure step is executed - without any build steps.

I'll see if I can find some info out on the original cross-compiling post, but any pointers would be very helpful!

George

Gotcha. So there's no way for me to test the download from RetroPie servers (unless someone puts binaries there). But I can test md_ret_files and the configure step.

Quick question. I've currently set the script to run on v0207. Looks like they just released v0208. Yay. Any thoughts on just running on master vs. a specific release tag?

mitu

@George said in Installation of Mamedev MAME:

Gotcha. So there's no way for me to test the download from RetroPie servers (unless someone puts binaries there). But I can test md_ret_files and the configure step.

If you have a local web server, just change the binary_url here and test it locally. It's a bit tricky to get the right URL, since it contains the OS and arch, but it's doable.

Quick question. I've currently set the script to run on v0207. Looks like they just released v0208. Yay. Any thoughts on just running on master vs. a specific release tag?

I had a previous suggestion - https://retropie.org.uk/forum/topic/19303/installation-of-mamedev-mame/56 - to dynamically get the latest release tag from the repo without hardcoding a certain version:

you can get the latest release tag dynamically from Github. Look at how this is implemented in the Skyscraper module, here and here.

George

Awesome! I'll give changing the binary_url a shot. I'm hoping the URL path structure is similar to the archive path folder (a la stretch/rpi1/emulators/mame.tar.gz).

I forgot about your comment on getting the latest release tag. This is a pretty long thread. I'll work on it.

- George

George

Very cool. The script now pulls the latest version based on the GitHub release tag from their API.

I also did a test with changing the binary_url to point to my server and it worked like a charm. I'm going to try a few games and see how they perform on a Pi 3 vs. Pi 0. Perhaps I'll remove the !armv6.

Any other feedback is welcome! Thanks for the help @mitu, as always.

- George

George

Did some performance testing on a Raspberry Pi Zero. I used ChoccyHobNob's script to get a list of candidates to run in person, but the majority of them ran well below 100% speed. On the in person testing, nothing tested with a reasonable level of playing performance, even early games.

Needless to say, I pretty much expected this. I'll keep the !armv6 flag so it doesn't show up on RPi0s.

One thing I did notice is that in Emulation Station, the games are listed by their filename and not their game name (i.e. goldnaxe2 vs. Golden Axe). Is there some way to fix that?

Thanks!

- George

mitu

@George said in Installation of Mamedev MAME:

One thing I did notice is that in Emulation Station, the games are listed by their filename and not their game name (i.e. goldnaxe2 vs. Golden Axe). Is there some way to fix that?

Emulationstation does some translation for MAME games so they don't show up as opaque archive names.I think the translation is active only for certain systems (NeoGeo and Arcade) and it's based on this file.

George

@mitu said in Installation of Mamedev MAME:

Emulationstation does some translation for MAME games so they don't show up as opaque archive names.I think the translation is active only for certain systems (NeoGeo and Arcade) and it's based on this file.

I did some digging given the files you mentioned, and indeed EmulationStation will check to see if the system is part of the NeoGeo or Arcade platforms, and then use the file name translation XML file.

In order to determine if the system is a NeoGeo or Arcade, it will look at the /etc/emulationstation/es_systems.cfg XML file to check if the system has a neogeo or arcade in its platform tag.

That particular file is driven by the installation, particularly the addSystem() function, which calls getPlatformConfig() to get a whole bunch of config info for the system. That in turn reads
RetroPie-Setup/platforms.cfg. That file also drives names, extensions, themes for a system.

I don't see any way to drive the platform from the installation script, besides directly using the setESSystem() function (which no other scriptmodule does). I presume that the platforms.cfg file will need to be updated too?

Thanks!

- George

mitu

@George said in Installation of Mamedev MAME:

I don't see any way to drive the platform from the installation script, besides directly using the setESSystem() function (which no other scriptmodule does). I presume that the platforms.cfg file will need to be updated too?

Isn't your scriptmodule already using the arcade and mame folders ? It should already have that translation available - though for the example you've given (goldenaxe2) I don't think it's part of the mamenames.xml. Maybe the names XML file needs an update based on the current MAME romset.

George

Thanks @mitu,

It is already using the arcade and mame folders, but that doesn't seem to make a difference. If I manually edit /etc/emulationstation/es_systems.cfg and change the platform tag from mame to arcade , then the full names start to populate.

I also did find that some names are not in the mamenames.xml, but I'll leave that to a separate conversation. Enough files translate properly for me to see that it works when the platform tag is set correctly.

George

Hello,

Just wanted to check in on next steps for this. I think the script is pretty solid now, building on RPi 3, PC, and even with cross-compiling. I don't think es_systems.cfg is in the RetroPie-Setup repository, so I guess we can address that separately.

Is there anything that still needs to be done? Should I submit a ticket to the RetroPie-Setup GitHub or do a pull request?

Thanks again!

- George

mitu

@George Create a PR on the Retropie-Setup repository - github.com/retropie/Retropie-Setup.

George

@mitu said in Installation of Mamedev MAME:

@George Create a PR on the Retropie-Setup repository - github.com/retropie/Retropie-Setup.

Thanks @mitu. I just submitted a pull request. Had to do a little file cleanup to eliminate some previous versions I had committed under the same branch.

Thanks again for all the help!

- George