Installation of Mamedev MAME

George

Hello all,

There are several different versions of MAME available from within RetroPie, and I thought I'd propose to also include the version of MAME that is maintained by Mamedev. There have been a few previous casual posts by others requesting this, particularly with regards to the versions for Raspberry Pi built by @ChoccyHobNob. I also found his builds a year or so ago while looking for ways to compile the more recent versions of MAME for Raspberry Pi. I've held back on posting about this until RetroPie was based on Raspbian Stretch, which enables the compilation of the most recent versions of MAME for Raspberry Pi (one could only use up to v0.176 on Raspbian Jesse).

Reasons to include the core Mamedev MAME:

It can run handheld ROMs (e.g. Coleco, Tomy, etc.) very well on a Raspberry Pi 3. These ROMs are more recent and thus not compatible with earlier (pre MESS merge ~0.166) versions of MAME. I've tested a few older ROMs with reasonable performance, though the handheld ROMs were my original focus.
I already wrote an installation script, based on a build from @ChoccyHobNob for MAME v0.200. (https://github.com/GeorgeMcMullen/RetroPie-Setup/blob/master/scriptmodules/emulators/mame0200b-rPi.sh).
While the lr-mame experimental installation script may be sufficient for some, it requires installation from source (i.e. compilation). Additionally, the libretro mame repository doesn't have any releases or tags past v0.179.
There are builds of RetroPie for Intel processors (Debian / Ubuntu), which would take advantage of a presumably faster processor than Raspberry Pi. It makes sense that a person with a faster processor would not be as concerned with poor ROM performance and may rather just want to run the most recent version of MAME. I have not included an Intel build of the latest MAME in my script though.

Thanks in advance for your fair and constructive feedback. Let me know what you think.

Thanks!

- George

dankcushions

i don’t see the harm! i think for x86 builds it’s what i would use, but for pi i would not recommend it, but at the same time, there’s no harm in adding it to the optional/experimental packages, etc.

BuZz

I'm not against adding it, but your module above is not suitable for inclusion (for various reasons, but wouldn't want to install 3rd party binaries for this and the module code is not suitable in the current form).

Feel free to add it as a feature request on our bugtracker. It would be source only though initially until the module migrated from experimental to optional.

sirhenrythe5th

as far as i understood this thing with MAME (which i love since 20 years now starting with 34b7 on Windows) the only Pi-Version that takes advantage of the Pi-struture is AdvanceMame.
That is also the point why i use it from the start and never even tried any lr-mame.
(plus the Scanlines and the ability to set buttons per game like i want. I.e. Shoulder-Buttons for Pinballs or Gear-Shifting and so on)

I could imagine that the Mame-DevTeam would be able to create an awesome Pi-Version. At least when godlike-Aaron Giles does that.
But till this happens i will stay with AdvanceMame.

George

Thanks for the feedback.

Yes, I expected that the scriptmodule would not automatically be accepted as-is, particularly because it references a binary and that the script was intended for exploratory purposes. As for AdvanceMame, I like that too, and this would not be a replacement but an addition. Evidently, there are some experiments being performed by Mamedev for ARM processors (see their arm_playground branch).

Would filing a ticket on the RetroPie GitHub be the proper channel for a feature request? Originally I was going to file one, but thought this might be a better forum for discussion prior to an official request.

I would be interested to hear what else can be changed/added to the script to make it more suitable. Here's my running list so far.

3rd party binary location. I presume that either there would have to be an official build from the Retro Pie team or even the Mamedev team, or an existing APT bundle.
There are comments included which are meant for people manually installing the script, which would be removed.
One of the comments in the script is instructions on changing the default resolution for the emulator, which is important because even the hand-held games will run slowly if the resolution is too high. Not sure how to tackle that part.
There is some code which sets the proper theme for the emulator as the Arcade/MAME theme, since addEmulator() and addSystem() no longer take a theme parameter. That code is based off of some other code existing in RetroPie setup, but would not be needed once es_systems.cfg contains the proper references for the emulator.
An install from source option would probably be required, though according to ChoccyHobNob's site, the Pi must be rebooted after changing the swap size (amongst other changes). I don't see this requirement in the script for lr-mame, though when I tried to install lr-mame from source, the compilation failed.
The script is hard coded for MAME v0.200. Most other emulators besides MAME aren't set for specific versions. I suppose the ability to use different versions of MAME is good in the sense that some versions run some games better than others, and others run games that the earlier ones can't (a la hand-held games). But this begs the question on if it is better to always point to the latest or have different scripts for each version of MAME (on top of the 9+ other MAME scripts).
The config directory is the default ~/.mame/ directory. I do not know if there exists any conflicts with other MAME installations.
There is no error additional error checking, meaning that if the wget for the binary fails, RetroPie still lists it as being installed. I expect that some of that would change by default once an official build is in place. (BTW: I used wget vs. downloadAndExtract() because the latter doesn't provide any detail on the download progress (which is important when downloading a large file over a slow network connection).
There are a few lines that move files around and change permissions just based on the way the zip file gets extracted.

Thanks again!

- George

mitu

@george said in Installation of Mamedev MAME:
[..]

Would filing a ticket on the RetroPie GitHub be the proper channel for a feature request? Originally I was going to file one, but thought this might be a better forum for discussion prior to an official request.

The proper way is to first bring it up in the forums, then see the feedback and then submit an issue or a PR - as @BuZz suggested and which is also outlined in the Github issue template. So far it's going as it should :).

I would be interested to hear what else can be changed/added to the script to make it more suitable. Here's my running list so far.

3rd party binary location. I presume that either there would have to be an official build from the Retro Pie team or even the Mamedev team, or an existing APT bundle.

Yes. I don't know if the MAME team publishes a binary distribution for the armhf or similar architecture, but the RetroArch team does - for their libretro cores, including lr-mame.

There are comments included which are meant for people manually installing the script, which would be removed.

One of the comments in the script is instructions on changing the default resolution for the emulator, which is important because even the hand-held games will run slowly if the resolution is too high. Not sure how to tackle that part.

Resolution change is part of the Runcommand in RetroPie, so you can safely omit this, though it should be documented for the emulator.

There is some code which sets the proper theme for the emulator as the Arcade/MAME theme, since addEmulator() and addSystem() no longer take a theme parameter. That code is based off of some other code existing in RetroPie setup, but would not be needed once es_systems.cfg contains the proper references for the emulator.

An install from source option would probably be required, though according to ChoccyHobNob's site, the Pi must be rebooted after changing the swap size (amongst other changes). I don't see this requirement in the script for lr-mame, though when I tried to install lr-mame from source, the compilation failed.

There's no need for a reboot after adding Swap. Both lr-mame and lr-mess script modules have provisions to add/remove swap before/after compilation from source.

The script is hard coded for MAME v0.200. Most other emulators besides MAME aren't set for specific versions. I suppose the ability to use different versions of MAME is good in the sense that some versions run some games better than others, and others run games that the earlier ones can't (a la hand-held games). But this begs the question on if it is better to always point to the latest or have different scripts for each version of MAME (on top of the 9+ other MAME scripts).

You mean like having 1 version for each MAME (monthly) release ? That would only confuse users and be tedious to maintain and support.

The config directory is the default ~/.mame/ directory. I do not know if there exists any conflicts with other MAME installations.

There is no error additional error checking, meaning that if the wget for the binary fails, RetroPie still lists it as being installed. I expect that some of that would change by default once an official build is in place. (BTW: I used wget vs. downloadAndExtract() because the latter doesn't provide any detail on the download progress (which is important when downloading a large file over a slow network connection).

Rather than using wget, maybe try and improve the existing downloadAndExtract instead to show the progress. I think you can use $md_ret_files in the install function to make sure you have the right files before copying them to the emulator folder - the scriptmodule installation would fail if those files are not present.

BuZz

@george said in Installation of Mamedev MAME:

Would filing a ticket on the RetroPie GitHub be the proper channel for a feature request? Originally I was going to file one, but thought this might be a better forum for discussion prior to an official request.

Yes - once it has been agreed here - I'm happy for you to do so

3rd party binary location. I presume that either there would have to be an official build from the Retro Pie team or even the Mamedev team, or an existing APT bundle.

it would be source only until we include it in optional - then we can host binaries on my server. Actually, I can host bins for experimental packages, but I don't generally build them, but I could make an exception for this.

One of the comments in the script is instructions on changing the default resolution for the emulator, which is important because even the hand-held games will run slowly if the resolution is too high. Not sure how to tackle that part.

This would be something we can document on the wiki.

There is some code which sets the proper theme for the emulator as the Arcade/MAME theme, since addEmulator() and addSystem() no longer take a theme parameter. That code is based off of some other code existing in RetroPie setup, but would not be needed once es_systems.cfg contains the proper references for the emulator.

that shouldn't be needed. Themes are handled from the platforms.cfg

An install from source option would probably be required, though according to ChoccyHobNob's site, the Pi must be rebooted after changing the swap size (amongst other changes). I don't see this requirement in the script for lr-mame, though when I tried to install lr-mame from source, the compilation failed.

When source is available retropie uses it. We only have binary only installs for non free stuff. You don't need to reboot to add more swap (at least not in the way retropie-setup does it)

The script is hard coded for MAME v0.200. Most other emulators besides MAME aren't set for specific versions. I suppose the ability to use different versions of MAME is good in the sense that some versions run some games better than others, and others run games that the earlier ones can't (a la hand-held games). But this begs the question on if it is better to always point to the latest or have different scripts for each version of MAME (on top of the 9+ other MAME scripts).

I would point it to the latest tag/release branch

BuZz

@mitu Sorry - I missed your replies .

mitu

@buzz I think your answers add to the picture I started painting.

George

Wow, thanks for all the input @BuZz and @mitu.

Yeah, the MAMEdev team does not publish a binary for armhf. In fact, they point to ChoccyHobNob's page.

I've started putting together a new scriptmodule which would perform a build from source, pointing to the latest release tag. It will of course take some time to test because compiling MAME on the Pi takes a loooong time. Thanks for the tip on adding/removing swap.

@BuZz does your server host binaries in plain ZIP form or is it an APT repository?

Regarding the resolution change, I imagine that the best place to do this would be on: https://retropie.org.uk/docs/MAME/ in a section for performance. Too bad that is the only tip I could offer that helps performance (changing the audio sample rate doesn't really help as much as I would expect).

Once I get the new scriptmodule in shape, I'll post an update.

Thanks again,

- George

George

Well that took a while.

Finally got MAME to compile on a fresh RetroPie install, after installing the minimum required dependencies. It looks like RetroPie already comes with a good number of dependencies already installed (primarily, SDL 2.0.8, which required its own set of dependencies to compile). Here's a list of the other dependencies that were required in order to compile.

libsdl2-ttf-2.0-0
libfontconfig1-dev
qt5-default
libsdl2-ttf-dev
libxinerama-dev

If anybody knows of any others that might be required (and not already on RetroPie), specifically for performance, etc. Let me know. As I said though, I've been able to compile MAME so I believe I'm good. Oh yes, and it runs and I'm able to play the handheld games (Coleco, Tomy, etc.).

In terms of the scriptmodule, the only downside I see right now is that MAMEdev uses the master branch on git as their development branch, and they don't have a "release" branch. So the script will have to be updated every time a new release comes out, if we want to keep it current. And of course this will also require building, testing, etc. every time a new release comes out. It may in fact just be better to only update it every once in a while, for example, with every release of RetroPie.

Here is a list of files/directories that I've added to the md_ret_files variable. There are more that get created by the build process, but I'm thinking that the build and src directories (among others) are not required. I'm using ChoccyHobNob's build as an example (though his also has some files I don't). I'm wondering if the artwork, ini, roms, and samples directories are actually required here as the configure function takes care of ini, roms and samples at least. On the other hand, it seems like some functionality, like hi scores have moved to plugins, and it would require write permissions (or moving that directory elsewhere). Again, feedback is welcome here.

artwork
bgfx
ctrlr
docs
hash
hlsl
ini
language
mame
nl_examples
plugins
roms
samples
uismall.bdf
LICENSE.md

My next step is to basically start from scratch. Do a build all over again, on ANOTHER fresh install of RetroPie, to make sure that I've got the build process down with all the dependencies.

I guess I'll be back in a few days!

- George

George

BTW: If you want to take a look at the script so far, please do. Feedback is welcome.

https://github.com/GeorgeMcMullen/RetroPie-Setup/blob/master/scriptmodules/emulators/mame.sh

- George

George

A note for future reference. I wanted to check how SDL2 was compiled for RetroPie, as ChoccyHobNob's page indicates that Raspbian Stretch comes with a version that doesn't perform well with MAME (2-3 fps). After a little digging, I found RetroPie-Setup has a scriptmodule for SDL2, located at:

https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/supplementary/sdl2.sh

This references RetroPie's own SDL mirror, which includes a build script to configure and compile SDL2, located at:

https://github.com/RetroPie/SDL-mirror/blob/rpi-2.0.8/build-scripts/raspberrypi-buildbot.sh

The "configure" statement is very close to ChoccyHobNob's configure statement, disabling almost all of the same things (pulseaudio, esd, video-mir, video-wayland). This is true except for video-opengl.

I imagine that there are other packages out there that require OpenGL. I have not yet tested if there is a specific difference in performance when OpenGL is enabled in SDL vs. not. But I don't expect a massive boost in performance, which would then create the quandary of what version of SDL2 to use or if it's even possible to have two versions of SDL2 installed.

I'll add more if I find any reasonable difference.

- George

mitu

@george said in Installation of Mamedev MAME:

This references RetroPie's own SDL mirror, which includes a build script to configure and compile SDL2, located at:

If your scriptmodule runs from a RetroPie installation, I think you can always assume the RetroPie 2.0.8 (at the moment) version is installed and available you shouldn't add anything in your script to handle the installation. I think that OpenGL is not disabled for x86, you can test that if you're using this platform.

BuZz

@george said in Installation of Mamedev MAME:

This references RetroPie's own SDL mirror, which includes a build script to configure and compile SDL2, located at:

https://github.com/RetroPie/SDL-mirror/blob/rpi-2.0.8/build-scripts/raspberrypi-buildbot.sh

We don't use this script for building SDL2.

BuZz

@mitu said in Installation of Mamedev MAME:

If your scriptmodule runs from a RetroPie installation, I think you can always assume the RetroPie 2.0.8 (at the moment) version is installed and available you shouldn't add anything in your script to handle the installation. I think that OpenGL is not disabled for x86, you can test that if you're using this platform.

Yep. So long as sdl2-dev is included as a dependency the retropie SDL2 will be installed.

George

Hello all,

Just wanted to give a bit of an update. My script module for MAMEdev MAME has been coming along nicely. I've hammered out all the dependencies, the appropriate amount of swap space, the new high score plug-in, updated for v0.203, and tested on a fresh RetroPie installation. It's looking very good.

I'd love to get some feedback on it and talk next steps. Here is the script:

https://github.com/GeorgeMcMullen/RetroPie-Setup/blob/master/scriptmodules/emulators/mame.sh

I did not include an "Install Binary" option this time, as per the comment by @BuZz . But if you're willing to host the binary, I'd be more than happy to update the script accordingly. Compilation time was 2 days, 10 hours on a Raspberry Pi 3. So I imagine it might be helpful.

Thanks again,

George

mitu

The binary install will be automatically detected at runtime by the setup script if it's going to be hosted by the RetroPie archive server, so you don't have to provide anything extra in the script.
Is there a reason for excluding x86 as a platform (with the !x11 flag) ?

George

Thanks @mitu ,

I didn't realize that about binary installations. Pretty cool!

With regards to the rp_module_flags, I couldn't find much documentation on it besides how it was compared to the current platform in order to determine whether to display / hide a script module in the RetroPie Setup, so I checked out other scripts. Here are my notes:

!x11 is referenced in the mame4all script, which also correlates to what I've read about MAME/SDL performing poorly when compiled with X11 support (at least on the Pi)
list itemI saw some scripts with an !x86 flag, which I do not use, since this should run fine on X86 platforms.
Please correct me if !x11 will in addition cripple X86 availability.
!mali is referenced by both advmame and mame4all, which indicated to me overall poor performance or untestability on Mali based platforms. I don't have an ODroid to test it.
Other scripts use !kms, but I did not include that as I thought that X86 might have kernel mode switching capability.

Let me know if you have any suggestions on better rp_module_flags.

Thanks again for the feedback and guidance.

- George

mitu

Normal Linux distros on the PC are running RetroPia via X.org, not using the framebuffer (like the Pi or other SBCs), so the x11 flag is automatically added to them. Using !x11 will make the scriptmodule not be available to them. See here for the flags added to any x86 installation.