Main > Raspberry Pi & Dev Board

Raspberry Pi MAME Arcade Project

<< < (4/6) > >>

paigeoliver:
Mame has gotten continually slower over the years. Version 106 is (in my opinion) about 50 versions too new to use on weak hardware. Version .55 has always been a real favorite of mine, no major bugs in that release and it supports almost everything anyone would want to play.



--- Quote from: danny_galaga on September 22, 2012, 08:00:28 am ---
I'm another that's perplexed by the performance. I experimented with an old 100mhz laptop for a potential project some years ago, and I was able to run games like Space Invaders and Galaga just fine. Granted, it was a pretty early version of MAME on it but still...

--- End quote ---

MonMotha:
MAME is also generally only hacked on by people looking to use it on x86 type CPUs.  Even if there's no inline assembly, some of the "performance tricks" in the code may only work well on x86 and may actually hurt on ARM (there are other "tricks" that can go the other way, of course).  Note that CPU ISA makes a huge difference in the performance of MAME: some backends run much faster on AMD64 than IA-32 even on the exact same CPU due to things such as number of explicitly named registers.  If somebody wanted to hack on MAME to make it run better on ARM 1176, substantial improvements are probably possible, but I'd suspect most of the work in the "MAME on ARM" department is going to be focused on Cortex-A these days for use on modern smartphones, Beagle/Panda, etc.

Also, it'll depend on what compiler you use some.  Presumably, ARM Linux MAME is being built with GCC.  GCC's ARM backend is decent, but it's not as good as its x86 backend.  clang/LLVM may do better (or worse).  It's also possible that whoever built the build people are testing on the RasPi did something like use an old compiler or may have even had compiler level optimization disabled entirely or perhaps set for "generic ARM" which will generate pretty crap code for an ARM1176JZF.

FWIW, I'm not really fond of the SoC used on the RasPi, but it should perform OK.  It's a somewhat older pipeline arch and ISA (about one major generation behind the current Cortex-A8/A9 being used on most smartphones), but at 700MHz+, it should do OK.  Probably comparable to a 300-400MHz Pentium II.  It's lacking in the RAM and cache department, though, so you'll have to keep the working set reasonable, which should generally be possible for classics in MAME.  Combine this with the "MAME is getting slower" phenomenon, and you may have the explanation for your performance issues right there.

I guess to be clear here, it IS slower than even the "previous generation" of smartphones (single core Cortex-A8 at typically ~1GHz, roughly 1-2 years old now) by a fair bit.  It's relatively old hardware.  Figure you get what you pay for at $25; a modern smartphone costs about $200-500 and sometimes upward of $800 for high end ones (remember, they're heavily subsidized in the USA on 2-year contract).  Obviously much of that is for things not on the RasPi, but you're still an order of magnitude cheaper for the Pi.  It's a decent little dev platform, but not much more.

Haze:
yeah, I understand the reasoning behind it all, think it's a worthwhile cause and would love to be able to recommend it (I hate the locked down culture we have with every home system aside the PC today) it's just a shame it's so inadequate.

as difficult as it is to recommend something like compiling MAME for the original XBox due to the SDK legality issues and having to hack the device to run it, it sounds like the pi offers absolutely no *real* advantages over doing so and is likely to disappoint in equal measure even if some of the slightly speedier emulators such as FBA are ported.

MonMotha:
If you want a low power, reasonably open (arguably more so than the Pi), faster platform, you might look at the Pandaboard (especially ES model).  It's a dual core Cortex-A9 at 1.0/1.2GHz with a gig of RAM.  The 3D video is probably slower, but you don't care in this case.  It does cost quite a bit more, though (~$180), and it's somewhat bigger.  The Gumstix products are actually smaller and also available with OMAP CPUs more powerful than the one used on the Pi.  The A9 used on the Pandaboard is actually faster than most of the Atoms with a properly optimized workload at something like 1/4 the power.  It's pretty cool.  There's also a pretty fully documented DSP for you to play with, which may actually be useful for MAME acceleration (if anybody ever cared to support it).  It's normally used for audio decode and some video offload features (the GPU also handles some video offload), but it's a general purpose DSP.

The SoC used on the Pi was actually intended for media players and as such is extremely video focused.  The CPU is only there to run the OS and basic UI.  It was done by a "video processor" group at Broadcom, which explains why the GPU actually boots the thing (which is why you need a binary blob to boot it).

danny_galaga:

--- Quote from: MonMotha on September 22, 2012, 07:16:45 pm ---MAME is also generally only hacked on by people looking to use it on x86 type CPUs.  Even if there's no inline assembly, some of the "performance tricks" in the code may only work well on x86 and may actually hurt on ARM (there are other "tricks" that can go the other way, of course).  Note that CPU ISA makes a huge difference in the performance of MAME: some backends run much faster on AMD64 than IA-32 even on the exact same CPU due to things such as number of explicitly named registers.  If somebody wanted to hack on MAME to make it run better on ARM 1176, substantial improvements are probably possible, but I'd suspect most of the work in the "MAME on ARM" department is going to be focused on Cortex-A these days for use on modern smartphones, Beagle/Panda, etc.

Also, it'll depend on what compiler you use some.  Presumably, ARM Linux MAME is being built with GCC.  GCC's ARM backend is decent, but it's not as good as its x86 backend.  clang/LLVM may do better (or worse).  It's also possible that whoever built the build people are testing on the RasPi did something like use an old compiler or may have even had compiler level optimization disabled entirely or perhaps set for "generic ARM" which will generate pretty crap code for an ARM1176JZF.

FWIW, I'm not really fond of the SoC used on the RasPi, but it should perform OK.  It's a somewhat older pipeline arch and ISA (about one major generation behind the current Cortex-A8/A9 being used on most smartphones), but at 700MHz+, it should do OK.  Probably comparable to a 300-400MHz Pentium II.  It's lacking in the RAM and cache department, though, so you'll have to keep the working set reasonable, which should generally be possible for classics in MAME.  Combine this with the "MAME is getting slower" phenomenon, and you may have the explanation for your performance issues right there.

I guess to be clear here, it IS slower than even the "previous generation" of smartphones (single core Cortex-A8 at typically ~1GHz, roughly 1-2 years old now) by a fair bit.  It's relatively old hardware.  Figure you get what you pay for at $25; a modern smartphone costs about $200-500 and sometimes upward of $800 for high end ones (remember, they're heavily subsidized in the USA on 2-year contract).  Obviously much of that is for things not on the RasPi, but you're still an order of magnitude cheaper for the Pi.  It's a decent little dev platform, but not much more.

--- End quote ---

I'm not a tech expert so feel free to correct me, but I have a GP2X, and I thought that uses ARM processors. MAME works quite well on that, at a much lower frequency than this Raspberry machine. Of course there may have been more people working on the GP2X version, which draws on the strengths of a few versions. What I like about it is you can over/underclock individual games to conserve power. I think I had Space Invaders running at 88MHZ, and Asteroids at 166 for instance. And the menu can be underclocked too (I might have had it at 66 or summink) since it doesn't need that much to run (",)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version