Category Archives: Raspberry Pi

Pi Emulators Now Work Again!

Posted on by
2

Or they should do, at least…

rpi2-1

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:

http://www.gcat.org.uk/emul/

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!).

 

Review: Raspberry Pi Case

Posted on by
Reply

I’ve been enjoying playing with the Raspberry Pi again lately. One of the Pi’s more unusual features is that it comes as a bare circuit board with no case, both to keep the price down at the $35 mark, and so that people can choose (or build) their own cases. So far, my Pi board has mostly just been lying on the carpet under my desk, in amongst the tangle of cables going to and from my main computer, TV, music keyboard and various peripherals. It seems happy enough down there, but there’s always a slight worry in the back of my mind that it’s going to get trodden on (it’s already endured one of Laura’s folders falling on it), zapped by static electricity, or that I’m going to damage something when I hold it to unplug one of the cables.

But not anymore… Gearzap have sent me a Raspberry Pi case to review!

The case arrived quickly, in a padded envelope for protection. The Pi slots into it nice and easily and fits snugly once it’s closed. The lid is easy to prise open, but all the Pi’s main ports and the SD card slot are easily accessible through the pre-cut holes in the sides so I probably won’t need to open it very often. The case is all plastic so it removes the danger of anything getting static zapped, or metal accidentally touching the board and causing a short circuit. Inserting and removing the tighter fitting connectors (especially the micro USB power plug) feels a lot safer now that I can grip onto the box rather than risking crushing a capacitor or stabbing myself on the GPIO pins.

In addition to the holes for the ports, there are various ventilation holes (although the Pi generates very little heat compared to most electronic devices). And there’s these:

A common complaint about the original Raspberry Pi board design was that it had no mounting holes, making it difficult to securely attach the Pi to something, which you may want to do if you’re building it into a larger project, or even just to stop it being pulled all over the place by its cables. The ModMyPi case remedies this by including its own mounting holes, making it easy to screw the Pi onto whatever you please. (The new Revision 2 Pi boards do have mounting holes, but there are a lot of revision 1 boards like mine already out there so it’s a useful feature in a case). But if you just want to sit the case on a desk, there are four little sticky rubber feet supplied that help stop it from sliding about and keep the bottom air vent open.

One possible downside is that the case makes it harder to get at the GPIO pins and to see the status LEDs. However, this is unlikely to be a huge problem in practise; the GPIO pins are mainly only useful to people who want to interface their Pi to custom electronics, something probably only a minority of users will ever do (I haven’t tried it yet myself, but would like to when I get the time). Even then, it would be easy enough to run wires to the GPIOs through one of the pre-cut openings in the case. As for the LEDs, they’re only really useful for troubleshooting when something goes wrong, which hopefully is rare enough that having to pop the case open won’t get annoying. There are slots right above the LEDs, so you can still see at a glance whether the Pi is powered up or not, which is the only thing I normally use them for.

The box seems quite well designed and built. There are no obvious weak bits that look likely to break off, and it still closes nice and firmly even after me fiddling with it quite a lot.

It also goes quite nicely with the external battery pack I’ve been using:

So if you’re looking for a Pi case, this seems like a very good option :).

 

Pi Emulators Update

Posted on by
3

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

Posted on by
15

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 😀 ).

It’s Pi-day :D

Posted on by
1

GCat’s adventures with a credit card-sized computer.

It’s months now since I blogged about the Raspberry Pi. At the time I said I was getting really excited about it. Well, my excitement did start to wane a bit after getting up at 5.45am on the release day (February 29th) only to find the level of interest had practically melted the servers of both supplying companies and there was very little chance of getting hold of one any time soon. I was still intending to buy one when some of the mayhem had died down, but I hadn’t given it so much thought lately. Then suddenly yesterday one of my colleagues walked into my office without any warning and handed one to me!

I couldn’t wait to give it a try. Unfortunately I didn’t have a screen in the office that it could hook up to immediately (it needs HDMI or composite, VGA or DVI monitor plugs are no use) so all I could do was download the software ready to try it out (it needs a custom version of Linux on an SD card) while casting occasional excited glances at the box. But luckily there’s a nice HDMI TV in my living room…

My first reaction was: wow, this thing really is tiny! I mean, I knew it was credit card-sized and all, but even so, it’s still hard to believe just how small it is until you see one in the flesh, so to speak. I was even more amazed by the size of the main processor (the black square chip just by my fingernail in the photo and about the same size!).

Hooking everything up to it reminded me of connecting up one of our old computers and brought back happy memories of geekily spent Christmases and so on. In the picture, the power is coming from my HTC phone charger and going into the micro USB connector on the lower left corner. The SD card with the Linux OS is the blue thing protruding out from underneath the board just by the power connector. The grey plug going into the near side is the HDMI cable to my television. The green cable coiling round the whole thing is ethernet to connect it to the internet (it doesn’t have built in wifi so it needs either a cable connection or an external USB wifi dongle). Finally, the two black plugs next to the ethernet are my ordinary USB keyboard and mouse.

With trepidation, I double checked all the connections and then turned the power on. Would it work? I’d seen reports that certain SD cards wouldn’t work properly so I knew there was a chance I’d got a bad one or that I’d messed up the OS install.

Success! I could see the raspberry logo on the screen and the Linux boot messages scrolling past (looking very tiny in full 1080p resolution). Soon I had the desktop environment running and was verifying that it was indeed capable of viewing pointless web pages.

It was pretty easy to get up and running by following the quick-start instructions on the Raspberry Pi website. It was a little bit sluggish for browsing the net, but that’s to be expected with such a low-powered machine with a chip designed for mobile phones but running a full desktop system. Apparently this will get better once X Windows (the software that provides the graphical user interface on Linux) is using the Raspberry Pi’s rather capable GPU to do most of the drawing instead of doing everything on the main processor as it is at present.

But nice though it was to see my blog on the big screen courtesy of the Pi, I was more interested in getting some of my own code up and running on it. After a quick break to redo the partitioning on the SD card (so that I could use the full 16GB of space rather than the default less than 2) and install my favourite geeky text editor, it was time to delve into the code examples.

As the Raspberry Pi is intended for teaching programming, it comes with some nice example programs showing how to make it do various things (play video, play sound, display 3D graphics, etc.). I’d decided for my first project I was going to try and get one of my emulators up and running on it; the architecture is actually very similar to my phone’s so even though the emulators contain quite a lot of assembly language code that would have no chance of working on a normal PC, they should work on the Pi without too much trouble. I decided to start with the Master System one as it’s a bit simpler than the others.

After an hour or two of hacking, I had something working.

As expected I didn’t need to change very much in the code. I just replaced the “top layer” that previously communicated with the Android operating system with a new bit of code to send the graphics to the Raspberry Pi GPU via OpenGL ES. (Although that’s mainly for 3D graphics, you can do some nice 2D graphics on it too if you more or less just ignore the third dimension).

The emulator isn’t fully working yet… there’s no sound (I need to look at the sound example that came with the Pi but it shouldn’t be too hard), no way to actually control it (that screenshot is just showing the demo running on its own – I need to figure out how to get key presses in the right form), and there are a few other glitches (the graphics seem to extend slightly off the edges of the screen and the timing is a bit off). But overall I’m reasonably pleased with my first few hours with a Pi 🙂

Update: the Master System emulator is now closer to being finished and you can download it from here.

Raspberry Pi!

Posted on by
Reply

I have to admit I’m getting really excited waiting for this to be released…

This pic from the official site, not taken or owned by me... if there's a problem with me using it, let me know and I'll take it down!

It’s a tiny little credit card sized computer, designed for teaching kids programming. Despite not being a kid (well, not physically anyway) and already knowing how to program, I want one.

Or several… they’re only going to cost 25USD for the basic Model A or 35USD for the slightly more powerful Model B. But despite the ridiculously small size and price they are capable of playing full HD video, which is more than my netbook can manage. This is made possible by the fact that the Raspberry Pi is using a mobile phone processor rather than a normal PC processor. (The main processor core, an ARM11, is very similar to the chip in my HTC Wildfire, but the one in the Pi runs a bit faster and is coupled with a very powerful graphics processor to handle video decoding and 3D acceleration).

The idea of it, a simple little machine that plugs into a TV and is easy to write your own programs for, takes me back to the old home computers of the 80s and early 90s that I first learned to code on. I did most of my learning on a ZX Spectrum +3, which is probably still in the wardrobe somewhere along with a BBC Micro Model B+ that I acquired a bit later. They were laughably primitive machines by any sort of modern standard, but I miss the simplicity and accessibility of them. You could turn them on and immediately start writing a program, and if you were curious there was plenty of information out there that would let you learn how the machine worked inside out.

The Raspberry Pi won’t be quite the same as that. It will still run a modern operating system (some form of Linux; Windows won’t play well on hardware like this) and elements of it, especially the graphics chip, will be too complex for most people to learn fully. But it seems like it will be a fairly large step in that direction. The Model A and Model B naming, in fact, is a nod to the first two versions of the old BBC Micro.

Normally when I want something like this, I’d probably buy one eventually, but have nagging doubts at the back of my mind. “You’re already working with computers all day”, they would say. “Why do you want to spend your free time hunched in front of a screen playing with code as well when you could be enjoying so many of life’s other rich pleasures instead?”. “But I want toooo… it’s fuuuun….”, another voice would argue back in the tone of a whining five-year-old.

This time, though, I’ve neatly side-stepped that whole dilemma by offering to supervise a project at work involving Raspberry Pis. So I can legitimately play with, um, create something valuable and useful with them in work time and even get paid to do it. Yay!

Can’t wait for the release date… which is hopefully January 2012 :). Next problem is how to actually get hold of one… seems I’m far from the only person to be disproportionately excited about this, and I wouldn’t be surprised if the first batch sells out pretty quickly.