STEVENS INSTITUTE OF TECHNOLOGY
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.
Controller 1
Controller 2
Input Task
TV / Monitor
Power / Battery
Microcontroller
Output Task
Audio Output
Stored
Applications
SD Card Reader
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.
NES Controller
NES Controller
Input Task
NTSC
12V Wall Adapter
Propeller Chip
Output Task
Audio Output
Stored
Applications
SD Card Reader
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.
Xbox Gamepad
Xbox Gamepad
Input Task
VGA Monitor
12V Wall Adapter
ARM
Processor
Output Task
Audio Output
Stored
Applications
CD Drive
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:
http://courses.cit.cornell.edu/ee476/FinalProjects/s2006/kwj5_mhw23/index.html
http://cnyack.hom 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: http://alumni.cs.ucr.edu/~amitra/sdcard/Additional/sdcard_appnote_foust.pdf)
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
http://www.sparkfun.com/products/136.
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:
http://www.eetimes.com/discussion/beginner-s-corner/4023908/Introduction-to-Serial-PeripheralInterface
http://www.eetimes.com/discussion/beginner-s-corner/4023816/Introduction-to-I2C
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:
+---->
|
5 +---------+ 7
| x x o
\
| o o o o |
4 +------------+
| | | |
| | | +->
| | +---->
| +------->
+---------->
Power
(white)
1
Ground
Pulse
Latch
Data
(brown)
(red)
(orange)
(yellow)
Signal Diagram:
References:
http://www.mit.edu/~tarvizo/nes-controller.html
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:
This application also assists with easily loading applications over a USB interface to a connected
Propeller chip through additional dedicated hardware. This mechanism will be used to upload firmware
updates to the Propeller.
Besides application instructions, games also require external data, such as sprites, background graphics,
tile images, audio files, and game scripts. All of this external data can be stored alongside the application
in the SD card and accessed at runtime as necessary. Since the Propeller doesn’t have much internal
memory, an external memory source will most likely be necessary in order to achieve playable
performance for games requiring more memory.
References:
http://www.parallax.com/tabid/832/Default.aspx
Drivers
Along with the hardware, various software drivers will be provided in order to assist others in writing
programs for the video game console. These drivers will simplify various commonly performed aspects
of game development, such as generation of the NTSC signals for source images, reading of the NES
gamepad, generation of audio signals for sound effects, reading of the SD card for loading and saving
game data, and interfacing with external memory.
Some sample code already exists in the Propeller Object Exchange, an online repository of open source
Propeller objects that can be tailored by the team in order to provide a more specialized version suitable
for application development for the console.
In particular, the team will be using the Parallax NTSC driver as a reference for its own custom driver.
The NTSC specification has very precise signal timings that can be very difficult to program for efficiently.
By using the reference driver as a base, the team can take advantage of experts in the field without
having to invest time, energy, and money into developing a completely custom solution from scratch.
References:
http://obex.parallax.com/
2.3: Mathematical Principles
The video game console project uses many engineering and computing principles in its design and
development. These principles will be described in this section, along with supporting reference
information that will come into play if and when actual work on the project is begun.
Obviously, as a type of embedded system, there are many electrical and physical principles in play.
However, for the most part most of these are handled at a lower level and are thus not necessarily
integral parts of the design process. In addition to these, there are several principles related to the
hardware that are necessary for the design process; these include digital signal processing for the
handling of NTSC and audio signals, and the basics of electronic circuits, which is necessary for setting up
and laying out the circuit board for the console.
Digital signal processing is used to generate the signals necessary to create an image through the NTSC
specification. In short, electrical signals are run through a 3-bit digital to analog converter (DAC)
attached to three output pins of the digital Propeller chip. These pins have various resistors attached to
achieve the conversion from the digital signal to the analog signal necessary for the NTSC signal.
Further details on signal processing:
http://en.wikipedia.org/wiki/Digital_signal_processing
http://www.analog.com/en/processors-dsp/content/beginners_guide_to_dsp/fca.html
Additionally, since the project equally involves the development of software applications (games) to run
on the console, there are a whole host of software principles involved. There are the standard general
principles that apply to all software projects, as well as principles more closely attuned to the highly
parallel environment available in the Propeller chip. As such, the programmer will need to know object
oriented programming, embedded systems programming, the details of real time scheduling and
operating systems, and parallelization and concurrent programming.
References for these topics are given:
http://www.oodesign.com/design-principles.html
http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf
http://www.cs.rice.edu/~vs3/PDF/comp322-lec1-f09-v1.pdf
http://en.wikipedia.org/wiki/Parallel_computing
2.4 Performance Objectives
In order for the video game console to be useful, it must reach certain performance objectives. These
objectives are defined in order to provide a playable experience for the user. If the hardware is too slow,
it can fail to keep up with the pace of game play and cause frustration for the user, which is very bad.
This can be manifested in various ways, including jitter in the output video signal, hiccups in the audio
output, missed controller input events, and overall slowness of the game loop.
There are several standard metrics for the performance of commercial video games. Usually, the
running of a game is divided into discrete events called frames, during which input for the time instant is
evaluated, the simulation is advanced, and a single rendered image is output to the video device.
By calculating the number of game frames running per second, we can get a useful metric for
establishing the running time of a game that does not have any deterministic end point. For commercial
games, this “frames per second”, or FPS, is usually targeted at one of two values: 30 FPS or 60 FPS. This
seems like a good target for games running on the video game console being developed as well, so
everything being built will focus towards making this rate possible.
In addition to the overall system metric for speed, there are additional metrics imposed by the choice of
hardware. The system will run at 80 MHz for each of eight cores, leading to an upper bound on the
amount of processing time available to run game operations. Each SD card will have a maximum size,
which will limit the size of applications and their game data, as well as save states that can be stored.
Additionally, there is a maximum amount of memory that can be purposed at runtime to store
instructions and data. All of these hardware limits translate to restrictions on what the games written
for the platform can accomplish. All video game consoles have similar limits; the only difference is how
high they go before they start limiting applications.
There are also various timing limits imposed by the signals being used to generate output audio and
video. For example, as discussed earlier in the paper, the NTSC signal specification contains various
explicit timing requirements in order to generate a signal that is compatible with the spec. These signal
timings are complex and listed in the accompanying reference information. It is sufficient to know that
the NTSC driver will need to taking into account the running time of the various instructions it employs
and know how many can be scheduled between NTSC frames, otherwise improper video signals will be
generated and the display could be distorted or entirely absent.
One last performance metric that must be considered is the performance of the user input interface. In
this case, the input is given through the NES controllers, so the system must operate at a level of
performance sufficient to capture all input events as they become necessary to make decisions in the
state of the game. Otherwise, unexpected behavior will result during game play and users will quickly
become frustrated and cease playing the game and the system in general.
Section 3: Critical Evaluation of Project
3.1: The “Good”
Creating a video game console is an ambitious task that requires much work, and as such there are
naturally bound to be some aspects which are easier to accomplish than others. Fortunately, the
chosen design is one that makes use of modern technology to accomplish tasks that once required much
more complex designs. The design process helped to choose the most straightforward possible
implementations of the electronic components, allowing for many of the goals to appear easy to
complete. Unfortunately, it is likely that only a few will be as easy as they appear.
Easily the simplest part, but also a vital portion, is providing power to the board. Regulator circuits
would need to be built and added into the PCB design, with the voltage stepped down to the voltage
required by the microprocessor. To even further simplify this, voltage regulator integrated circuits could
be purchased to eliminate extra design steps. After the regulators are implemented, a common AC-toDC wall adapter will be used. This particular design aspect is relatively low stress compared to the rest
of the PCB board design, as it can be completely simply with many store bought components.
The input control scheme using the NES controller is another of the easy to implement project aspects.
Using “old-school” technology translates well into this design, as it allows for a much more simplified
approach than more modern equipment. The NES controls will only require five of its input pins to be
used, with two of those being power and ground. This leaves three that connect to the actual
microcontroller, meaning a relatively small amount of work to put in.
Interfacing with the SD card for reading games will also be a safe task. Since SD cards are a very
commonly used means of data reading, there are vast amounts of resources online that can assist in the
wiring of one to a microcontroller. Using SPI interfacing, only four ports of the microcontroller will need
to be dedicated to SD card reading. As with the NES controller there is ground and power connections
that need to be made, but small amounts of interfacing with the microcontroller leads to easy design
implementation.
3.2: The “Scary”
The actual construction of the PCB board is an extremely critical and sensitive task. The designs chosen
may appear to be rather simple, but the actual soldering process will most certainly be a daunting task.
Small errors in that stage of the project can result in major hardware complications, and finding out
where the errors in the soldering are can be an even more arduous task. Even worse than the design
simply not working due to soldering errors would be if some of the components were damaged in the
process, leading to increased costs and potentially setting the project behind schedule.
As far as individual component implementations, the video output is an extremely crucial component
that could lead to major problems. Properly amplifying the video signal could potentially be difficult,
and the visual output is certainly the first noticeable sign of project success. Without video being
generated, it would be impossible to debug and test the programmed games that are being played, and
would certainly lead to the project being considered a failure.
The thought of programmed games bring up another scary aspect, the actual programming involved.
Programming a game is a complex task that involves in-depth testing to make sure that the mechanics of
the game itself work, on top of creative thinking required to come up with unique and fun game ideas.
The games themselves would also have the limitations of the hardware to keep in mind, leading to some
further issues of memory requirements and overall game length. On top of dealing with the complex
hardware implementations, also having to worry about creating one or more successful games is a large
amount of work. Without games, the hardware is essentially useless. In fact, even with only one or two
working games the project will seem a lot less impressive.
3.3: The “Fun”
The fun of the project comes from working through the above difficulties. There will be immense
amounts of satisfaction to be had once the PCB has been verified to work correctly. There will also be a
lot of learning involved in the construction process, and although learning is not always considered fun
given the nature of this design it certainly will be interesting.
After the hardware is successfully created, and the first working game is successfully played, creating
more games will be significantly easier. On top of that, getting to play the games to test them and
seeing their evolution will be an extremely rewarding experience.
Perhaps the most fun part about the project is its potential. As with all gaming systems, there is a high
likelihood of multiplayer games being created. Multiplayer games would of course allow others to see
the success of the project, and there is a chance that other people with their own game ideas could
contribute to the project.
Potentially, a website could be hosted where the design of the system is shown with instructions on
creating one. Then a community could form where users can create and trade games with each other,
vastly increasing the library of games available. Bringing an idea like this to the internet, even without
any commercial success involved, would be an extremely unique experience and would most certainly
be something fun.
3.4: Project Funding
Funding from outside sources is a highly unlikely thing for this particular project. That being said, the
parts themselves are not extremely expensive and it is highly likely that it will be able to be completed
on a small budget. This project, however, has a unique option of obtaining “donated” software from
other amateur game designers. As previously discussed, potential trading or sharing of game ideas and
actual game code is a possible outcome of this project. Having outside help testing the hardware
limitations through increasingly complex game designs would be both useful and time effective, as it
would require little to no time spent by the group programming.
Section 4: Summary
In summary, the team is creating a retro video game console. Of course a team of three cannot create a
worthy competitor in a market dominated by big names such as Nintendo, Sony, and Microsoft, but a
team of three can definitely make a retro based console worth playing. Video games will always have
business, and retro style games have become increasingly popular with the release of indie games and
various downloadable “arcade” games. These games are very reminiscent of the 90’s Super Nintendo
Entertainment System, SEGA Genesis, and even some earlier consoles. Therefore the team aimed to
create a functioning retro style console.
The major components of the console are the Propeller microcontroller, the SD card reader, controllers,
wall adapter, and output cables. The microcontroller is the most important component, as it’s the main
processor in the console. It is what takes the inputs from the controller and game, and outputs it. It shall
contain a GUI menu that can interact with the controller inputs and whatever is on the SD card. It
receives power from the wall adapter and opens and runs the game. The microcontroller we are using is
a Propeller chip. This chip is very helpful in the development of the console, as it has its own coding
language which happens to be simple, and can display video. The chip contains eight independent cores,
each that perform separate tasks for the console, such as display video signals. The SD card reader
would be the next most important component in developing the console. It will be the way that users
can play the games, and even change the firmware of the console. Conveniently the chip can produce
video signals, as long as it is defined in the coding. That leaves the simple task of attaching a composite
cable to a TV or a VGA cable to a monitor to play and use the console. The controllers used are NES
controllers. These were chosen because they are easy to set up and have a very nostalgic feel. Of course,
the NES controllers would be for a prototype phase, and from there a similar and reminiscent controller
can be developed.
Research was conducted for this console as well. The group found articles about USB’s, SD card readers,
NTSC signals and interfaces, and much more. These are intended to give insight on how each works and
how it is applied and used in the console. Other articles dealt with the economy of video game consoles.
Most previous and retro consoles have been major successes, and it’s no wonder why they are
becoming popular again. There are types of competition that can threaten consoles, such as cloud-based
stores for PCs, but this can be put aside because it simply is for PCs. The group took into consideration
some sort of implementation to the console. But in conclusion it was learned that video games will
always have a big market, and even though a retro console might not be as big a hit as consoles out
now, it will definitely cater to those who share the same nostalgia.
Section 5: References
5.1: Cited References















http://courses.cit.cornell.edu/ee476/FinalProjects/s2006/kwj5_mhw23/index.html
http://cnyack.hom estead.com/files/modulation/ntsc_sig.htm
http://alumni.cs.ucr.edu/~amitra/sdcard/Additional/sdcard_appnote_foust.pdf
http://www.sparkfun.com/products/136
http://www.eetimes.com/discussion/beginner-s-corner/4023908/Introduction-to-SerialPeripheral-Interface
http://www.eetimes.com/discussion/beginner-s-corner/4023816/Introduction-to-I2C
http://www.mit.edu/~tarvizo/nes-controller.html
http://www.parallax.com/tabid/832/Default.aspx
http://obex.parallax.com/
http://en.wikipedia.org/wiki/Digital_signal_processing
http://www.analog.com/en/processors-dsp/content/beginners_guide_to_dsp/fca.html
http://www.oodesign.com/design-principles.html
http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf
http://www.cs.rice.edu/~vs3/PDF/comp322-lec1-f09-v1.pdf
http://en.wikipedia.org/wiki/Parallel_computing
5.2: Useful Websites



www.parallax.com
http://propeller.wikispaces.com/
http://obex.parallax.com/
5.3: Data Sheets


Propeller Datasheet:
http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/PropellerDatasheet-v1.2.pdf
Propeller programming manual:
http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/WebPM-v1.1.pdf
5.4: Useful Articles








http://www.faculty.iu-bremen.de/birk/lectures/PC1012003/14usb/FINAL%20VERSION/usb_protocol.html
http://www.differencebetween.net/technology/difference-between-sram-and-dram/
http://www.permadi.com/tutorial/raycast/index.html
http://www.pcworld.com/article/207891/inside_the_nintendo_entertainment_system.html
http://fms.komkon.org/EMUL8/NES.html
http://nesdev.parodius.com/NESDoc.pdf
http://electronics.howstuffworks.com/n64.htm/printable
http://wiki.superfamicom.org/snes/show/S-DD1
Section 6: Project Members
6.1: Jonathan Lado
Jon Lado is an electrical engineer at Stevens Institute of Technology. He has always been interested in
electronics and circuitry and in Stevens he seeks to further his knowledge of each. The project was fun
for him because he has always been into video games. He’s always dissected his old consoles and tried
to figure what each component does. Now as he learns more and more it’s interesting for him to recall
those times. This project was very nostalgic for him since it caught his interest in creating a console and
reminded him of the fun games he would play when he was younger.
6.2: Jack Alvino
Jack Alvino is a rising senior Electrical Engineering student at Stevens Institute of technology. He was
born and raised in Staten Island, New York until 14 years old, when he then moved to Bensalem,
Pennsylvania. He went to a small Catholic High School, excelling academically in math and science.
Unable to decide where to go with his life, he began exploring options, and attended a summer program
where a competition between mock businesses was held. Quickly realizing that business was not
something that even remotely interested him, his heart was set on engineering.
From an early age, Jack always had an interest in video games. His first console was an N64 at the age of
6, but he was playing Doom with his father on the PC before that. While keeping up with consoles,
computers became a much more interesting topic once he reached high school. By the time he
graduated, he had a goal of building his own. Since that time he has constructed and upgraded his own
personal PC in the interest of keeping up to date with the gaming advancements. When reading about
this project, there was a natural impulse to want to work on it due to his fascination with video games.
6.3: Michael Popoloski
Michael Popoloski is a student at Stevens Institute of Technology who is pursuing both a bachelor’s and
a master’s degree in computer engineering. His love for video games, computer hardware, and software
development led him to envision the idea for the project and work to see it come to fruition. As project
leader, Mike has worked to ensure that the team met the deadlines for the various reports and that the
ultimate decisions regarding design choices were made in the best interests of both the project and the
team. His love and fascination with the rewarding experience of software development will continually
urge him to better himself and the projects he works on.