MESS as a possible addition

[geokm]

Hi,

What do you think about add MESS as you already include variants of MAME.

It would be awesome to have all the retro computer systems included in Retro Pie 8-)

8-)

[Jason Whiteman]

Note:

Currently working MESS.

Regards,
Jason

[Jason Whiteman]

One of the issues I ran into is a common issue using gcc 4.7.2 and MESS/MAME (… and other packages) – on more limited hardware, gcc runs out of memory and the result manifests itself differently depending on the memory left over for the compile.

Therefore, when compiling MESS or MAME – the compiler will error out on tms57002.c

The fixes (pick one), as are widely published:

1) Add more memory (not possible with Pi – although can use a cross-compiler and do that. This is not the architecture of RetroPie – so I am compiling everything on the Pi itself) See epilogue for more info.

2) Try an older/newer gcc g++ package. The buzz seems to indicate that 4.7.2 eats up more memory although too old and there are problems – some claim 4.8 fixes these issues. I did not test – although a 4.8 toolchain would be the most clean suggestion

3) For Pi the suggestion is already to give the GPU the minimum memory (16M) although this did not fix the issue.

4) Optimize less. Default for MESS/MAME is -o3. I tried -o2 for this issue and it did not help. (translates to OPTIMIZE=3 and OPTIMIZE=2 in the MESS/MAME makefile). OPTIMIZE=0 is the prevailing fix for this tms57002.c issue

The best fix is only to use less optimization on the target .c file(s) required. In the lab here, the fix was manual – patch makefile to OPTIMIZE=0, compile only tms57002.c (break out of makefile after output is generated) and patch the makefile back to OPTIMIZE=3 until the next failure if any.

—–

My fix happened to be a combination of #3 and #4 only because of the order of operations in attempting to fix. #3 requires a reboot as I have not found a dynamic way to force lower memory utilization (ignoring the option for dynamic – which is an “alpha” feature and not sure how it operates during this operation). Before generating a script, I’d have to validate that the OPTIMIZE=0 fix works with a higher GPU memory split then decide how to handle the target(s) that need OPTIMIZE=0 assuming this works with a more aggressive split (meaning less memory for the CPU).

Regards,
Jason

Epilogue:

… note to the search engine hits that find this for the memory issue (more detail on why RetroPie solution cannot involve cross-compile:

The RetroPie project entails a script to compile emulators native on the Raspberry Pi device. This script has a mode to pull sources from the net and compile from source using the limited 512MB memory minus the GPU allocated memory. Therefore, in the case of these constraints – using a cross-compiler on non-raspberry hardware would entail using precompiled binaries which is not the function of the script for this option.

There are possible alternatives that are currently out-of-scope for the project. But the constraints for this thread are assuming bare-metal Raspberry Pi compilation of MAME/MESS (and any other emulator for that matter).

[Author]

Posts