Video Game Console Project /
CPE 322: Engineering Design VI /
Mike Popoloski
Jack Alvino
Jon Lado
5/4/2011 /
We pledge our honor that we have abided by the Stevens Honor System.
Section 1: Introduction
1.1: Abstract
Video game consoles cover a wide range of engineering and computer science in their design and operation. This paper will cover the design, technical details, and engineering and economic constraints involved in building a student video game console that will be both useful and fun to play. Besides exploring the technical hardware aspects, which are numerous, the paper will also cover the programming interface and give some examples of games that would be fun and simple to build to demonstrate the capabilities of the system. Finally, a critical self-evaluation of the project as a product is given, demonstrating the feasibility of realizing it as an actual device.
1.2: Overview
Entertainment is a huge part of the modern economy in developed nations. A large portion of this entertainment industry is concentrated in video games, which are software products that exist solely for the amusement of their users. These video games can run on many modern computer platforms, but they have also led to the rise of dedicated machines that only run games. These are given the name “video game consoles”, and they by themselves constitute a multi-billion dollar industry that touches upon every aspect of computer hardware and software development. This fact makes them very interesting as a topic of study for student projects.
The project presented in this paper aims to investigate the technical and economic details behind video game consoles by building a useable console out of commercially available parts. This console will not only be a great educational experience for its builders, but also a fun, cheap, and useable machine that can be played or sold for other enthusiasts interested in developing software for a free and “open source” video game console.
The video game console project will focus on several distinct areas that will all be covered in this report. Most of them cover the hardware that will be employed to realize the final machine. This hardware has several jobs; it must easily support many different games, have a way to run game code, except player input, and act upon it to achieve real-time responses. Additionally, it must generate output data in the form of audio and video and transmit them to external output devices. All of these tasks require different hardware components and interconnects.
Besides the hardware, there is also the matter of the programming environment required to develop software applications that will run on the console. Without games, the console is useless. Thus, the paper will explore the tools and expectations around the software portion of the project, and will describe the mechanisms for developing and releasing the code for others to use and play. This facet of the project is a unique selling point among commercial game consoles; all game consoles currently on the market require large fees and notoriety in order to develop games for them. In contrast, our video game console will support open source games, which incentives the purchase of the hardware both for hobbyist development as well as play of a wide pool of free games.
This project ends up covering many areas of computer hardware and software development, and by building the console the team will gain considerable experience in all of them. Video generation, embedded systems, assembly language programming, real-time scheduling, digital system design, and electronic circuits are all covered. Additionally, the team will gain experience designing, planning, and executing a larger-scale engineering project that will have business and economic decision making incorporated. This gives important real-world experience and will make the project a valuable point for future resumes and job searches.
Section 2: Technical Information
2.1: Functional Overview
The following section gives a high-level block overview of the project hardware, and the various subsystems that will be required in order to implement all of the desired features for the video game console. Each subsystem is detailed and a list of requirements given and discussed.
Microcontroller
This is the main processor for the game console. It ties together the entire system and performs the actions required to translate game code and user input into an output video and audio signal. It has several discrete tasks:
- Boot up and display a menu that contains all of the programs found on the attached SD card.
- Allow the user to run one of the programs.
- Draw power for the system from an attached battery or wall adapter.
- Receive programming commands via USB for changing the firmware.
- Reading input from the input task and sending it to the main game process.
- Reading game code from the SD card into main memory.
- Executing the game.
- Sending the resulting output video and audio signals to the output devices; speakers, monitor, TV, etc.
Input Task
Handles reading the attached NES controllers and correctly communicates with them via the established protocol. Consolidates the input received and stores it in memory so that other tasks, such as the main game task, can make use of it for changing the state of the game.
Controllers will be standard NES controllers, which are simple to interface with and have nostalgic appeal.
Interfaces:
- NES controller plugs. Might need to obtain these from an existing project and harvest them from there.
SD Card Reader
Compiled applications will be stored on SD cards. A single SD card may have multiple applications stored on it, in which case the CPU will read the list at startup and provide a menu on screen to allow the user to select one and run it. Game data will also be saved to the card if necessary to provide “save states”.
Interfaces:
- SD Card Reader (I2C possibly)
Output Task
Handles the rendering of game data and conversion of the graphics into video signals for the appropriate output device: either NTSC composite or standard VGA color signal.
Additionally, it handles producing audio signals that will be sent to speakers to accompany the game and provide auditory feedback.
Interfaces between output and microprocessor:
- Composite video jack
- VGA connector
- Audio jack
2.2: Technical Description
This section gives an overview of the various hardware profiles considered to fulfill the functional design provided in the previous section. These hardware overviews are presented in block diagram form to give a quick visual aid. Further detail information is only given on the first design, since that is the one ultimately chosen by the team as the most promising set of hardware for the project.
Design 1
This design emphasizes smaller and cheaper pieces of hardware in order to fulfill the functional contract. It uses simpler NES controllers and the time-tested American NTSC signal as the output of the console. This design most closely mimics the hardware of old-school Nintendo Entertainment System. Additionally it makes use of the Parallax Propeller chip, a niche but innovative embedded processor that should provide a great deal of power without sacrificing simplicity or ease of development.
Design 2
This design focuses on more powerful components and fully featured peripherals, at the expense of simplicity and cost. The ARM microcontroller is used in many commercial products, including mobile devices and smaller video game consoles. Unfortunately these processors are usually costly and need to be bought in vast bulk, making them less useful from our perspective.
Additionally, this design makes use of the Xbox 360 gamepad as its input peripheral. This controller is more complex and feature-full than the NES controllers of the previous design, which provides more opportunities for games but makes them harder to interface and program for.
Design Choice
The group has decided to go with Design 1, and as such hasn’t done as much in-depth research on the second design. The reason for this is that the second design, while potentially more powerful, is also far more complex and involves a much bigger investment than the first one, which cannot be afforded at this particular point in time.
NTSC Output
Signals
NTSC is the standard used for North American video signal. For color, the signal was a combination of red, blue, and green. Three signals must be transmitted to see the color. These signals can be a combination of the three.
References:
estead.com/files/modulation/ntsc_sig.htm
Ports + Interface
For the game console we are using a propeller chip. The propeller chip is capable of generating its own video signals. It can generate NTSC signals, as long as it is defined in the code which type of signal needs to be generated. To view the generated material, a RCA to RCA cable can be connected from the propeller setup and into the TV. This also depends on where it is getting connected to. For a TV, an RCA cable can be used. If a computer is needed for display, a VGA cable would be needed. This would be connected to computer and the console.
Therefore, since the console generates its own video signals, only the proper ports are needed to connect the console to a display. For a TV, a RCA cable is used, and for a computer monitor, a VGA cable is used.
SD Card Interfacing
Applications the microcontroller reads will be stored on a secure digital (SD) card. There are multiple methods to interface an SD card with a microcontroller, but this project will like use the most common method of Serial Peripheral Interface (SPI). The two figures below illustrate the pin assignments for the cards:
(Source:
To properly interface a card with the microcontroller, a socket will be mounted on the PCB and then interfaced using the above pin assignments as reference. Any simple socket that allows for easy access to the card for removal/replacement will work, such as the one found at
The SPI interfacing method chosen is relatively straightforward, and is supported by the Propeller Microcontroller used to design this system. It requires only four connections between the SD card and the microcontroller, specifically pins 1, 2, 5, and 7 on the SD card. The rest of the inputs are then pulled up with resistors, with the exception of the two ground ports that are grounded as necessary.
Another option for interfacing is Inter-IC bus, or I2C. It is a two wired serial bus, as opposed to the SPI four-wires. However, it cannot achieve data rates as high as SPI interfacing and does not have duplex capability of having data streaming from master to slave and slave to master simultaneously. While this duplex capability may not be necessary for this project, it should be noted that having more potential features that could possibly lead to easier implementation of other project parts is always a good thing.
References:
NES Controller Input
The controllers for the Nintendo Entertainment System will be repurposed for use with the video game console being developed.
The old NES interface is very simple to hook up and connect to. It uses a serialized polling mechanism, which takes input from the microcontroller’s clock and latches the state of the buttons at a given time pulse. Then the button states can be sent, one at a time, across the data wire.
Pinout:
+----> Power (white)
|
5 +------+ 7
| x x o \
| o o o o |
4 +------+ 1
| | | |
| | | +-> Ground (brown)
| | +----> Pulse (red)
| +------> Latch (orange)
+------> Data (yellow)
Signal Diagram:
References:
Power / Battery
This step will use a simple AC-to-DC wall adapter, which can be easily purchased from any electronics shop. There aren’t any particular specifications to conform to here, except that the microcontroller circuitry requires a certain voltage, which will be stepped down from the 12 V wall adapter via a series of on-board regulators.
Microcontroller
Arguably the most important part of the project, the microcontroller for the console needs to perform several important duties in order for the machine to be useful as a gaming platform. These include loading stored applications from removable storage, displaying the list during a boot sequence, allowing the user to select a game to run, and then loading and executing game code in order to run the simulation and provide the necessary gaming experience.
As part of this process, the microcontroller will accept input from the attached gaming controllers, receive power from the power system, and use them to affect changes in the state of the virtual game world. The game will make the necessary calls to generate visual and audible feedback to communicate changes in the virtual world to the user. This feedback will be fed via the microcontroller into the external NTSC and audio ports via RCA connectors. These can then be used to connect the entire console to external hardware such as a TV and speakers that can display this information to the user.
For the microcontroller, the project will be using the Parallax Propeller microcontroller, which has 8 independent cores, or “cogs”, which will perform the various functions of our game console.
The following is an example Propeller development board sold by Parallax:
For our project, we will be buying stand-alone chip packages and building them into our PCBs, which run at $7.99 for single purchases.
The key feature specs of the Propeller chip are as follows (listed on the Parallax reference information):
- Model Number: P8X32A-Q44
- Processors (cogs): Eight
- Architecture: 32-bits
- System Clock Speed: DC to 80 MHz
- Global RAM/ROM: 64 K bytes; 32 K RAM / 32 K ROM
- Cog RAM: 512 x 32 bits each
- I/O Pins: 32 (simultaneously addressable by all eight cogs)
- Current Source/Sink per I/O: 40 mA
- Clock Modes: (a) External crystal 4 -8 MHz (16 x PLL) (b) Internal oscillator ~12 MHz or ~20 kHz (c) Direct drive
- Package Type: 44-pin QFP
- Power requirements: 2.7 to 3.3 VDC
- Communication: Serial for programming
- Dimensions: 0.39 x 0.39 x 0.05 in (10 x 10 x 1.4 mm)
- Operating temp range: -67 to +257 °F (-55 to +125 °C)
The Propeller is a rather unique chip in that it has eight independent cores, or “cogs”, that combine their processing power to perform the various functions necessary for the hardware product. It utilizes a round-robin memory hub that switches deterministically between each core at every clock cycle. This allows for the development of very specific programs that take advantage of the deterministic behavior to maximize the performance of the hardware.
An overview of the Propeller chip is given:
Programming Environment
As can be seen from the functional and technical block diagrams, the design of the video game console depends on storing application code and assets on external SD cards and loading them at runtime through a boot loader stored on the chip itself. These applications need to be written and compiled first, and the details of doing that will be covered in this section.
The Parallax Propeller chip uses two different programming languages in order to achieve programmability. First, like all microcontrollers, it accepts a variation of assembly called PASM (Propeller ASM) that is compiled into object code and loaded onto the chip via USB or serial connections to a PC. These PASM programs run on a single core of the chip, but can launch additional cores and point them at various blocks of memory that constitute instructions to execute.
Additionally, the Propeller chip has a high-level language interpreter built right into its ROM. This language is called Spin, and is the entry point for all programs written for the Propeller. The main Spin interpreter starts up and runs the main entry point for the application, which can then start additional cores as necessary. Spin provides a high-level interface for all of the chips operations, and gives additional instructions that are not natively supported by the hardware. Since it is interpreted, it is slightly slower than hardware PASM instructions, and for that reason is useful for game code but not as useful for low level graphics and audio signal generation and driving.
The Propeller programs can be compiled into object code on the PC and then saved in raw binary format and loaded onto an SD card. These cards can then be read at runtime by a program written specifically to test the SD port and read the binary format there. There is no virtual memory system for the Propeller, so executing data as code is as simple as moving it into main memory and setting the instruction pointer to point at the start of this data. Using this method, hot-swapping of applications can be accomplished without much difficulty.
The Propeller comes with an IDE that helps write, compile, and test the programs as they are written, rather than waiting for the programming of the processor. A screenshot of the IDE is given below: