Installation of Mamedev MAME

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.

mitu

@George said in Installation of Mamedev MAME:

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.

You might as well disable it, waiting for 4 days to compile then finding out it's not really up to par it's not so user friendly.

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.

You can invoke different stages of the scriptmodule workflow through retropie_packages.sh:

sudo ./retropie_packages.sh mame sources # to download sources and apply patches
sudo ./retropie_packages.sh mame build # to compile the package
sudo ./retropie_packages.sh mame configure # to configure the package
sudo ./retropie_packages.sh mame clean # to clean up/wipe build folder
[.. etc..]

Make sure the build_mame function doesn't run 'make clean' and you should be able to resume compilation by using the build command for the package.

George

Oh wow. Thank you for the workflow info! That is invaluable! (Guess I should have asked before!)

Also, good point on disabling for Pi 0. I'll probably do that unless I find some games actually work well on it. ChoccyHobNob had some benchmarks done on a Pi B+. I'll try to replicate without overclocking. If nothing works, then it will be disabled.

George

Just wanted to let folks know that I have not abandoned this. In fact, I've just been continuing my tests. One of these tests has been to try a fresh install and compile on a Raspberry Pi Zero. The compilation step has taken over a month SO FAR. There may be something wrong with my SD card, but I have not seen any other issues, so I've just let it run. Hopefully it will finish soon and I can test out the binary which is expected to be very slow.

I'll update my Github with the latest scriptmodule once I've done some more tests. Thanks for the patience!

George

MAME is finally linking on my Raspberry Pi Zero. It's taken around 51 days so far. Haha!

jkman999

WOW!! That is crazy. I, for one, am watching this fairly closely as I would love to have just a few of those things running on the PI that are only in the newer versions. I really appreciate the work you are putting into it. Thanks.

J_K_M_A_N

George

Thanks JKMan,

It's been pretty smooth, so far, with the exception of getting it to compile on a Pi Zero. I'm still at that linking stage. I've gotten a couple of linker errors that I'm fighting through. The problem is that the linking process takes DAYS until it errors out on me again. I'm not ready to admit defeat on this yet though, even if the performance is abysmal on a Pi Zero.

I know it's been about a month since my last update. I'll try to give updates a little more regularly.

Thanks again,

George

meyers980

I know I'm definitely interested in this. George mentioned them up top, the recently added handheld LCD games (like Tiger Electronics, Coleco, and Game and Watch) are a big interest of mine. And building a handheld with a pi of some sort that could play those games would be wonderful.
The DEV team seems to be adding handfuls of old handhelds with each new build, as well. It seems like those games would run wonderfully on a pi but require new MAME to work.

mitu

@meyers980 You can get that by installing the lr-mess emulator, if you're interested in non-arcade systems emulated in current MAME. Currently, after installing it, it will configure the emulator to run VTech CRVision, Coleco, GB , Nes and Arcadia systems - so you'll have to manually add the other systems you're interested.

Compiling lr-mess on a Pi3 can take up to 30 hours.

meyers980

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

Are you saying non-arcade games added to MAME .204 for example can be played in lr-mess? Or just games added up until the merger?

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.