Cem Ozkaynak

Brian Smith

May 2, 2005


1. Introduction


Brian Smith and Cem Ozkaynak, two Seniors enrolled in ECE 476 at Cornell University, seek to rekindle the mood of impending nuclear annihilation by distant ‘Evil Empires’ through the classic 1980’s video arcade sensation Missile Command.


Given the harmonious state of international affairs today and the resounding love for America throughout the world, we sought to remind younger generations that there were periods in history when ‘rogue states’ threatened the world with nuclear annihilation.  To recreate the long-forgotten fear of these ‘Evil’ states that were often geographically challenging for many to locate we chose to use the medium of our generation – video games.   Missile Command is simple in concept and easy to pick-up.  In our design, the player has five cities that he would prefer continued to exist.  However, the opponent rogue state, signaling its distaste for diplomacy and its preference for the blood of the capitalist West, launches its nuclear missiles at the player’s cities.  The player attempts to defend the cities against incoming waves of hostile missiles using interceptor missiles, which travel from one of the cities to the target chosen by the player.  The interceptors detonate at the target, creating a temporary explosion area which destroys all missiles within its radius.  The player must choose the targets wisely since there is a limit on the number of interceptors available at any given time.  Each successful intercept adds points to the player’s score.  The game continues, increasing in difficulty by increasing the inbound missile speeds, until all of the player’s cities are destroyed.  The only objective of the game is to surpass any existing High Score.  In nuclear warfare there are no winners – unless, of course, you’re a rogue state.  Somehow impending nuclear annihilation never deters those guys.


To implement Missile Command in hardware we have chosen to use two Atmel Amega32 microcontrollers (MCUs).  Both microcontrollers are soldered on to separate prototype boards which have the appropriate power input, mouse input, and video output connections.  One microcontroller is used to generate a NTSC B/W video signal that is transmitted to a state-of-the-art consumer electronic 5” B/W Jensen television.  The second microcontroller interfaces with a PS/2 mouse and is responsible for transmitting the relevant mouse parameters to the video generation microcontroller.  The software on both MCUs is written in C using CAVR. 


2. High Level Design


2.1 Background Math


Besides simple arithmetic, Missile Command requires cosine and sine tables to determine the trajectories of inbound missiles and interceptors.  The game makes no attempt to model the physics of real missiles by tracking variable acceleration due to variations in fuel consumption, distance from Earth, atmospheric resistance, etc.  In fact, the inbound missiles ‘fall’ at a constant y-velocity that is only changed according to difficulty level.  Despite these simplifications, the need for cosine and sine calculations throughout video generation frames complicates the design of our software.  These issues and the associated solutions are discussed in detail in the Software section.


2.2 Logical Structure


The design of Missile Command is separated into two segments – mouse control and video generation.  The mouse MCU is connected to the video MCU through wires soldered directly onto both prototype boards.  The video MCU reads the relevant mouse MCU pins when it needs to determine the location and status of the mouse.  The video MCU executes all video generation code and interfaces with the B/W television through the prototype board.  The video MCU code structure utilizes state-machine coding techniques. There are clearly delimited areas of the code that are responsible for functions such as drawing and updating cities, drawing and updating missiles, drawing and updating interceptors, and checking for the end of the game.


2.3 Hardware/Software Tradeoffs


The NTSC video generation requirements and the speed of the Amega32 are the main constraints on our design.  The necessity to update the video signal within a fixed time frame limits the amount and complexity of instructions executed in any one frame.  Therefore, the software is written to facilitate this time constraint by breaking-up the various tasks that must be accomplished into executable chunks for each frame.


2.4 Standards Compliance


Our hardware complies with the PS/2 standard 6-pin interface as detailed below.  Missile Command complies with NTSC RS-170 monochrome standard for television interface using 525 stacked horizontal lines and a 60Hz refresh rate.  This standard specifies a horizontal sync pulse of 5 ms and a vertical sync pulse of 63.55 ms.  We implement a 63.625 ms vertical sync pulse because it is easily generated using a 16MHz clock.  We follow the RS-170 monochrome video standard by implementing a black and white scheme for our game.


2.5 Intellectual Property Concerns


Although this game is a recreation of the original Missile Command, a proprietary game, we have not infringed upon any intellectual property rights.  According to Richard Lawrence's 1999 article “Legalities of Emulators,” copying the premise behind a game is not illegal.  For the mouse microcontroller, we used code developed by Chee Ming Chaw and Elaine Siu for a Minesweeper Program for 476 in 2003.


3. Hardware Design


The hardware design of this project is very simple in principle.  Two Atmel Amega32 microcontrollers (MCUs) are soldered on to separate prototype boards which have the appropriate power input, mouse input, and video output connections.  One microcontroller is used to generate a NTSC B/W video signal that is transmitted to a state-of-the-art consumer electronic 5” B/W Jensen television.  The second microcontroller interfaces with a PS/2 mouse and is responsible for transmitting the relevant mouse parameters to the video generation microcontroller. 


Custom PC Board (prototype board): A prototype board for the Atmel Mega32 (PDIP) MCU includes a power supply, crystal clock, RS232 interface and generous bypass capacitors. A six-pin header allows flash memory programming from an STK500. There is space to optionally mount 0.3 inch PDIP, SOIC16, SOT23-6, LCC-16 (0.05 inch) and headers. A 32-pin header-plug mounted along the top edge of the board could interface to a stardard solderless white-board.

4. Software Design


The software design is the main component of this project.  Two separate software codes, one for the PS/2 mouse and one for video generation, were used. 


4.1 Mouse Software


For the mouse microcontroller, we used code developed by Chee Ming Chaw and Elaine Siu for a Minesweeper Program for 476 in 2003.  This supplied us with a basic way to interface with the mouse and get the following three bytes of information:


Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

Bit 0

Byte 1

Y overflow

X overflow

Y sign bit

X sign bit

Always 1

Middle Btn

Right Btn

Left Btn

Byte 2

X Movement

Byte 3

Y Movement


The useful pieces of information are the x movement, y movement, x sign, y sign, and left button.  We mask the left button bit form the first byte and output it on PORTD.2, which is connected to PORTD.2 on the video micro.  The x movement that we get in byte 2 is actually the amount of change that has occurred since we last polled the mouse.  It is an unsigned value, with the sign coming from bit 4 of byte 1.  The same goes for the y movement from byte 3.  The only difference for the y movement is that we have to invert it because our video screen has line 1 at the top.  We then restrict the movement of the mouse such that it cannot go outside of the game area, and cannot go as far down as the cities (we don't want to friendly fire!)  We add the movement of the mouse to the current position of the mouse, and output the x and y coordinates on PORTB and PORTC, respectively.  These ports are connected to the same ports on the other MCU. 


The resolution from the mouse is four pixels per millimeter, which may seem to be a bit overly sensitive for precise applications, is great for our program, because a premium is placed not on accuracy (the explosions are 5 pixels large), but on speed.  We sample the mouse every 200 line times (~78.5 Hz).


4.2 Initial Video Design


The initial software template that was used for the video generation code was that of ECE 476 Laboratory 4: Lunar Lander.  This code contained small and large alphanumeric character bitmaps that were utilized as well as tasks that sent the bitmaps to the television.  Some modifications were made to these existing tasks to incorporate the bitmaps that we designed for the cities and explosions.  The function video_puts() was modified to generate video signals from bitmaps stored directly in flash rather than ROM.  This modified function is referred to as video_putsf().


The video generation software is divided into segments that generate the initial menu, clear the screen, update the cursor, as well as generate cities, missiles, and interceptors.  It is not possible to do many video intensive updates in a single frame which means that some tasks have to be further broken-down and divided executed over multiple frames. 


An initialize routine is called in main() to set-up the MCU for NTSC video generation as well as to set the initial values of some of the game parameters.  Subsequently, the main() task enters an infinite loop where the processor goes into ‘sleep’ mode until the raster on the television reaches line 231.  At this point the MCU starts executing the video generation code.  It begins by erasing the mouse cursor on the previous frame and drawing the new cursor based on the output of mouse MCU.  Also, the bounds for the mouse position are checked to ensure that the cursor is not drawn outside of our active window. 


Following the updated cursor, a switch-case statement is used to create a state-machine structure that executes one of the following states:  PRNT_INTRO, GET_INTRO, PRNT_DIF, GET_DIF, GAME_INIT, RUN_GAME.


PRNT_INTRO: This state sends the game menu to the television.  Additionally it sets the city status (cstatus) and interceptor status (istatus) arrays to their initial values indicating that all cities are alive and all interceptors are dead.  The game state variable, gamestate, is updated to GET_INTRO.


GET_INTRO: This state is repeatedly executed until the user makes a valid right mouse click.


PRNT_DIF:  After the player’s mouse click, this state is executed and displays the difficult menu.  The three difficulty levels are North Korea, Pakistan, and USSR.


GET_DIF:  Similar to GET_INTRO, this state waits for a mouse click and checks the location of the cursor to determine which difficulty level was chosen.


GAME_INIT:  This state clears the screen by clearing three screen lines in each iteration until all of the active screen has been cleared.


RUN_GAME:  This is the most complicated state because all of the actual game video generation occurs in this state.  Within RUN_GAME, another state machine determines the state of the game in progress.  This state machine is necessary to subdivide the tasks of generating images for the city, interceptor, and missile.  The following sections explain each function in detail.  See Appendix for images of game in play.


PRNT_GAMEOVER: The end of the game is detected within RUN_GAME when all of the city status bits, cstatus[], have been set to zero.  The gamestate is updated to PRNT_GAMEOVER which checks for a change in the high score, sends the message “BOOM” to the screen and calls GET_GAMEOVER.


GET_GAMEOVER: This state generates a large mushroom cloud that occupies most of the active screen.  This image remains until the user clicks the left mouse button which prompts the gamestate to change to RESTART.



RESTART:  Similar to GAME_INIT.  The state clears the active screen and returns to the main menu.


PAUSE:  Upon a right-mouse click during game play, the gamestate is updated to PAUSE.  This state freezes the current screen and allows the user to return to the main menu by clicking on the “E” that appears in the upper left corner of the screen.


Game Menu and Paused Game


4.3 City Generation


The city generation scheme draws the five cities at the bottom of the screen according to the status, cstatus[], of each city.  The variable cstatus[] is an array of size citycount which is set to five cities.  The array is indexed by a city index, c_index.  No more than once city is drawn in any own frame which means that the c_index is updated in each frame to keep track of which city should be drawn in the next frame.  If there is a change to the status of a particular city in the execution of the frame due to a missile impact, c_index is set so that the city will be updated immediately in the next frame.  The set of possible city states includes healthy (2), wounded (1), and dead (0).  These states correspond to different images in the city bitmap array that is stored in flash.  A special function, video_putcity, is used to send the city bitmap to the television based on the desired x-coordinate of the left corner of the bitmap image.  An array of x-coordinates for the cities is stored in the variable cx[] which is indexed using c_index.  The y-coordinate of each city is the same and corresponds to the bottom of the active screen.


4.4 Interceptor Generation


Similar to the city generation scheme, the interceptor generation scheme uses an array to track the status of interceptors, an interceptor index to map into the array and a counter to keep track of the number of interceptors fired.  The interceptor status array, istatus[], is  of size max_intercept which is set to five.  The status array is initialized to zero for each index value.  When the game begins, the interceptor state is called periodically to check for a mouse click indicating the player's desire to launch an interceptor missile.  If the total launched interceptor count, icount, is less than max_intercepts, then an interceptor is generated.  All interceptors begin at the same location at the bottom middle of the active screen.   


For the purposes of calculating interceptor trajectories, we have separated the active part of the display screen into a grid.  The active screen is 128x78 pixels in size, which has been separated into 42x26 target boxes with each box occupying a 3x3 pixel area.


The interceptor generation scheme determines which box the target is located in and automatically resets the target location as the center of that box.  This targeting approximation is acceptable because the explosion size exceeds the size of the target box, therefore destroying all missiles within range.  Once an interceptor is generated, the corresponding istatus[] bit is set to 7 which indicates the missile is alive.  The states 5-6 indicated partial detonation and the states 1-4 indicate full detonation.  These states are necessary to display the evolution of the explosion over multiple frames.  Finally, state zero indicates a dead interceptor.


If no mouse click is asserted during the execution of the interceptor task, no new interceptors are generated.  However, one existing interceptor is always updated based on the present i_index during the execution of the interceptor task.  The (x,y) coordinate of each interceptor is tracked in the variables ixp[] and iyp[] which are indexed by i_index.  The position is updated by adding the appropriate sine or cosine value from flash to these variables.  The cosine and sine tables are indexed based on the number of the x-box and y-box representing the target box.


4.5 Missile Generation


In designing the missile generation scheme, we first agreed on certain parameters.  We decided that the missile launch location and the launch angle would be random. Additionally, the y-velocity would be constant according to difficulty level, with only variations in x-velocity determining the incoming angle.  Finally, the number of missiles on the screen is determined only by the initial level selection made.  We have a time2gnd[] array that tracks the time remaining until each of the generated missiles reaches the bottom of the screen.  Regardless of whether the missile has been destroyed in transit, this timer is updated until the maximum value is reached at which point a replacement missile can be generated.  However, when the missile is destroyed, another counter also begins and continues updating until it has reached ~6.7sec.  If this counter reaches the maximum value before the time2gnd[] counter has completed, a replacement missile is generated.   This system of multiple missile counters is necessary to minimize penalizing the player for shooting the missile down while maintaining the pace of the game.


We accomplished all of these things in our program by making extensive use of the Mega32's flash memory. The program determines the angle at which the missile will be shot from by taking the current number in fastcount, a variable that can be any of the values 0-19 and is incremented once every line of video generation.  This number is divided by 2, which results in temp, a number from 0-9.  The missile is shot at an angle of 45-10*x.  To determine the start position, we use an array in flash with the minimum start location that would result in the missile landing on the screen for a missile with the given angle, as well as an array with the distance above that minimum that the missile could launch from and still hit the ground on screen.  The remainder of division of a second random number between 0 and 249 by the value in the second array is added to the value in the first array, which gives us a semi-random location for the missile that still guarantees that the missile will not fly off screen.


In order to continue to draw the missiles we made another two flash arrays that are indexed by the difficulty level that the user has selected.  One is the y increment, which depends only on the level, while the other is the x increment, which depends on both the level and angle.  By pre-calculating all of these values we saved a great deal of processing time and RAM.  Each time we redraw a missile (once per 8 frames) an appropriate increment is added to both the x and y position of the missile.  Using fixed point addition we can change the position by as little as 1/256th of a pixel.


The missile's status can change before it hits the ground because of three different conditions: It hits a city, it hits a missile (in flight or exploding), or it hits another missile as it is exploding.  In either of the later two cases the missile will explode and regenerate after 50 more cycles. The city collision detection is done by checking the status of the pixel that the missile is moving into and checking if the missile is within the 8x16 box of any of the cities.  In order to check for a collision with an interceptor, the program checks if there is an interceptor within a certain number of x and y coordinates of the missile.  This number is determined by the state of the interceptor (flying, partially exploded, or fully exploded).  The number is slightly larger than the drawn object to take into account shock waves created by the explosion, and to make the game actually playable.  The same detection is done for all other missiles, except we only change the status of the current missile if the other missile is exploding so missiles can't blow each other up by simply running into one another.  If a missile hits an interceptor the score is increased by 10 times a numerical representation of the difficulty level (it's difficult to multiply anything by a dead Soviet state).  If a missile is destroyed by another missile, the score is increased by twice as much, thus rewarding the user for chain reactions and for using those rouge bastards' own weapons against them.


4.6 Lessons Learned


The main lesson learned was to utilize flash memory whenever possible to reduce the number of unnecessary arithmetic calculations, particularly those involving multiplication and division, in the main program.  By pre-calculating a set of possible trajectories for the missile and interceptor, and placing the associated sine and cosine tables into flash allowed us to simplify the game design.  However, since the sine and cosine values are fractions of an integer it was necessary to use floating point flash which introduced complications in the game when the floating point flash value was added to the current x and y position of the missile or interceptor.  This problem was circumvented by scaling the sine and cosine tables by 256 and truncating the value to be a character.  Additionally there are two versions of each x and y position variable, one long and one normal.  When the position is to be updated using the scaled sine or cosine values, the value is added to the long version of the position which is subsequently right shifted by eight bits and stored in the normal x and y position variables.  The normal variables are then used as the coordinates for video generation.  This scheme has the advantage of using shifts rather than multiplication or division which improves the execution speed of the code.


A painful lesson learned, after a few hours of testing, is that it is a poor idea to assign ixp[] the value that you meant to assign to iyp[].  This creates interceptors that rain down from the sky!


We also decided against plotting the path that each missile had traveled because it introduced unnecessary complications when crossing paths had to be cleared or a local interceptor detonation cleared part of the path.  Furthermore, with large numbers of missiles and interceptors, the screen became cluttered with missile lines.  We feel that the current implementation of the missiles and interceptors as single pixel points makes the game more visually appealing.


Also, we have learned that it is unwise to purchase RCA cables from Radio Shack and that asking for a single 9-V battery makes retailers sad.


5. Results


5.1 Performance


The game performs well despite the limited amount of video that is updated in each frame.  We allocated almost all of our available 2048 bytes of SRAM to program variables and used nearly 50% of the 32 Kbytes of flash.  The explosions that are drawn for intercepts are executed smoothly without a noticeable flicker. 


5.2 Safety


From the designer's perspective, the circuitry involved uses voltages below 15-V and there are few connections that have to be made beyond the prototype board circuitry.  Once this is completed, the game designer uses exposed wires to connect the signal generation pins on the prototype board to the television.  However, these wires are safe to touch and there is no excessive electrocution risk.  Structurally, the components are small and safe to handle.


5.3 Interference


The noise emitted from our signals is not enough to interfere with FCC regulated transmission, so we are not concerned with interfering with RF devices.  However, our game may interfere with the player's motivation to do something more productive with their time.  Nevertheless, this is a small price to pay for such a valuable historical teaching tool.


5.4 Usability


Missile Command is easily usable by sighted individuals with average motor control.  Although the title, menu, and score information is written in English, the simplicity of the interface and intuitive nature of game play makes it likely that anyone will be able to pick-up the game quickly.  The two MCUs are attached together and are easily portable.  This hardware can be connected to any NTSC television with an appropriately spliced video-in connection.  The hardware also interfaces with a standard PS/2 mouse.


6. Final Remarks


6.1 Expectations


We are satisfied with our design of Missile Command.  It provides the feeling of despair that we had originally set out to create.  The game is sufficiently challenging without the use of Multiple Independently targetable Re-entry Vehicles (MIRVs) but the next iteration of this game could incorporate these sly tools of diplomacy.  The MIRVs would be displayed as inbound missiles that split off into multiple inbound missiles at a certain point on the screen.  Furthermore, we had originally planned to design the missiles such that the path they had traveled would be highlighted.  As discussed in Lessons Learned, we found this to be cumbersome and visually distracting.  An improvement on the current design could incorporate sound effects to further instill fear and hesitation in the player.  Our plan was to incorporate sound if we had extra time but found the basic game design occupied most of our time.


6.2 Standards and Intellectual Property


See Section 2 for relevant discussions.


6.3 Ethical Considerations


Missile Command conforms to the IEEE Code of Ethics.  Our game is intended to entertain users while educating them about the consequences of nuclear warfare through a safe medium.  We have attempted to acknowledge all existing sources that have inspired our game and given credit to those that we have used software code from.  Although some foreign nations are characterized as antagonists in this game, we do not seek to stereotype the citizens of these nations nor do we support any form of discrimination based on individual ideology.  For the purpose of this game, we have made gross simplifications of the nuanced relations that exist between nations.  Through our work, we have attempted to support the technical advancement of our fellow students.


IEEE Code of Ethics

1. to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment;

2. to avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist;

3. to be honest and realistic in stating claims or estimates based on available data;

4. to reject bribery in all its forms;

5. to improve the understanding of technology, its appropriate application, and potential consequences;

6. to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;

7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others;

8. to treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin;

9. to avoid injuring others, their property, reputation, or employment by false or malicious action;

10. to assist colleagues and co-workers in their professional development and to support them in following this code of ethics.


7. Appendix


7.1 Hardware Schematic


Mouse and Video Prototype Boards (MCUs) with Atmel Mega32s


Video MCU-Television Connection


Table of Corresponding Pin Configurations






















Note: Pins 5, 6, 7 on PORTB must be disconnected during chip-programming



7.2 Cost


7.3 Partner Tasks


Brian Smith

Custom PC Board construction

Soldering Wizardry

Mouse Code Modification

Game Software Architecture

Game Code Development

Code Testing & Debugging

Moral Support & Commiseration


Cem Ozkaynak

Game Software Architecture

Game Code Development

Menu Code Development

Code Testing & Debugging

Moral Support & Commiseration

Website Construction


7.4 Extra Pictures


Game Play


Mouse MCU


Video MCU


Lab Setup: Two MCUs, STK-500, Mouse, TV


7.5 Mouse Code




7.6 Missile Code




7.7 References


ECE 476, Cornell University



Adam Chapweske’s General PS/2Mouse/Keyboard Protocol:



Minesweeper Project (Chee Ming, Chaw and Elaine Siu)



Richard Lawrence’s 1999 article “Legalities of Emulators”



Atmel Mega32 Datasheet