Champaign-Urbana Community Fab Lab
Champaign-Urbana Community Fab Lab

The Emulation Station

Concept Emerges.

Our last assignment! This project is supposed to be reflective of what we learned about the design process this semester. We had tasks such as: story boarding, paper prototyping, iterative assessment, and more! The only catch for this assignment was that we had to use a medium/tool that we have never used before. In the past we have always been given or had the option to use tools that we have learned in class, so this was all new. At the beginning, we were given a sheet of possible tools to choose from. Upon scanning the sheet for the first time, I saw “raspberry pi” on the list and immediately snapped into wanting to make a video game console. I have seen this done in the past, so I knew it was possible. I just had literally no idea of how to approach making it. 

For the storyboard, it was simple. I wanted to make a portable device that could play games, play them well, and be able to have more than one players playing. 

Picture 1: Initial Storyboard

Little did I know, this idea was ambitious to the point of being impossible. To start off, the games I wanted to play (gamecube) proved to be fundamentally impossible for the pi to run. Many forum posters say it is due to the pi not having a 64-bit architecture like the gamecube does. This is false because I ended up running N64, “64” for 64-bit architecture, games pretty well. In short, the pi just does not have enough power to run the games making it literally impossible to make a custom game cube out of a raspberry pi. To rectifiy this I went back a generation of game consoles to the Nintendo 64. Emulation for this console would prove sketchy but doable! To continue, I wrote “4 Players!!” completely ignorant to knowing what a “player” actually is. A player is something that is giving input that the console needs to read and execute. This is much more taxing on the cpu than a simple AI that doesn’t have inputs but only executions. So, this project was whittled down to a portable N64 game console that could support up to two players and run at 60 frames. 


One of the first steps I had to take was purchasing a raspberry pi. I took about 30 minutes for me to make a decision between the Raspberry pi 2 B and the pi 3 and went with the 2B in the end. The Pi 3 did offer more processing power for 10 bucks more but many said I could emulate the same with a 2b. I took “the same” as the 2b has enough power to run the game flawlessly. I’m glad this was wrong. If the games ran flawlessly I wouldn’t have much to do. Instead, I learned a bunch about computers along the way. 

The other sect of research I had to do was how to interface with the pi. I quickly found that there was an OS designed to emulate games on the pi called “retropie.” To interface with the pi, I need to load an operating system (OS) onto a micro-SD card and boot the pi from there. Getting the OS loaded was easy. Put the micro-SD into a SD adapter -> Put the SD adapter into my computer’s SD slot -> Unzip a folder containing the OS called “retropie” -> Reinsert the micro-SD back into the pi and boot. Research did not take as much time as I thought it would take so I started to worry about if what I was doing was enough. Luckily the pi I bought was nowhere near perfect. 

The Meat and Potatoes

The meat and potatoes of this project was the optimization of this tiny computer. Many hours were spent within menus tweaking aspects of the pi that would either allot me more power or optimize a process. 

Picture 2: My desk during this whole project!

This amalgamation of cables would be my own little raspberry pi lab for the next week and a half. Two monitors, a laptop, 2 keyboard, 2 mice, 2 usb N64 controllers, my pi, and my desktop. Laptop was for loading software/games to the raspberry pi. Desktop was for debugging research. One monitor to interface with the pi. A keyboard to navigate the pi’s command prompts. Finally, the controllers to test game play. This picture was not necessary, but it was amusing to me! 

Picture 3: The raspberry pi 2 model B

This is the Pi I used for this project. In the middle of the board you can see a big green block of metal and a smaller grey block of metal to the right of the green block. These are heat sinks. Heat sinks act as a form of cooling without the fan. Heat is taken from the processor (green) and the Graphics Processing Unit(GPU, grey) and sent upward thorough the little fins. These fins proved crucial as they reduced the temperature of the pi running N64 games from 70 degrees C (highly dangerous) to around 58 degrees C (not highly dangerous). Outside to that modification, the rest of the board is run-of-the-mill. 32GB micro-SD (middle left), micro-USB power supply (bottom left) HDMI (bottom), Ethernet port (bottom right) and 4 USB 2.0 ports (top right).

Image result for retropie config menuImage result for raspi config advanced options

Pictures 4&5: Raspberry Pi configuration screen (left) Advanced configurations screen (right)

I am going to do a quick run down of each of these screens’ options and how I used them to benefit me or why I didn’t use them.

Raspi config, left

  • Expand File system: This formats the SD to the raspberry Pi, already done on my computer
  • Change Password: Security measure, no password was used doubt someone will hack my pi
  • Boot options: Could choose to boot to this screen or the OS, I did OS
  • Wait for network at boot: Have to be connected to the internet to use the Pi, this was disabled.
  • Internationalization Options: Everything was in English so I did not touch this.
  • Enable Camera: You can connect a camera via ribbon cable to the the pi, cameras are not needed for video games.
  • Add to Rastrack: Online pi data tracking
  • Overclock: I had to enable overclocking on my pi. Bumped the processing power from 900Mhz to 1000Mhz. A 7-10 frame difference in testing.
  • Advanced options: see right
  • About Raspi-config: A READ ME file about what each of these menu options does. 

Advanced options, right 

  • Expand File system: I do not know why they had this twice
  • Over scan: Naturally games have these ugly black bars around the screen. Before messing with this, about half the screen was black bars. Over scan eliminates these bars making the game easier to see 
  • Memory split: Oddly enough, I did not have to touch this option. I had the games running at 60 fps without touching it.
  • Audio: One can either play audio through the 3.5 mm jack on the board or through the HDMI. By default, it was through the jack so I changed it to HDMI.
  • Resolution: For some reason, the resolution was really high out of the box. Old games do not need high res do I bumped it down to 640×480. Doing this would put less stress on the GPU and processor because there is less on screen imaging to process. Also, there is a hertz associated with a resolution. This number of hertz is a hard cap at the amount of frames a game can be outputted to the monitor. There were options for 50hz resolutions but this would hard cap our game play at 50 frames, not ideal. 60 hertz for our desired 60 frame gameplay
  • GL Driver: For experimental versions of pi. Did not use.

Picture 6&7: Game Emulator Menu (left) picture taken of the emulation (right)

Each game on the pi is given its own emulation menu from which to control aspects of that games emulation. Every game is a tad different so they must be emulated different. 

  • Default Emulator: Always picks the most powerful one which is the worst one.
  • Select Emulator: Can choose from 7 emulators. The one I picked, “gles2n64”, prioritizes game play over graphics leading to smoother game play but bad in-game menus and the lack of eyes from smash bros characters (right).
  • Remove emulator: Removes the emulator. I do not understand this option’s purpose.
  • Default video mode: I did this back in the raspi-config menu. CEA-1 is the 640×480 resolution.
  • Remove video mode: Removes the video mode. I do not understand this option’s purpose.
  • Select frame buffer: Having a frame buffer makes it so that input is separated by frames. Once can press four buttons at once and have them all be read or, with a frame buffer, can have the first button pushed be read while the others are not read. They are not read because the frame buffer counter is not up. This can make games seem more fluid. Games already have their own frame buffers so I did not use this option.
  • Launch: launch the game and play it. 
  • Exit: save the settings and do not play the game.

The final thing I did was turn off something called retroarch.h settings. Retroarch was a controller setup program that made it so that one could have a specific set of controls per each game. Turning this off allotting me more cores towards emulation.


  • Overclocking to increase processor power
  • Changing resolution to decrease computing stress and give the ability for 60 frames per second
  • Fixing over scan to conform the game to the screen.
  • Audio to HDMI
  • Finding the right emulator to show the game
  • Disabling undesired programs (retroarch.h)
  • Adding heat sinks to my CPU and GPU to decease temperature.  

All lead up to a game console that:

  • Can be played for hours without over heating
  • Supports two players easily
  • Can fit in your pocket
  • Can conform to any TV
  • Can hold 32 GB worth of N64 games (biggest game I saw was 50mb, so 640 games!)
  • And most importantly, run at 60 frames per second.

I could go on about how important to me it was that I managed 60 frames. It just produces the best game play bar-none.

Finishing Up

The last bit I had to do was make a box! For this box I laser cut a press fit box. I could have 3D printed a case but a pressfit box took less time and looked better. 

Picture 8: The pressfit case.

I used an online generator to produce a .svg file of a pressfit box. All I had to do was add holes for the ports. Picture 8 was a little bit too small so I had to reprint, the concept was there tho. The reason I cut holes in the top of the box was to allow for the heat to rise. Don’t want our console to overheat after all the work we had done to it.  


Picture 9: Console presentation

The presentation went better than expected! I did not run into any issues testing at home pre-presentation but that doesn’t mean bugs will not creep up! This presentation ran for 90 min and the console maintained quality throughout. I had a couple people that stayed and played for awhile. I defiantly got more praise for it than I thought so needless to say I was proud of myself!


At the start of this project, when I had to establish learning goals. I said that my tech learning goal was to be able to use raspberry pi as a prototyping device in the future. As for what I would be prototyping, I do not know, but I have the know how of manipulating the pi to get a desired state. Somthing I just thought of being to prototype, as I’m writing this, would be a smart speaker. There is a ribbon cable spot for a screen so one does not have to use HDMI. Then there is the 3.5mm jack for audio. The micro-SD for storage and USB for a Bluetooth adapter as well as speakers them selves. One could use all these aspects to run Spotify on a tiny LCD and play music over Bluetooth (wifi if you have the pi 3).

It is baby’s first computer is what it is, low barrier to entry. A good place to start if one would like to tinker with computational architecture. Which leads me to my educational learning goal. I really wanted to learn how a computer works. I’ve built my own desktop before but that was all plug and play. I’ve never had to manipulate anything on the back end. Going in, I thought I would be just turning down the resolution and overclocking. What I ended up doing was min-maxing cores of the processor. Working in command prompts was also new to me so navigating those was troubling. It was almost like a text adventure but instead of giving command you are writing codes to change directories and call certain programs. Next time I will have to work with computers on a more intricate level I will think back to this project to see if what I did could help. 

Tags: ,