Pi Emulators Now Work Again!

Or they should do, at least…


Whenever I start getting comments and emails rolling in about compilation problems, I always know a new version of Raspbian must have been released, complete with the seemingly-obligatory moving around of libraries and header files ;). I’ve updated the Makefiles to deal with this, so if you were having problems, please head on over to my emulator download page and grab the latest version of the source:


As always, please let me know if you have any problems, but hopefully it should work now (at least until the next distro update moves things again!).


Android Emulators Update

I just made a minor update to my Android emulators for 8-bit machines (the Raspberry Pi versions have not been changed). Since I updated my HTC One X to Android 4.1.1, the sound in all three of the emulators had been really horrible and distorted (yes, even more so than usual πŸ˜‰ ). So it seemed a good time to update them to use 16-bit sound output, which seems to be better supported in Android. It turns out that 8-bit samples, which I was using before, aren’t actually guaranteed to work at all on every device, so this change would have been worth making even without the sudden appearance of the distortion.

Nothing else has changed except that they’re now being built with a newer version of the Android SDK; however, they should still work on all devices back to Android 2.1, and indeed they do still work on my old Wildfire. Please let me know if you encounter any problems.

Much as I like Android and Google and HTC in some ways, they do seem to like changing things that worked perfectly well already, and not always for the better. Almost every system update for my phone seems to turn into a fresh game of hunt-the-process-that’s-draining-the-whole-battery-and-guess-how-to-make-it-stop… including the ones that claim to improve battery life. And the latest update not only broke 8-bit sound, the phone also refuses point blank to talk to my desktop PC anymore, either as a USB disk drive or for app debugging purposes – both worked fine before. Ah well… got to keep the users and developers on their toes, I guess.


Pi Emulators Update

I’ve had a few emails and comments over the past months about my Raspberry Pi emulators… mostly noting that they won’t compile on the new Raspbian OS that was released for the Pi last month. Finally, after being busy travelling the world and working on other projects for a while, I had some time to look into this :).

(Well actually, I did look into it a couple of weeks ago. I fixed the compilation issue in a few minutes as it was mostly just a case of libraries moving to slightly different locations… but then when I tested Tetris on the Gameboy one, it stubbornly failed to run, just freezing up on a white screen. I could play Mario and Sonic fine, none of the other games had problems. Only Tetris. I couldn’t understand how on earth such a subtle change to the build process could have broken one game and left all the others unaffected, so I suspected this was going to be a long drawn out and annoying thing to debug and put it aside for a while. Today I had psyched myself up ready to dive in, but before I started I had a thought: what if my Tetris ROM file got corrupted when I copied it to my shiny new Raspbian SD card? Not very likely, but worth ruling out anyway. Bingo! After copying the ROM again, it worked fine. No subtle bug after all. I could have released this update weeks ago. Sorry).

So… updated versions that should build on Raspbian are now up on the emulators page. The Raspbian-compatible Makefile is now the default one, but the old one is still there as Makefile.squeeze just in case anyone wants it. You may also need to change to the ilclient directory (/opt/vc/src/hello_pi/libs/ilclient) and run “make” in there to build it before you can build the emulators for the first time, as it’s distributed as source code.

Nothing much else has changed… I tested my Pi with composite video instead of HDMI and discovered that running the emulators with HDMI audio when HDMI’s not in use crashes them. So HDMI is no longer the default, the analogue port is the default and you need to pass ‘-h’ on the command line to use HDMI.

Enjoy :). I have something else in the pipeline that I’m hoping won’t take as long to materialise as this update did.


Second Helping of Pi

Unsurprisingly, I found a few spare hours this weekend to work more on the Raspberry Pi. (Though I was very restrained and didn’t work on it non-stop… did still go dancing one night and out for a walk to take some nice photos yesterday afternoon. I know what it does to my mood if I spend a whole weekend cooped up coding, even if I am tempted to at the time).

First I finished up the Master System emulator. I added in a border to stop the graphics going off the edge of the screen, then turned my attention to the more challenging requirements: keyboard input, sound, and timing.

Getting input from the keyboard isn’t usually a particularly challenging thing to do… not for most programs, anyway. But for console emulators it’s a bit more involved, for two reasons:

  • we want to be able to detect when a key is released, as well as when it’s pressed
  • we want to be able to detect multiple keys being pressed at once (for example, the right arrow and the jump key)

I tried various ways of doing this – firstly, the way I used in emulators I’d written for Windows previously: the SDL library (this library can do lots of handy things and keyboard input is only one of them). But although the library was installed on the Raspberry Pi and I was able to link to it, I couldn’t detect any keyboard activity with it. Eventually I found out you can perform some arcane Linux system calls to switch the keyboard into a different mode where it will give you the information I needed. This only works from the real command line, not from X Windows, but it was better than nothing. (You also have to be very careful to switch the keyboard back to its normal mode when your program exits, otherwise the computer will be stuck in a strange state where none of the keys do what they’re supposed to do, with probably no way out other than turning it off and on again!). I still want to find a way to make it work in X Windows, but that’s a project for another day.

(I wrote a more technical blog post here about the keyboard code in case anyone wants to use it).

While reading the keyboard turned out to be a bit harder than I’d hoped, this was more than made up for by how easy it was to get the sound working. In fact I found I was able to re-use most of the code from the audio playing example program that came with the Pi. The only slight strangeness was that it seems to only support 16 or 32 bits per sample rather than the more standard 8 or 16, but it’s easy enough to convert the 8 bit samples generated by my Master System sound code to 16 bit. I didn’t know whether the Pi was expecting signed or unsigned samples, but the din of horribly distorted noise that greeted me the first time I tested the emulator with sound confirmed that it was the opposite of whatever I was giving it. That was easy enough to fix too.

As for the timing, it turned out to be a non-issue – the sound playing code will block until it’s ready for the next batch of sound data anyway, so this will keep the emulation running at the correct speed. (Actually it’s a non-issue for another reason as well, but I’ll get to that later).

(It’s amazing how enormous the pixels look now. I’m sure they never did when I was playing with a real Master System on a telly almost as big back in the 90s. I suspect it was just the general blurriness of TVs back then that masked how low resolution the graphics really are).

Since my first Raspberry Pi emulator had been easier than expected, I decided to port another one – my Android Gameboy emulator should be do-able by welding the head of Raspberry Pi-specific code I’d just written for the Master System one onto the body of behind-the-scenes code from the original Android version of the Gameboy and making a few important tweaks to make them look as if they match up. So that was what I did.

“This’ll be a breeze”, I smugly thought. “I’ll be done in a few minutes!”. But it wasn’t quite that easy…

I was mostly done in a few minutes (well, maybe half an hour) – graphics were working and I could play Tetris or Mario. But the sound was horrible. Really horrible. Not just normal-Gameboy-music level of horrible… something was clearly very wrong with it. I checked and double checked the code over and over but still couldn’t see the bug. I hadn’t changed the sound output code very much from the Master System, apart from changing the sample rate slightly and switching from mono to stereo. I switched back to mono again. No change. I tried a more standard sample rate (22050Hz instead of 18480Hz). Nope, now it’s horrible and completely the wrong pitch.

I puzzled over this one for a long time. I tried various other things I could think of, rewriting the code in different and increasingly unlikely ways, but nothing seemed to make a difference. The only thing I established was that the sound buffer was either not being completely filled or was underflowing – when I tried filling it with a constant value instead of the Gameboy’s sound output, I still got the horrible noise (a constant value should give silence). But why??

Eventually I cracked it, and learnt something in the process. I noticed that Mario seemed to be running a little bit slower than it should, and I wondered if the emulator was not actually running fast enough to process a frame before the sound buffer ran out. That would certainly explain the sound problem… but didn’t seem like it should be happening. The same emulator code had no trouble reaching full speed on my slower HTC Wildfire, it should be no problem for the Pi to manage it as well. On a hunch, I tried reducing the sound sample rate quite a lot. Finally a change! Sure, the game was running slower and the music was now sounding like a tape recorder with a dying battery… but for the first time the horrible noise was gone! Then I had a thought: what if the graphics code is locking to the frame rate of the TV? The Gameboy screen updates at 60Hz, but UK TVs only update at 50Hz. Trying to display 60 frames in a second when each frame is waiting one-fiftieth of a second is not likely to work very well. Sure enough, only outputting every second frame (so running at 30 frames per second instead of 60) cured the problem completely. It had never occurred to me that this could happen… I was so used to programming PCs, where the monitors have all run at 60Hz or more for decades, that I forgot the little Pi connected to my TV would be different.

Anyway… I decided to tidy up the code and release it in case it’s of interest to anyone. So if you head on over to my emulators page, you can now download the source code of both emulators for the Raspberry Pi along with detailed instructions for using them. Enjoy πŸ™‚

(A word of warning… I wouldn’t say they were examples of good programming practise. The CPU cores and graphics and sound rendering code are written in ARM assembly language, which I only did because I wanted to learn it at the time – C would be a better idea if you wanted to write an emulator that’s easy to maintain and extend, and probably would be fast enough to emulate the old 8-bit systems).

(Another word of warning… I have some more things in the pipeline that might be more interesting than these two πŸ˜€ ).

My Android Apps

I’ve had my Android phone about 18 months now. As the sort of person who likes to program everything that isn’t nailed down (starting from my dad’s ZX Spectrum and eventually progressing up to supercomputers) I just had to have a go at making some apps.

Android is good for coding your own apps, which is one of the reasons I chose it. For iPhone and iPad you need to use a Mac for development (which I don’t have and have no intention of getting) and you also have to either pay a developer fee of $99 per year or jailbreak your device. Even then you can’t test your code on anyone else’s phone unless they also pay the fee or jailbreak it. Thankfully Android is more accessible for programmers… you can just download a free software development kit for Windows, Mac or Linux and get started straight away.

Most of my apps are quite boring. There’s one that backs up all my contacts and text messages to a file and puts it in my Dropbox folder automatically. That was the first one I wrote and I’ve used it a lot ever since, though I improved it and added the Dropbox integration more recently. Another keeps track of my finances, and there’s one that allows me to access the task tracker I use (without which my life would probably be frighteningly close to unravelling completely) from my phone. But the most fun ones are the emulators.

Emulators are programs that make a computer behave like a different kind of computer. They let you run old programs on hardware that didn’t even exist when they were written. There are huge numbers of emulators out there allowing you to turn your PC into any kind of old, clunky computer or console imaginable. They’ve always interested me, partly because I like old computers for nostalgic reasons and partly because of the technical intricacy that goes into making emulators work. So since I started programming on the Spectrum and could still just about remember how it works inside out, it seemed fitting that I should code a Spectrum emulator for Android.

Here it is, running one of my favourite old games (Spellbound Dizzy) on my phone. I’m quite proud of it… I think it works rather well. (If your definition of “well” encompasses turning a cutting edge smartphone into an ancient, primitive computer, that is πŸ˜‰ ). It runs at full speed, which the other emulators I tested didn’t seem to quite manage on my slow-ish HTC Wildfire.

Then I decided that at this point it wouldn’t be too much work to make a Sega Master System emulator as well. I never owned a Master System (went straight from the Spectrum to Megadrive and our first PC) but I loved playing Sonic on other people’s whenever I got the chance.

It uses exactly the same main processor as the Spectrum and a lot of the other emulator code could be shared as well, so I got it up and running a lot quicker than the first one. The only hard bit was getting the Master System’s graphics working properly.

Finally (for now) I did a Gameboy emulator as well:

Tetris is even fiddlier to play with the controller on the touchscreen, though.

If you have an Android phone and feel like reliving the games of the early 90s, you can play with my emulators too. I put them online here (you will need to have the “Unknown sources” box ticked in your application settings to be able to install them). I’ve only tested them on two phones so far so it’s possible they won’t play well on all devices. If they don’t seem to work properly, please feel free to get in touch and I might be able to fix them, though I can’t promise anything. There are probably better emulators out there for all these machines, I really just made these ones for my own amusement.

(As well as installing the emulator app, you will need to put some games on your memory card. There are hundreds if not thousands of Spectrum games on World of Spectrum, which seems to be at least semi-legitimate. I don’t know of any legal sites for Gameboy and Master System ROMs but they’re pretty easy to find by googling anyway).

Have fun :).