Generating older lr-mame builds

roslof

Older binaries of lr-mame run games that the bleeding edge version cannot run. This topic is created while trying to build a 64-bit version of lr-mame version 0.222 (which was locked down in 2020 -- so to speak).

The 0.222 build was important in part because it's the last lr-mame build that did not include netlist discrete audio, which had adverse impact to several games on lower CPU systems such as the Raspberry Pi 3B+ and 4B. There are also some games like freezeat (Freeze prototype by Atari) that run too slow with modern lr-mame -- even on the new Pi 5.

It's known at this time that you can't simply take the existing lr-mame script and reference the older 0.222 commit, so focus here is to see if we can find a solution to build this 3-year old version.

Discussion started here in a Raspberry Pi 5 related thread.

Will continue discussion here.

ChaosEffect

@roslof This script from November ~~2021~~2020 doesn't work for me either:

https://github.com/RetroPie/RetroPie-Setup/blob/44f00eb3939c1d65ea6e8bb9eae1269403f726fa/scriptmodules/libretrocores/lr-mame.sh

This would be the first change to the RetroPie installation script for lr-mame after the commit you linked for 0.222. I will try the version of the script immediately before that too (May 2020).

The latest script + the one linked above both failed while compiling rendlay.cpp for me. I'm not sure if that has any significance.

I did notice that my RetroPie installation on Pi 5 includes diff patches for installing lr-mame2015 and lr-mame2016.

roslof

@ChaosEffect said in Generating older lr-mame builds:

I will try the version of the script immediately before that too (May 2020).

I tried it. Same problem, so save yourself some time.

I did find this older lr-mame issue from July 2020 which matches what we're seeing. Related to gcc10 10.1.0 (older/works) vs. gcc 10.2.0 and later, which contains this commit that broke things for lr-mame back in July 2020.

So... I suppose there would be a way to build gcc 10.10.1.0 and try again? Or...

This is the changelist that the lr-mame team used to resolve the issue around the time of lr-mame 0.224. It simply changes push to push_specific to multiple files in 3rdparty/sol2/sol. Should be a straightforward way to incorporate these changes and try to rebuild lr-mame.

ChaosEffect

@roslof Great find!

Here you go if you want to test it:

https://github.com/StormedBubbles/mame/tree/mame-0.222

I'm trying to compile using the older of the two scripts from around that time (including the CFLAGS="-fsigned-char" flag that will hopefully allow Time Crisis to work). I will squash those commits a little later.

roslof

@ChaosEffect said in Generating older lr-mame builds:

I'm trying to compile using the older of the two scripts from around that time (including the CFLAGS="-fsigned-char" flag that will hopefully allow Time Crisis to work). I will squash those commits a little later.

Sounds good. In parallel, I'm building using the modern script, manually altered the 7 sol-related files.

ChaosEffect

@roslof The compile with the 7 changed files using the May 2020 script + that extra flag worked. In terms of % speed given by pressing F11, Time Crisis was at about 80-81% during the heavy smoke in this version of MAME while current MAME has it dipping down to the 70-76% range (early game submarine explosion). Rail Chase 2 was hovering around 50% speed during the opening gameplay part where the train busts through when it's more in the 30-40% range in current MAME. This was with all default core options. I have some testing to do with some other games I'm curious about!

roslof

@ChaosEffect same success here. The existing script worked and I only needed to modify the rp_module_repo value by pointing it to your repo. Cheers!

EDIT: Ah, "that extra flag worked". I forgot that the flag was not part of the lr-mame.sh script and was fixed upstream, so of course Time Crisis did not work for me without the flag. But still, great to know the issue with older lr-mame builds is solved.

ChaosEffect

There does seem to be some benefit to Pi 5 users here other than "totally unplayable game becomes slightly less unplayable." Tekken Tag Tournament and Mortal Kombat 4 both had some dips when watching the speed counter in current MAME, but they both appear to be running at full speed in 0.222 without any overclocking.

MK4 would drop down to the 90% range in current MAME.

Tekken Tag was less obvious (maybe dropping down to 95% in current MAME).

This MAME version unfortunately predates the various mouse and lightgun changes I submitted to lr-mame in the last couple of years (expanding player count to 8, fixing the mouse buttons, allowing for multiple mice and lightguns). I can add those changes to this older version in the next couple of weeks if it seems like this will get used.

ChaosEffect

@roslof I have another couple for you.

One is MAME 0.209, which includes the Time Crisis helicopter fix from 0.203 and is the first Libretro version to include lightgun support. I am hopeful that this will give some improved performance for the game on my Pi 5 over 0.222 using the perhaps misguided "older = faster on pi" mantra. Unfortunately, the compile failed catastrophically almost immediately after downloading the source without an error that made it obvious to me what to do. Here is the source if you want to try:

https://github.com/StormedBubbles/mame/tree/mame-0.209

I tried with the current lr-mame install script as well as one from that time period with the same result.

Something I am more hopeful about is this:

https://github.com/libretro/beetle-saturn-libretro/issues/29

Tangentially related to MAME, but I noticed that your compatibility list mentions advmame as a candidate for running Sega Titan games. At least Die Hard is still problematic on a Pi 5 with 0.222 and current lr-mame, but Beetle Saturn runs Saturn games at full speed for me on Pi 5 without any overclocking. Perhaps someone will take a look at this in the near future and port over the necessary code.

roslof

@ChaosEffect said in Generating older lr-mame builds:

s ago

@roslof I have another couple for you.

Thanks for this. Will check this out.

grfc

@roslof Hi! I've been using your Pi 4B compatibility spreadsheet (awesome!), but have been scratching my head about how to easily install lr-mame 0.222 and lr-mame 0.251 as your sheet suggests. Is there a straightforward way to add both of these to my Pi 400 Retropie build?

roslof

@grfc said in Generating older lr-mame builds:

@roslof Hi! I've been using your Pi 4B compatibility spreadsheet (awesome!), but have been scratching my head about how to easily install lr-mame 0.222 and lr-mame 0.251 as your sheet suggests. Is there a straightforward way to add both of these to my Pi 400 Retropie build?

"Easily" is subjective, but I'll try to direct you on how you can do this.

For the Raspberry 4B, you'll need the 32-bit binaries of lr-mame 0.222 and/or lr-mame 0.251. Older binaries are linked at the top of my spreadsheet. You can reference this at anytime. For now, you can use this link to go straight to the 32-bit binaries for the Pi 4B.

You'll need to create folders in the libretrocores emulators folder for each binary:

sudo mkdir /opt/retropie/libretrocores/lr-mame0222/
sudo mkdir /opt/retropie/libretrocores/lr-mame0251/

Copy the respective binaries so they appear in each of these folders. Ensure the binaries are not in subfolders within these folders.

You'll need to set permissions on each emulator, or the game will not run:

sudo chmod +x /opt/retropie/libretrocores/lr-mame0222/mamearcade_libretro.so
sudo chmod +x /opt/retropie/libretrocores/lr-mame0251/mamearcade_libretro.so

I use "arcade" for my mame system, so I would backup emulators.cfg, then add two new lines. Below are examples, using the "arcade" system:

backup emulators.cfg:

cp /opt/retropie/configs/arcade/emulators.cfg /opt/retropie/configs/arcade/emulators.cfg.backup

Confirm the backup exists... then edit emulators.cfg:

nano /opt/retropie/configs/arcade/emulators.cfg

You should already have a line for launching lr-mame. COPY that line to create two new lines. Modify each of those new lines to reference 1. a new emulator name (like lr-mame-0222) to the left of the equals-sign, and 2. change the path to reference the older binary from lr-mame to the new folder lr-mame0222 and lr-mame0251 respectively for each link, and save the file.

Here are what my added lines look like for the arcade system (emulators.cfg):

lr-mame-0.222 = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mame0222/mamearcade_libretro.so --config /opt/retropie/configs/arcade/retroarch.cfg %ROM%"
lr-mame-0.251 = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mame0251/mamearcade_libretro.so --config /opt/retropie/configs/arcade/retroarch.cfg %ROM%"

This will allow you to select lr-mame-0.222 and lr-mame-0.251 per game with RetroPie's Runcommand interface when you launch your game(s).

These are the basics that should get you going. Be careful and again, please backup everything before you get started.

grfc

@roslof This reply is amazingly detailed, thank you for taking the time to write this up. End result: your instructions helped make everything work perfectly and I am now able to run the older versions of lr-mame. Thank you again!