RetroPi – Part Two: The OS

So, in part one I described our intentions and what we want to achieve. In this part I will go though how we chose an OS for our Pi, and why we chose it.

tl;dr: We chose to use Raspbian because it’s quick-and-easy to set-up, there is a stable release and it is well supported and widely used.


Having used the Pi for media streaming and generally messing around before, we have some Pi XP. Additionally we have used many other distributions such as Gentoo, Sabayon, Ubuntu, Debian etc., etc.

The Pi Download page is a good start when choosing an OS.

Attempt 1

We grabbed an Arch image, threw it on an SD card and booted the Pi. We then spent some time configuring the window manager, spent some more time sorting out the usual stuff one does on a new install: networking, locale, NTP, etc. Nothing special here.

Attempt 2

After doing all this, we realized I made a mistake, somewhere along the line something went wrong and the Pi thought the 8 GB SD card was only 2 GB. A fresh install was required. I couldn’t be bothered to do it all again, so instead I changed to Raspbian, just to try something new.

The next hour was delightful, Raspbian uses a tool called raspi-config. Here you can easily configure all of the stuff above, including memory management, overscan, SSH, boot behaviour, package updating and more.

Once that was complete the Pi now booted straight to a GUI and was ready to go.

So Why Rasbian?

I’m not at all ashamed to admit that we stuck with Rasbian because it was easy. I have played with a few OSes in my time, and often enjoy the wars I get in with Gentoo’s package manager, however now we have some focus for the project, and some goals we want to hit. It seems only sensible that we choose an OS that does a lot of the necessary but ‘boring’ work for us. Along with this, we know that Rasbian will always have a stable release and they have a bunch of packages available to boot.


Anything. I don’t think our project really holds any limitations that would lock us in to any distribution. I’m confident that if we had the time, patience and will we could complete this project using /any/ distribution of GNU/Linux. We chose the one that worked quickly, and the only small annoyance is I have to get used to using apt-get install. Fine.

Woo a working Pi. \o/

RetroPi – Part One: The Plan

As the Rasberry Pi has been out for a while now, we thought that it’s probably about time we did something constructive with it.

tl;dr: We are going to use the Raspberry Pi to make an all-in-one games console emulator supporting multiple platforms, games and input devices.

Raspberry Pi?

For those who don’t follow the release of small, open source, cheap computer news the Pi is a small, open source, cheap computer. It’s the size of a credit card, it runs the Linux kernel and there are a few supported GNU/Linux distributions supported (along with a few others that people have got working but are not officially supported e.g. Gentoo.

What can the Pi do?

The Pi, so far, has been used in various projects mainly created by individuals that are just having some fun (IMO the main reason to own a Pi). The Pi has been used to take photos while High Altitude Ballooning, as a retro arcade-coffee-table, these guys made a Raspberry Pi Super Computer and there are probably 100s of other things I’ve missed and/or don’t know about.

What’s the Plan for us?

Inspired by the coffee-table-arcade, we want to make some form of gaming Pi. The initial plan was to support as many controllers, platforms and games as possible. NES, SNES, GB and GBA, MAME and what ever else we could get working. 1. Support as many platforms, controllers and games as possible.

The key for me, is to create something that does away with the fiddly process of getting an emulator to run, to get ROMs to run on those emulators and finally trying to hack together some form of support for a joypad or other controller. 2. Make configuration easy. We will design and develop an interface for our arcade. Through this interface one should be able to choose a game (perhaps using a default emulator), choose which emulator to run that game (perhaps certain games run differently with different emulators) and quickly and easily configure any USB controller that one throws at it. All of these things will be persistent, so when we play again, settings are saved, configuration is ready, and the user’s choice of emulators and games is remembered or accessible in some way. 3. Make a user friendly interface.

What will this entail?

Firstly we need to install an OS on the Pi. Which is the best for the job? I don’t know.

We have found RetroArch, it’s a modular, multi-system emulator that contains features similar to many other emulators. It’s exactly what we need, it’s open-source and it’s already been forked for use on the Pi.

Compiling. Compiling takes time; time, CPU power and memory. The Pi is a bit short in this department, so we are going to discover the world of cross compiling.

Programming on the Pi. We want to create a good front-end for our RetroPi. We want it to be controllable from keyboard and mouse or any of the controllers that we will support. It should allow us to easily play games, to change configuration options, and allow us to utilize features of an emulator like quick-save, speed options, etc etc. We plan to create this from scratch ourselves, using some programming language. It seems that python is all the rage on the Pi, but we might choose C++ as it has numerous GUI libraries that we can cheat with.

What next?

If we get this far, then awesome. We’ll probably end up getting drunk and playing a lot of old games. We may choose to mount the whole thing in a coffee table, we may choose to create a package so that others can share and develop the idea further or we may just give up and move on.

What’s first?

First thing’s first is getting one game working on the Pi, for one emulator with any input device. This will involve choosing the OS and installing RetroArch.

Wish us luck.