Advice for MAME compilation on ARM architecture

[fsmunoz]

Hi all,


I'm new to the forum so I hope I'm not off-topic here. This is actually not so much about Pandora but rather looking for advice from the experience that a Pandora developer might have gained when porting software to the platform. I am also hoping that cross-compiling linux code from other platforms is interesting for Pandora owners/developers so the help could go the other way some time in the future.


I am trying to compile MAME for a prototype of the upcoming XO 1.75 Laptop from the One Laptop per Child Organization. It is based on a Marvell Sheeva ARM CPU which is compatible with the ARMv7 architecture, and runs a slightly modified Fedora 14 distro. I understand the Pandora has a similar architecture, and I see that MAME is available for the platform, so I was wondering if anyone experienced in compiling MAME for ARM could help me.


First question: which MAME to use? I've seen people giving AdvanceMAME a try, but I wasn't able to make it work. I also gave MAME4ALL a try, but was unable to make it work either (I got some strange "Relocations in generic ELF" errors)... so I'm currently progressing with the standard MAME source, and more precisely with the SDLMAME version for *nix.


Can anyone let me know which version has been ported to Pandora, and potentially any compilation tricks used on the x86 code to make it work?


I've been working on this for some weeks now (I'm just an amateur, so bear with my "development speed" here) and have finally been able to get it to compile, but with some tricks:


- I had to stub the function osd_yield_processor in /src/osd/sdl/osinline.h as it wasn't being implemented if the system architecture was neither x86, x86_64 or PPC


- I have to compile with the OPTIMIZE=0 flag due to a casting warning error: "warning: cast from 'UINT8*' to 'UINT64*' increases required alignment of target type"


...but the result is not working (I'm currently debugging) and performance is probably going to suck due to the OPTIMIZE=0 flag.


Anyone out there who could shed some light?


Thanks a lot for your help and best regards


F

 

[sebt3]

You wont be pleased by the performance you could get from the current MAME tree.


MAME4all is probably your best bet. Your mame4all compil error look like you actually crosscompiled the .o file but that you try to link with your host linker

 

[fsmunoz]

Hi Sebt3,


thanks for your email. I am dissapointed to learn that the original MAME won't have a decent performance. On the other hand, if MAME4ALL works correctly under lower resources, I am happy to follow that path.


On the errors I'm getting when compiling -or more specifically, when linking- MAME4ALL (src/raze/raze/raze_1.o: Relocations in generic ELF (EM: 3)), I haven't pursposedly crosscompiled anything. I downloaded the source and simply ran make. I tried again, but this time I searched for any .o files under the src directory before running make. I just found one (src/gp2x/mmuhack.o) and moved it to a different name just in case. I'm using the linux makefile anyway, so I don't think that has any impact.


The error I get is still the same.


Could this be due to binary/assembler code being inserted in an inline function directly? Doesn't this happen when compiling for the Pandora?


(EDIT)I´ve found the file that produces the problem and it's a compiled .asm file. It´s an assembler file that is somehow compiled upon running make. This might be the cause of the problem as this assembler code probably is not valid for an ARM processor. But how does this work in Pandora?


thanks a lot


Fernando

 

[laurent77]

hi guy


i like play with mame 106 than final burn


lolo

 

[fsmunoz]

Hi lolo,


thanks for the advice. I'm not being able to find help on how to compile SDLmame (the *nix version) for version .106. Do you have a link or know where to get the sources, and a guide on how to compile it?


Thanks


Fernando