Installation of Mamedev MAME

mitu

@meyers980 said in Installation of Mamedev MAME:

I thought MESS stopped being developed a while back when it was rolled into MAME.

I'm not sure about naming, but Mess is now part of MAME - the lr-mess target is built from the same repository as MAME, including all the non-arcade targets. So yes, it's up to date - https://github.com/libretro/mame - with the current Libretro MAME core. You can check to which MAME version the Libretro core is synchronized.

meyers980

@mitu That's very interesting! I'm definitely going to be testing that soon then. Thanks for the info.

George

Some updates:

I encountered linking errors with MAME on the Raspberry Pi 0, and when I attempted to resolve them, it restarted the compilation process. Sigh. For the time being, I've disabled Pi 0/ARM V6 (by adding !armv6 into the module flags).
The script will now detect when being built on a PC and set the Swap space to be larger.
Also when building for 64 bit, it will move the binary from mame64 to mame, so that it is still recognized by the script.
Updated for MAME v0207

Feel free to have a look. I'm currently testing it out. https://github.com/GeorgeMcMullen/RetroPie-Setup/blob/master/scriptmodules/emulators/mame.sh

- George

markwkidd

@mitu said in Installation of Mamedev MAME:

@meyers980 said in Installation of Mamedev MAME:

I thought MESS stopped being developed a while back when it was rolled into MAME.

I'm not sure about naming, but Mess is now part of MAME - the lr-mess target is built from the same repository as MAME, including all the non-arcade targets. So yes, it's up to date - https://github.com/libretro/mame - with the current Libretro MAME core. You can check to which MAME version the Libretro core is synchronized.

I have just created a guide to compiling libretro-mame (including the MESS target: https://docs.libretro.com/development/cores/core-specific/mame/

If there is anything that folks discover would be useful to add for rpi and other RetroPie users, please feel free to either edit that doc directly or you can submit updates via a github issue in the docs repository http://github.com/libretro/docs

mitu

@George said in Installation of Mamedev MAME:

Feel free to have a look. I'm currently testing it out. https://github.com/GeorgeMcMullen/RetroPie-Setup/blob/master/scriptmodules/emulators/mame.sh

Just a couple of comments

you don't need to rename the binary, I'd leave it as is and have a separate function (_mame_get_binary_name) that will return different values depending on the target platform. Use that function in the subsequent routines where the binary name is expected. Just a suggestion.
due to the way ES works, you'll not be able to have arcade/mame as a (sub)system. arcade is already an existing system and its configuration will override any sub-folders' configs.

George

Thanks @mitu,

My most recent Pi 3 build was successful with my changes and v0207. So things are looking good.

@mitu said in Installation of Mamedev MAME:

you don't need to rename the binary, I'd leave it as is and have a separate function (_mame_get_binary_name) that will return different values depending on the target platform. Use that function in the subsequent routines where the binary name is expected. Just a suggestion.

I'll look into adding a function like _mame_get_binary_name. I think that will help keep it clean.

due to the way ES works, you'll not be able to have arcade/mame as a (sub)system. arcade is already an existing system and its configuration will override any sub-folders' configs.

I was using the scriptmodules for mame4all and advmame as a reference while doing the script. That's why I included the addSystem "arcade" lines (though I also include the optional arguments for description and file extension). Are you saying I should remove the addSystem line for arcade or remove the optional arguments?

In other news, I've found that the Pi can get very hot during compilation. I did not experience this before, but I recently put my Pi in a new mini-arcade case (reusing a case from an old broken Coleco tabletop arcade) and have the Adafruit LCD Kippah on it. All this adds up to very little ventilation. I noticed that certain files were taking an inordinate amount of time to compile. Did a little research and found this post:

https://raspberrypi.stackexchange.com/questions/83184/raspberry-pi-thermal-throttle

Sure enough, when running the commands:

vcgencmd measure_clock arm && vcgencmd measure_temp && vcgencmd get_throttled

My temperature was around 81C and the CPU clock was getting throttled. This may also explain why my Pi 0 was taking so long to compile, but that will require more research for another time.

So, heat sinks and ventilation are a must when trying to compile MAME (probably most versions). @markwkidd would that be useful info for your compilation guide?

- George

mitu

@George said in Installation of Mamedev MAME:

I was using the scriptmodules for mame4all and advmame as a reference while doing the script. That's why I included the addSystem "arcade" lines (though I also include the optional arguments for description and file extension). Are you saying I should remove the addSystem line for arcade or remove the optional arguments?

Advmane is using arcade and mame-advmame as ROM folders - see here.
Mame4All is using arcade and mame as ROMs folders - see here.

They're not configuring any sub-folders. So you can probably use arcade and mame (similar to Mame4ALL).

In other news, I've found that the Pi can get very hot during compilation. [...]

Did you hear about cross-compiling :) ?
https://retropie.org.uk/forum/topic/19854/install-and-configure-precompiled-emulator-binaries/5

George

@mitu said in Installation of Mamedev MAME:

Advmane is using arcade and mame-advmame as ROM folders - see here.

Mame4All is using arcade and mame as ROMs folders - see here.

I see that advmame is creating a sub-directory here, but it's not actually being referenced in the configuration file. In fact, I don't reference the arcade/mame subfolder either, so I could probably take out:

mkRomDir "arcade/$system"

as well as:

ln -sf "$romdir/$system/$mame_sub_dir" "$romdir/arcade/$system"
# fix for older broken symlink generation
rm -f "$romdir/$system/$mame_sub_dir/$mame_sub_dir"

Would that be it?

Did you hear about cross-compiling :) ?
https://retropie.org.uk/forum/topic/19854/install-and-configure-precompiled-emulator-binaries/5

8-O!!! I did not know about cross-compiling for RetroPie. I will have to check it out! Though, it's probably still good to do a compile test on the actual device.

- George

mitu

@George said in Installation of Mamedev MAME:

I see that advmame is creating a sub-directory here, but it's not actually being referenced in the configuration file. In fact, I don't reference the arcade/mame subfolder either, so I could probably take out:

I think that's for configuration or nvram, hiscore storage, but not dedicated ROM storage.

8-O!!! I did not know about cross-compiling for RetroPie. I will have to check it out! Though, it's probably still good to do a compile test on the actual device.

Timing a build is certainly useful - especially if the package is meant to be installed from source - , but not so much on a Pi Zero :).

George

@mitu said in Installation of Mamedev MAME:

I think that's for configuration or nvram, hiscore storage, but not dedicated ROM storage.

Yes, the symlinks are for nvram, hi, etc. but they are still not used in the config file (see here).

Updated the script again. Really want to nail down the (sub)system issue. I really appreciate the ongoing feedback! Thank you.

- George

mitu

@George said in Installation of Mamedev MAME:

Updated the script again. Really want to nail down the (sub)system issue

Which issue ? (you might have mentioned it during this topic, but I can't remember it).

George

Hahah, yes this thread is getting long. Just the issue of not having arcade/mame as a (sub)system.

mitu

@George I though you were referring to something like adding command line parameters for starting mame as a different system emulator, like lr-mess does for multiple systems.

George

@mitu said in Installation of Mamedev MAME:

@George I though you were referring to something like adding command line parameters for starting mame as a different system emulator, like lr-mess does for multiple systems.

Apologies for the confusion. I'm not trying to do anything like that. But I do want to make sure the script is as clean and conformant as possible.

George

Quick little update. I successfully built MAME on my Intel/Ubuntu RetroPie installation with the script. Things are looking good.

I have not been able to get cross-compiling to work though. Am I correct in my understanding that I should be able to cross-compile MAME for ARM/Raspbian Stretch on an Intel/Ubuntu machine? On one post I read that it might not be possible because of a large number of dependencies.

I get the following errors:

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
make[4]: Leaving directory '/home/george/Downloads/RetroPie-Setup/tmp/build/crosscomp/build-gcc/libcc1'
make[3]: Leaving directory '/home/george/Downloads/RetroPie-Setup/tmp/build/crosscomp/build-gcc/libcc1'
make[2]: Leaving directory '/home/george/Downloads/RetroPie-Setup/tmp/build/crosscomp/build-gcc/libcc1'
make[1]: Leaving directory '/home/george/Downloads/RetroPie-Setup/tmp/build/crosscomp/build-gcc'
Makefile:2302: recipe for target 'install' failed
make: *** [install] Error 2
~/Downloads/RetroPie-Setup

= = = = = = = = = = = = = = = = = = = = =
Running action 'switch_distcc' for 'crosscomp' : Create am arm cross compiler env - based on examples from http://preshing.com/20141119/how-to-build-a-gcc-cross-compiler
= = = = = = = = = = = = = = = = = = = = =

'/opt/retropie/admin/crosscomp/bin/cc' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-gcc'
'/opt/retropie/admin/crosscomp/bin/gcc' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-gcc'
'/opt/retropie/admin/crosscomp/bin/arm-linux-gnueabihf-gcc' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-gcc'
'/opt/retropie/admin/crosscomp/bin/c++' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-g++'
'/opt/retropie/admin/crosscomp/bin/g++' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-g++'
'/opt/retropie/admin/crosscomp/bin/arm-linux-gnueabihf-g++' -> '/opt/retropie/admin/crosscomp/stretch/bin/arm-linux-gnueabihf-g++'
sed: can't read /etc/init.d/distcc: No such file or directory
Failed to restart distcc.service: Unit distcc.service not found.

Again, thanks as always.

- George

mitu

@George said in Installation of Mamedev MAME:

. Am I correct in my understanding that I should be able to cross-compile MAME for ARM/Raspbian Stretch on an Intel/Ubuntu machine?

Yes, that should work. While not specifically for MAME, I did cross-compile lr-mame and lr-mess, but not using the RetroPie provided scripts - though it certainly should be possible.
What Ubuntu version and architecture are you using for cross-compilation ?

barbudreadmon

@George it might be a good idea to only include playable drivers when building mame for pi, i don't see the point of having all those 3d/preliminary drivers that will never run at playable speed on a rpi, except if you really want to compile for 2 days and a half, and exhaust your ram and disk space with huge executables.

For the remainder, it is described at 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.

Ofc, it would mean managing a list of those drivers

markwkidd

@barbudreadmon said in Installation of Mamedev MAME:

Ofc, it would mean managing a list of those drivers

The driver list could be generated by script but yeah of course someone's then got to write the script :|

mitu

@George I did try to cross-compile from an Ubuntu 18.0.4 host and it seems to work, but there's one gotcha - you need to copy your scriptmodule to the chroot that gets created. So the steps would be

# build the cross-compiler 
sudo ./retropie_packages.sh crosscomp setup stretch

# Compile one small package in the chroot, to get it created 
sudo   ./retropie_packages.sh builder chroot_build module lr-picodrive

# Copy your scriptmodule to $HOME/RetroPie-Setup/tmp/build/builder/stretch/home/pi/RetroPie-Setup/...., then run the cross-compilation.
sudo   ./retropie_packages.sh builder chroot_build module mame

Note that the builder will cross compile twice - for RPI 0/1 and for RPI 2/3. I haven't figured out how to compile for one platform only, but you can modify the builder script to exclude the platforms you're not interested in.
Some steps in the MAME compilation will be executed completely on the ARM chroot (.lay files 'compilation'), they won't get any significant speed up from cross-compilation, but overall it should be considerably faster to get a PI build using cross-compilation.

Leaving aside the cross-compilation, I have just one suggestion for your scriptmodule - you're currently hardcoding the MAME tag release, but you can get the latest release tag dynamically from Github. Look at how this is implemented in the Skyscraper module, here and here.

George

Thanks for the info @mitu. I've been trying to get a handle on why this is not compiling. I'm still getting stuck at that first step:

sudo ./retropie_packages.sh crosscomp setup stretch

This fails while building libgcc

Makefile:883: recipe for target '_gcov_dump.o' failed
Makefile:883: recipe for target '_gcov_flush.o' failed
Makefile:883: recipe for target '_gcov_fork.o' failed

Here's some info on my platform:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:        18.04
Codename:       bionic

The processor is an AMD processor and not Intel though. Not sure if that would actually make any difference here though. There don't seem to be any errors that would indicate a missing dependency either.

@barbudreadmon and @markwkidd, yeah the script could be modified to only include specific drivers. That would need some experimentation to see how much it would reduce the compile time. Thanks for the info.

- George