Installation of Mamedev MAME

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.

George

Thanks for the clarification @mitu. I've updated the script to remove !x11. Let me know if you see anything else. I'll be continuing to test in the mean time.

mitu

I've tested the build on Ubuntu (x86_64) and - ironically - it crashes with not enough memory :).

[...]
as: out of memory allocating 4064 bytes after a total of 84123648 bytes
{standard input}: Assembler messages:
{standard input}:734193: Fatal error: can't close ../../../../linux_gcc/obj/x64/Release/src/emu/emumem.o: Memory exhausted
emu.make:1143: recipe for target '../../../../linux_gcc/obj/x64/Release/src/emu/emumem.o' failed
make[2]: *** [../../../../linux_gcc/obj/x64/Release/src/emu/emumem.o] Error 2

The system I'm testing had 4Gb RAM, I'm trying right now with more RAM added (6Gb) and see if it gets through.

EDIT: Seems 6 Gb makes the compilation go further and succeeds. The installation fails though, because the exe name is mame64 instead of mame:


Building driver list...
35435 driver(s) found
Compiling generated/mame/mame/drivlist.cpp...
Linking mame64...
Removing additional swap
~/RetroPie-Setup
Could not successfully build mame - MAME emulator (/home/pi/RetroPie-Setup/tmp/build/mame/mame not found).

I guess you could move the exe beforehand, just to simplify the install and configure procedure, or have different paths when a x86_64 binary is produced.

George

Thanks @mitu,

I'll try to do a compilation with a smaller amount of memory and see what might help. I actually thought that the rpSwap function might be doing something there, but perhaps that is only used on Raspberry Pis? (Does rp stand for Raspberry Pi or RetroPie?)

Are there any built in functions that can tell what platform the script is being run on, which may help facilitate looking for mame64 vs mame? Alternatively, I'll check to see if the makefile itself will have an option on naming the executable.

- George

mitu

@George said in Installation of Mamedev MAME:

Thanks @mitu,

I'll try to do a compilation with a smaller amount of memory and see what might help. I actually thought that the rpSwap function might be doing something there, but perhaps that is only used on Raspberry Pis? (Does rp stand for Raspberry Pi or RetroPie?)

rp is for RetroPie, but the way the swap adding works is that ensures you have at least the amount of RAM you request, it doesn't just get added on top.

Are there any built in functions that can tell what platform the script is being run on, which may help facilitate looking for mame64 vs mame? Alternatively, I'll check to see if the makefile itself will have an option on naming the executable.

I think there's a flag added to check for 32 vs 64 bit (see here). You can have an additional method (_get_mamedev_name) that would output the correct filename, so you can re-use it in the various methods of the scriptmodule (configure, install - to add it to the md_ret_files). For instance, the mame2003-plus module is identical with the mame2003, it's only the library name (the libretro core) that's different, so the other methods are re-used.

George

Cool.

I did a test on a system with 2gb of memory and used rpSwap 8192 and everything compiled fine (took over a day to compile though). Any thoughts on having separate rpSwap amounts based on x86 (8192) vs. Pi (2048)? I feel 8192M on a Pi is a bit much, taking a considerable amount of space on an SD card, but I don't have any evidence to say whether it would be more than what most people have available or if too much swap is detrimental on these systems. I haven't pushed my updates to GitHub yet.

Thanks for the pointer on isPlatform. I'll look to use that to distinguish mame64 vs. mame. I looked at the mame makefile, but it looks like the TARGET parameter gets overridden deep in a sub-makefile that seems to be generated somehow.

In other news, I attempted to load the binary, which was compiled on a Raspberry Pi 3, onto a Raspberry Pi 0 and got an "Illegal instruction" error when trying to run it. That's new to me, since I've done this before on the previous version of RetroPie/Raspbian without a problem. Any thoughts on what might cause the issue? I'm currently attempting to compile on the Raspberry Pi 0 to see if I can narrow down the issue. It will probably take ...some... time though before it is complete.

Thanks!

- George

mitu

I think you can add the swap based on the platform - 6/8Gb on an x86 and 2Gb otherwise. Also, regarding the exe name, I think it's best to not fiddle/hack the build system just for the name, you can just move or rename the file after the compilation or just keep the different names.
For the Pi 0 not running the Pi3 binary - I think it's normal since they have different CPUs (ARM6-Z vs ARM7-A) and the CFLAGS used during compilation target either the Pi1/0 or Pi2/3 (via -mcpu, see here).

George

Thanks for the pointers.

I'm thinking I'll add a few checks for x86 and x64 and set swap and rename the executable accordingly. So far, that seems to be the most straightforward way to do it.

On the Pi 0 end, I'm doing some compile tests to see how things go. I'm really just looking at compile-ability and run-ability. Performance-wise, the Pi 0 does not do very well with recent versions of MAME.

Side question: Is there any way to have the scriptmodule pick up where it gets left off? For example, if a compilation fails, I can go back and fix an error, but the next time the script runs, compilation will start from scratch. So far, the only thing I've been able to workaround is make a backup copy of the build directory and then put it back after the download step finishes.