Run SDLMAME/SDLMESS on a Framebuffer Device

Since I tend to forget things once they are solved I decided to write a short primer on how to run sdlmame on a hardware accelerated framebuffer device supporting YUV-overlays. This is really not a trivial task and this document only covers the last steps in detail.

This is nothing for the faint at heart. It is dangerous. Your computer may crash. You may lose data.

Please take this warning serious. You are in root's realm and executing low level drivers.


There are a couple of things you need before the steps outlined below will actually work:

Working Framebuffer Device

A working framebuffer device (i.e. /dev/fb0) largely depends on your distribution. The first obstacle in my case was persuading ubuntu to load the radeonfb driver at boot. It involved messing around with initramfs-tools and modifying scripts - only to find out that my R480 based card was not supported. On the net I found a patch for a later kernel which I had to modify for the stock 2.6.20 ubuntu-feisty kernel. For gutsy, the situation has not improved. Still the same driver issues - no r480 support - and consequently modifications.

SDL Library with a Modified directfb Driver

The stock sdl 1.2.11 directfb driver simply did not work with my radeon card. I could not get YUV-overlays to work although they are supported in the code. I would guess the reason is that it has not seen attention for a while. Consequently I started work on an enhanced directfb driver a while ago. It is now kindly hosted at Arbee's WIP Emporium » SDLHome x.y.z.

In order to install a modified SDL library, you have to replace the directfb driver source with the modified one. On ubuntu you would do the following:

core:/tmp$ apt-get source libsdl1.2debian
core:/tmp$ wget -U firefox
core:/tmp$ cd libsdl1.2-1.2.11/
core:/tmp/libsdl1.2-1.2.11$ tar xfz ../directfb.tar.gz 
core:/tmp/libsdl1.2-1.2.11$ dch -i DirectFB Replacement
core:/tmp/libsdl1.2-1.2.11$ debuild -us -uc

The Ubuntu edgy/feisty developers did a nice job here since no further package configuration was necessary.

Finally you need install the package as root:

core:/libsdl1.2-1.2.11$ sudo dpkg -i ../libsdl1.2debian-alsa_1.2.11-7ubuntu2_amd64.deb

Other distributions may require more work or basic ./configure; make; make install with appropriate configure tweaking. If you are putting together an X-less system, –without-x –disable-video-x11 will be your friends.

Basic Setup

Still here? Good. You should now have a framebuffer device:

core:~$ cat /proc/fb
0 ATI Radeon ]O 
core:~$ ls -l /dev/fb0 
crw-rw---- 1 root video 29, 0 2007-07-20 19:59 /dev/fb0

If this is not the case, try

core:~$ sudo modprobe fbcon
core:~$ sudo modprobe radeonfb # for radeon cards

dfbinfo should contain something like the following:

Screen (00) FBDev Primary Screen            (primary screen)

     Layer (00) FBDev Primary Layer             (primary layer)
        Type:    GRAPHICS 

     Layer (01) Radeon CRTC1's Overlay        

Layer (01) is important. If this layer does not exist or does not support “VIDEO” type there is no chance for hardware accelerated YUV overlays. We now need the following lines in /etc/directfbrc:


The last two lines will make sure that joysticks work. The first two lines define the “startup” video mode. You should have a corresponding entry in /etc/fb.modes. Now is the time: Execute the following as root.

You are now acting on your own and declared will. All sorts of strange things may happen - including loosing all your data!

export SDL_VIDEODRIVER=directfb
mamepm -video soft -scalemode yuy2 -verbose galaga

If everything worked a game like galaga will show a performance of 250 to 300% in comparison to ”-video soft”.

I was able to get this to work on the following platforms:

  • Ubuntu edgy/feisty with neomagic (neofb) framebuffer
  • Ubuntu feisty with radeonfb framebuffer
  • Ubuntu gutsy with radeonfb framebuffer

Finally here is a screenshot of what you will get:

DirectFB does not support taking screenshots of YUV overlays. The screenshot is therefore taken with ”-video soft -ym none”.


The procedure described above should work for stock sdlmess/sdlmame. If you intend to set up a system without X, you have to compile sdlmess and sdlmame with the following command:

make NO_X11=1 NO_OPENGL=1

This will compile a binary with support only for software rendering and yuv-overlays.