GameSphere   -   Craig   J.   Bishop   2010

  

Home-Made 32-bit ARM

Game Console

  

    Four years ago, I decided to build a game console.  So I did.  I learned how to use PIC microcontrollers, how to build support circuitry, how to design PCBs, how to design complete digital computer systems, how to write bootloader code in ARM assembly, how to interface with N64 controllers, how to read/write a FAT filesystem, how to use an oscilloscope effectively, how to blind debug hardware problems, how to solder .5 pitch TQFP, and much more.  The entire console is built from scratch, entirely of my own design.  I also wrote 100% of the code running on the console, from assembly bootloader to C game logic.  The actual development of the project took a little over three months after I started the first board.  The sample game in the YouTube video below took less than a day to develop, but it still looks sweet!  Most importantly, I had fun throughout the entire project!

The Beginning

The Hardware

    The GameSphere consists of three hand-built circuit boards:  a CPU board, a video board, and a human interface controller board.

    The CPU board has an ARM7 processor from Atmel - the AT91R40008.  It’s an older model, but it runs fast (75Mhz fast, 100Mhz overclocked) and has a simple external bus interface.  The CPU is the 100 pin TQFP package mounted on the green breakout board.  To the left, I currently have a 55.8Mhz clocked connect--I haven’t ordered a 100Mhz one yet.  The top left four components make up the power supply:  5V, 3.3V, and 1.8V.  On the top right, there is a standard RS-232 port fed by an line driver on the bottom right.    The other large DIP-package IC is a 256KB flash from Silicon Storage Technologies.  The large mass of resistors up to the left is the dual 8-bit audio DAC.  The power lines and memory bus both connect to the 40-pin IDE

cable connector on the left.  At startup, the flash loads its contents into the internal 256KB RAM on the CPU, since the flash is rather slow--70ns delay slow.  Then execution is transferred to the CPU RAM, and the console boots up, initializes the timers, USART modules, external bus mapping, video hardware, and software sound system.  The underside of the board is pretty ugly.  The whole board took two days of point-to-point soldering to put together.

    The Video board was the biggest time sink of the whole project.  It connects via the 40-pin IDE cable to the CPU board, bridging the 8-bit databus to a dual-port 128Kb x 8-bit Cypress SRAM (100 pin TQFP package on the green breakout board).  The high address bit is controlled by an I/O line on the ARM.  While one half of the RAM is written to by the game running on the CPU, the other half is rasterized to the display:  double buffered graphics in hardware.  A Microchip PIC18F4682 (the 40 pin DIP package) generates VGA/Composite video sync signals and counts addresses to the dual-port SRAM.  The output databus from the dual-port VRAM is pushed through an 8-bit resistor ladder DAC:  3 bits red, 3 bits green, 2 bits blue.  That configuration generates a very acceptable range of colors, however I do need change the DAC to a weighted design in order to generate more vibrant colors onscreen.  Three NPN bipolar transistors controller the outputs from the DAC, dumping the video levels to GND during sync and blanking.  Currently, I have the video hardware configured to generate a VGA signal at 224x240 resolution with 256 colors.  I have hardware for composite video signal generation on the board, but I have not been able to coax it into working.  I have a SOIC breakout board for an Analog Devices AD725 RGB to NTSC encoder, but it is desoldered right now.  I either have noise problems on my power lines, or I am generating the syncs incorrectly on the PIC---either way I have not gotten that to work yet.  The DIP switch array controls whether the RGB video lines go to the NTSC encoder or to the VGA connector.  I also added an SD card slot onto the

board, since it is quite difficult to fit all assets a game requires into 256KB.  The plan is to connect the SD card to the PIC on the Human Interface Controller board, and have that microcontroller asynchronously read/write data from the card, effectively creating a content streaming system for sound, graphics, and other media.  The video board is not quite as crazy on the underside, but still took the better part of a day to assemble.  Actually programming the video generation software took weeks of wading through poor reference material and tweaking timing values.

    The Human Interface Controller board is not quite as exciting as the others.  It has a single IC on it, a PIC18F2685 that talks to the N64 controller, and responds to controller polling requests from the CPU over USART.  It’s very noticeable in the picture of the underside that I originally had a different setup using a larger microcontroller.  I desoldered that and decided to use the smaller form factor chip so I could build expansion hardware on this board.  I plan to add additional external SRAM here--maybe the two 512Kb x 8 SRAMs I have in my bench drawers.  Those of course would be configured as one 512Kb x 16 bank.  The controller board was the last board I assembled, and it only took a few hours to build and to program the micro to interface with the N64.  Strangely, it took the longest time (a couple hours) to get the darn thing to talk to the CPU.  Turns out, I forgot to disable the CPU’s PIO controller on the USART1 lines--duh!

    I have been writing software for this project since I finished the CPU board.  Just minutes after I soldered the last connection on that board, I attempted to boot a simple blinky program to blink the status LED at a fixed rate--just to make sure the board worked.  Sixteen hours later I had a board that worked.  I had several wrong connections, a bad clock, a bad reset circuit, and I added a JTAG debug header--beats my DIY flash programmer by a long shot.  After that, the blinky program worked, and at that point I started building the video hardware.

    Amazingly, the video hardware worked the first time I connected it to the CPU.  I had tested it just displaying the random garbage in the VRAM at power on, but never connected to the rest of the console.  The test program simple draws all the possible colors across the screen.  The first picture shows the random VRAM garbage, and the second shows the test program.  Notice the VGA signal isn’t perfect yet.  It has a skew in the top couple lines resultant from bad sync signal timings during blanking.

The Software

    It took several days and some heavy use of my oscilloscope to debug the problems in the VGA generation software.  But, I finally prevailed--and trust me, that has to be one of the best days ever!  I quickly wrote a BMP to C R3G3B2 C array converter, and drew my first images to the screen.  Soon after I had a side-scrolling tilemap going.

Demo Game Video

    (the music is not from the console--that hardware is still undergoing heaving dubugging)

More Photos

Contact Me

    All of the game software is written in good old C and assembly, and it is compiled with the GNU ARM-ELF GCC toolset.  It took awhile to set up the makefile and write the bootloader assembly, but after that development for the system is a breeze.  I write code, compile it with a makefile hooked into xCode, and then run a script that downloads the new image into the internal CPU RAM for debugging.  When I am satisfied with the program, I run a flash programming utility and write it in the flash ICs for nonvolatile program storage.  I am still perfecting the software development side, and soon I will have to figure out how to handle

overlay code loaded from the SD card, and how to handle two different banks of RAM, one internal fast bank, and one external 16 bit wide slow bank.  Perhaps the internal bank will contain the speed critical sections:  graphics data and blitting routines.  The slow bank will contain inactive cached graphics and program code.

    Please feel free to contact me with any questions or comments about the GameSphere and its development.  Make sure to put “GameSphere” somewhere in the email’s subject, so I don’t delete it as spam.

Email:  craigoramajb {{ @ }} gmail.com

            (Remove the spaces and braces--spam protection)

AIM:  deathinbottle9

Special Thanks

André LaMothe

    Thank you for the Black Art of Video Game Console Design book, it really helped me through some of the most annoying problems, especially the VGA signal timing hackery.

Atmel

    Thank you for the free samples of your AT91R40008 ARM microcontrollers.  I love the SAM line of processors, and will definitely be using one in the next revision.

Sparkfun Electronics

    Thank you for the awesome hobbyist supplies.  Also, thank you for the awesome IRC chat channel and its wonderfully helpful late-night inhabitants.

Cypress

    Thank you for the free samples of your dual-port SRAM products.  I didn’t notice how expensive those things are when I sampled them, and sadly I won’t be able to afford those in the next revision.  However, that chip really made this design shine.