I left my previous post on the Pi at the point where I had SDL with DirectFB installed and tried to run the fuse zx emulator (no X11). It took me a week to understand that that wasn’t working. Although I’ve used Gentoo Linux for some 10 years now, I had never played with framebuffers before, so it was an honest mistake.

For reasons I’m not aware, the fuse emulator (compiled both manually and through portage) would seg fault. I could see some DirectFB messages, a screen popped up and then blank. The thing is that I had been able to get some simple SDL demos to display something on the screen, so I figured that the plan (SDL/DirectFB) worked. I tried almost everything, having debug messages for DirectFB, setting up some parameters, nothing worked. At that point my only guess was that there was something wrong with the fuse binary and/or gcc and friends. So, I thought that maybe changing CHOST from armv6l-hardfloat-linux-gnueabi to armv6zk-hardfloat-linux-gnueabi could make a difference.

2 days later (compiled gcc, binutils and glibc with no help from distcc), I was back at square 1: Seg faults with fuse… I switched SDL to use the fbcon backend and everything worked. :headbang:

I did try fbcon before even DirectFB, but when tried fuse as a regular user, it would not start. Neither would my test SDL demos. The problem with that was eventually the mice permissions that gpm sets up. A simple hack to get this over with is changing /etc/init.d/gpm start() block to ‘fix’ the permissions at start:

start() {
        checkconfig || return 1

        local params=""
        [ -n "$RESPONSIVENESS" ] && params="$params -r $RESPONSIVENESS"
        [ -n "$REPEAT_TYPE" ]    && params="$params -R$REPEAT_TYPE"
        [ -n "$APPEND" ]         && params="$params $APPEND "

        ebegin "Starting gpm"
        start-stop-daemon --start --quiet --exec /usr/sbin/gpm \
                -- -m ${MOUSEDEV} -t ${MOUSE} ${params}

        chmod 0666 ${MOUSEDEV}

        eend ${?}
}

There must be a better way to do this, but anyway.

So, with fbcon SDL backend, fuse at last started up. It worked flawlesly and fast. But to reach my peak of hapiness with this little thing, I needed to see full screen the love of my childhood: The Amstrad CPC 6128’s blue background and yellow letters.

There are a few Amstrad emulators (almost none in portage which is a shame), and after some tries, I settled on Caprice32. It compiles with no changes, works beautifully, but it does need the Pi to run at 900Mhz to reach 100% speed. I’m guessing some optimizing even with just compile flags will be ok to have it run 100% on lower frequency, but I can’t be bothered with that now. One small note if you try it yourself: Edit cap32.cfg and make sure you set scr_bpp=16. Tried a couple of games (like Robocop), works great!

Next stop was ScummVM. Go ahead, just emerge it. I can’t believe how well this runs. No comment.

C64 is a different story. Vice won’t compile, at least through portage. To be honest it’s not my favourite C64 emulator, so I tried Frodo. It compiles manually, but this one I think needs some hacking. Colors are messed up (8 bit SDL maybe?) needs to be slowed down (done through .frodorc). We’ll see.

But, the holly grail for me is the Amiga… There are ports of UAE4All for Arm chips, but I’m not sure how well they work. Will most likely give it a try at least.

Have I mentioned that all of the above run with sound enabled? If you’re on Gentoo, just add this to /etc/conf.d/modules to load the alsa broadcom module:

modules="snd_bcm2835"

at the end of the file. Remember to emerge alsa-utils and stuff. Up the alsamixer volumes, and you’re set.

Here’s a video of the above in action. Sorry for the weird angle :-)

Back to posts