MAME 0.164 on Raspberry Pi2

EDIT: You may prefer to read this post, for an updated version of MAME, or maybe this page for detailed compile instructions.

Ever since the Raspberry Pi2 came out I’ve been wondering about how it would handle MAME. Not MAME4ALL or AdvanceMAME but the full latest version of MAME (Currently 0.164) I’ve heard people asking about it on various forums and on Reddit. It may be a lot slower they say, but maybe it will be fast enough on the Pi2 that the classics will play?

Got to be worth a shot, I thought. How hard can it be?

I Googled. I found two attempts back in 2012 both fails with no updates. Hmm, maybe not as simple as I thought.

OK lets give it a go…

mkdir mamepi
unzip -d mamepi
cd mamepi

Fail! It seems we need SDL2 and the first version to support Pi2 is 2.0.4 which isn’t released yet, but it’s close so lets grab the RC.

sudo apt-get install build-essential libfreeimage-dev libopenal-dev libpango1.0-dev libsndfile-dev libudev-dev libasound2-dev libjpeg8-dev libtiff5-dev libwebp-dev automake 
tar zxvf SDL2-2.0.4.tar.gz 
cd SDL2-2.0.4
./configure --disable-pulseaudio --disable-esd --disable-video-mir --disable-video-wayland --disable-video-x11 --disable-video-opengl --host=armv7l-raspberry-linux-gnueabihf 
make -j 4
sudo make install

That went OK, lets try MAME again

cd mamepi
make clean

Fail! It needs SDL2_ttf as well sigh, here we go again.

tar zxvf SDL2_ttf-2.0.12.tar.gz 
cd SDL2_ttf-2.0.12
make -j 4
sudo make install

That went OK, lets try MAME again

cd mamepi
make clean

Now we’re getting somewhere, it seems to be compiling ok, but slowly. So I leave it for a few hours and come back to Fail!

Looks like a memory problem, duh!

sudo nano /boot/config.txt

Change gpu_mem=256 to gpu_mem=16

sudo reboot


cd mamepi

Yes! that did it, it’s going again. Let’s leave it until tomorrow morning.


Fail! Looks like it compiled ok but failed to link

sudo nano /etc/dphys-swapfile

Change CONF_SWAPSIZE=100 to CONF_SWAPSIZE=2048 (The maximum). Now this is going to be in /var/swap and if you are using an SD card, that’s not good, don’t forget to change it back after you are done or you can dramatically shorten the life of your SD card.

sudo reboot


cd mamepi

Success! It worked! So first the good news, it works. Sound, controller config, every game I tried, all worked.

Now the bad. It’s slow. I was expecting that but wow! even invaders and puckman didn’t run full speed. With overlays and artwork turned on they were unplayable even with auto frameskip. Turning off the artwork stuff and some games are playable if auto frameskip is enabled. adding -sr 11025 to the command line improves a few of the older games and -mt didn’t seem to have any appreciable effect at all.

OK here are the screenshots I took while testing:



Space Invaders – 77%

Space invaders is slow but it’s playable with frameskip on.



Puckman – 92%

Puckman is almost fast enough to play without frameskip.



Gauntlet II – 29%

Gauntlet II is unplayable.



R-Type – 52%

R-Type is ok with frameskip on but its getting jerky.



R-Type Leo – 35%

R-Type Leo is unplayable.


And just for laughs…


Ridge Racer – 5%


Soul Caliber – 12%

As an exercise it was interesting and it was awesome seeing the Soul Caliber attract mode in slow motion on a $30 computer, but I haven’t ended up with some awesome new emulator for the Raspberry Pi2, sorry guys!

If you want to mess around with it for yourself and save a couple of days of compile time, here is the precompiled binary for MAME. You will still need to compile SDL2.0.4 and SDL2_ttf.


35 Responses

  1. Slippyblade says:

    I’d love to see this done with a different version. The past several iterations of MAME have been getting resource hungry and are obviously not intended to run on pocket comps like the Pi. I use .149 in all my cabs… May try doing this with that version and see how it goes.

    • Libretro currently has a few versions of MAME available, a couple of which are pretty playable on a Pi2. all of them are crippled by being quickly shoehorned into the libretro api, some have ARM optimizations for Pandora or Android. I’m currently playing with some older versions of the MAME code here too, I’ll add .149 to the list. Currently 0.139 appears to be too slow on a Pi to be usable, 0.078 appears to be pretty playable, 0.106 is on the edge.

  2. Thanks for posting this, I was about to try this same thing with MAME 0.167. I was wondering about a few things that might speed up MAME these things would mean modifying the code though:

    From the bottom of the website –

    “SDL by itself does not directly use OpenGL ES 2.0, you need to configure it properly from your code. OK, so you need to setup SDL in order to use OpenGL ES2, basically you need to use something like:


    window = SDL_CreateWindow(window_name, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED,
    window_width, window_height, SDL_WINDOW_SHOWN | SDL_WINDOW_OPENGL);

    You also need to link with the OpenGL ES 2.0 libraries and EGL, this is what I’ve used: -L /opt/vc/lib -lEGL -lGLESv2 -I /opt/vc/include/”

    Maybe that will speed up the Pi2’s graphics and MAME!

    The other thing I was thinking is getting MAME to use multithreading, as the Pi2 does have four cores…

    If I was better at C and compiling I’d give these a try myself…

    Also, one last thing, did you try set your Pi’2 GPU size back to 256meg
    example – Change gpu_mem=16 to gpu_mem=256 then reboot.


    • MAME does all it’s rendering on the Pi in software there is no HW rendering. even if there were the current version of SDL (2.0.3) doesn’t support the Pi’s graphics chip (2.0.4 does but it’s still beta). MAME uses OpenGL (not GLES) and the Pi’s hardware only supports GLES, OpenGL falls back to software rendering again so all the OpenGL code would need rewriting to use GLES and that would only help the newer 3D games not the old classics because they all draw in software, the only speed kick would be getting the framebuffer onto the screen so the improvement would be minimal.

      MAME does use multithreading for drivers that support it (there aren’t many) and it doesn’t help at all for drivers that don’t. It’s all about timing and emulation accuracy. MAMEDEV go for accuracy over speed because they assume eventually computers will be fast enough.

      Read this for more info on MAME speed problems:

      • Hi Steve,

        Thanks for the quick reply and thanks for the cool article. I found out there is an option to get MAME to compile a few games, so it should be a lot quicker test environment.

        I just installed the latest Rasbian Jessie and it comes with GCC 4.9 since you posted some great step by step instructions I think I’ll give it a shot.

        One thing I like about the latest MAME is that it seems to support multiple keyboards. I haven’t tried it yet on my Mac but the config file shows it. I’ve been playing some old games with my son and we were both using different keyboards hooked up to the Pi (running Mame4all). But if I pressed a key on my keyboard it would react as if my son pressed that key on his keyboard.

        Thanks again for the cool article, MAME & MESS rocks… Maybe we have to wait for the RPi 3 to play some of the old classics and have some old computers emulated (old CoCo nut here).


  3. Hi again Steve,

    I thought I’d post a comment on some fantastic progress (or find) I made so far.

    I followed everything you did above on my new Raspian Jessie install on my Rpi2 (over clocked to 900 MHz) except I used MAME0167 (the current latest release) and I only compiled a minimal set of games with the command:

    This compiled in about and hour and a half (less games to compile)

    Once it was complete I tested the game circus using the HDMI cable for Video and Audio to 1080p monitor with the command:
    ./mametiny circus
    It was super slow, (exiting said 10%) which would be 3fps similar to your results above. So I looked through the SDL PERFORMACE OPTIONS (at the bottom of the mame -showusage) and noticed the -scalemode and tried it with:
    ./mametiny circus -scalemode hwblit

    The MAME openning screen (which tells you about the game) was blurry, but when I hit OK on the keyboard the game started playing fullscreen as clear as before but this time playback speed was 100%!!

    The only other game I had the roms for that was in the “tiny” list was called crash. I tried that game with the -scalemode hwblit option and it also played back at 100%

    I also tried -scalemode hwbest and it seemed the same as hwblit (also 100%)

    It sounds like you and I are after the same thing, to get the old classic arcade games working with the latest MAME. Since the resolution of the originalgames are so low, I think the RPi2 is able to do it. It will probably slow down trying to render games with higher resolution.

    With this success I will do a complete compile of MAME0167 and I’ll let you know how I make out. I’m hoping Pacman, Asteroids, Defender, Donkey Kong and other games around that time will play at 100% with this option.


    • Hi Steve,

      Here’s the update with the complete version of Mame 0.167 compiled on the Rpi 2 and overclocked at Medium 900Mhz

      All games had backgrounds/overlays turned off & run with the following command:
      ./mame -scalemode hwblit

      Game Speed Percentage
      1942 73.72
      arkanoid 100
      armora 47.78
      asteroid 78.38
      berzerk 100
      ckong 100
      defender 99.98
      galaga 100
      joust 100
      invaders 100
      mooncrst 90.99
      mpatrol 100
      phoenix 98.35
      puckman 100
      robotron 100
      scramble 69.63
      spacduel 59.08
      starcas 91.43

      Also successfully ran one computer emulation too:
      coco3 – TRS80 Color Computer 3 Emulated and running Game Dungeons of Dagorath 99.99%

  4. Pegaz says:

    Hi Nowhereman999,

    I’m very interested in this your progress, with the 0167 version of MAME.
    Could you compile the MESS in the same way and share with us.
    I would like to try some old computers (Acorn models for example) on Rpi2 but I’m not a Linux expert and do not know how to do it myself.

  5. Pegaz says:

    Hi Nowhereman999,

    Thank you so much for this comprehensive guide, I will certainly try on Jessie.
    At the moment, I use my own customized retropie 3.0 package based on Raspbian Wheezy and when I try to install, it tells me that I do not have gcc 4.9, which obviously exists on Jessie.
    Is there a way to compile MAME / MESS 0167 to Raspbian Wheezy and how to install gcc 4.9 on it?
    I tried to do it by using one instruction from the Internet, but it tells me that my version 4.8 is the latest and that it can not find version 4.9 and I stuck there.
    The primary reason why I want to try your version, the higher speed and improved compatibility Acorn emulation since version 0164, which is shared by Steve.

    • nowhereman999 says:

      A cool thing about the raspberry Pi is you can backup the current configuration by putting the microsd card in you pic and do a backup as an image. Then you can copy the latest Debian and follow my instructions.

      Or you can simply buy another microsd card and swap them I your Pi as a manual dual boot.

  6. Pegaz says:

    In the meantime, I started Steve precompiled Mess binary, but even with -hwblit switch I can not acheive full 100% speed with various old computers.
    Is there a way, in options or something else, which would speed up the emulator, at least for another 15-20%?
    Are older versions of Mame / Mess are less demanding?
    Have you compared speed betwen 0167 and 0164 version, when both used -hwblit option?

    • nowhereman999 says:

      Hi Pegaz,

      I think the only way to speed up you emulator is to overclock your raspberry PI. I haven’t done much testing of MAME or MESS. I did compile 0.167 of MAME without over clocking my Pi2, then I compiled 0.170 (just recently) and overclocked my Pi2 and the games ran 10% faster. I’ve only test the COCO3 emulation and it was 99% with 0.167 without over clocking, now of course with overclocking and 0.170 it is 100%.

      I know very old versions of MAME are less demanding and there is a very old version that is used by retropi. But I don’t know about old versions of MESS, and even how hard it is to compile for the Pi.

      I know it’s frustrating to be close to 100% but just not there… I think we are stuck with the speed of MAME unless the source code is modified to support multicore, even then I don’t know enough about the program to say how much it will help…


  7. Pegaz says:

    Hi Nowhereman999,

    Thanks for the answer, I agree with you.
    I will continue with mame.ini file, maybe I can get some speed-up.
    What overclock configurations you use?
    900 mhz is default for Rpi2, same as “Medium” for RPi1 and only latest option at 1000MHz is for Rpi2, but I dont know how much safe is?

  8. MAME 171 (released today) has initial support for BGFX ( a unified GPU backend which should see MAME able to use OpenGLES on the Raspberry Pi2 in hardware mode under SDL2.0.4. This might give a small uptick in speed. I’ve put up an OS X version and I’ll be compiling a RPi version tomorrow (its late here now) so we shall see then. We also might get a small speed increase from enabling OpenGL hardware acceleration in the new linux kernel for the Rpi. We really are pushing the hardware to it’s limits with this and I’m hopeful that MAME will become more usable in the near future when a Raspberry Pi3 is released.

  9. Pegaz says:

    Hi Steve,
    Thank you so much for that.
    Can you please make MESS binary too, I am really struggling to do it.

  10. Pegaz says:

    I tried to be helpful and compile an older mess version, according to the first comment from sleepyblade.
    I downloaded source from here:
    Unpacked and tried the same procedure with which Steve and Glen have managed to compile 0164 and 0167.
    Unfortunately, after the first MAKE command I received an error message:
    src/osd/sdl.mak:497: ***Qt’s Meta Object Compiler (moc) wasn’t found!. Stop.
    When I try to instal libqt5 packages it gives me message E: unable to locate package libqt5
    Any help?

  11. nowhereman999 says:

    I think you need to add these for libqt5 libraries to compile:
    sudo apt-get install libqt5widgets5
    sudo apt-get install libqt5qml*
    sudo apt-get install libqt5open*

    I hope that helps…

  12. Pegaz says:

    Thanks, I finally made it with fresh Jessie instalation to compile mame 0170, but when I tried to compile latest 0171 it fails with drawbgfx error, I dont know why.
    Also I still struggling to compile mess instalation older than 0162, which exist as separate builds.
    Id like to compile version 0149, mentioned in first comment here, but always get a bunch of errors at begining of process.
    I also compared speed between 0170 and 0164 and thre is no much diferencies betwen them.
    Thats why I like to try 0149 version, to find out how much is faster than newer versions.
    Is it even possible to compile mess 0149 on RPi2 and if anyone knows how?

    • nowhereman999 says:

      Hi Pegz, I’m no C compiling expert myself, I’m fighting with compiling 0171 right now. I’ve had some progress by using this command (fixed a moc error)
      sudo apt-get install qt5-default

      I think compiling the bgfx stuff it needs X11 (Desktop GUI) so I’m trying to compile with:
      make -j 4 NOWERROR=1 SUBTARGET=tiny NO_OPENGL=1

      I’ll probably update my blog, if I get this figured out.

      I can’t help with mess 0149 on RPI, as I said I’m no expert…

      Good luck

      • BGFX needs X11 and OpenGL; compiling without either should work but I’m getting the drawbgfx error as well. I’m still looking into that.

        • nowhereman999 says:

          Hi Steve,

          if you want to compile without BGFX you can use the compile option USE_BGFX=0 but then you loose the benefits of the more advanced rendering of BGFX. It will be just an updated version of 0.170 mame. I’ve started compiling on a new install of Raspbian with the Desktop GUI and X11 with BGFX and X11 enabled. I’ll report how I make out.


          • Adding USE_BGFX=0 as a compile option should work (at least it looked to me like it should when I went through the makefile) but it doesn’t, the compile just fails with an invalid option USE_BGFX error part way through.

            The makefile for bgfx contains lines specifically for the rpi so it should work, hence my confusion. I’m still digging through, it’s slow going on a pi

        • wow! what I wrote there is rubbish! lol please ignore that… brain fart!

    • adding TARGET=mess to your make line will give you a mess build but theres no need if you build without a target you get mame and mess combined

      • nowhereman999 says:

        Hi Steve, You probably know it already but I just wanted to make sure you are compiling on the RPI with the -j4 option, it’s 4 times faster (using all four cores of the RPI 2). It’s so important when compiling MAME which is a monster… Even with SUBTARGET=tiny it’s a half hour compile. Brain farts happen to me all the time. 🙂 Cheers.

      • Pegaz says:

        I try this with 0170, but always gives me error make: *** No rule to make target ‘scripts/target/mess/mess.lua’ …
        When I add SUBTARGET=mess, compile works trough the end, but it takes loooong time.

        Much more troubling me mess version 0149, which constantly report some problem with Qt librarry, eaven I installed the following things:

        sudo apt-get install libqt5widgets5
        sudo apt-get install libqt5qml*
        sudo apt-get install libqt5open*
        sudo apt-get install qt5-default

        • Yes, sorry, I meant SUBTARGET

        • OK I got 171 to compile, not a clean compile I had to retry fixing as I went so I’ve just run make clean and started again, it should be good this time.

          you need to

          sudo apt-get install libxinerama-dev

          I dont exclude x11 or opengl, I don’t even nowerror=1

          I just ran “sudo make -j 4”

          I’m doing it again now without sudo *fingers crossed*

      • Pegaz says:

        Good news Steve, I hope you made it…

  13. James BD594 says:

    Has any one attempted this with a Raspberry PI 3?

  1. November 14, 2015

    […] used the help from Steve Boswell and his site listed here and some good compiling info for the Raspberry Pi here and more specifically SDL2 on a Raspberry […]

  2. February 29, 2016

    […] the help of Steve Boswell and his site located here and some good compiling info for the Raspberry Pi here and more specifically SDL2 on a Raspberry […]