Missle Command video game using Atmega32
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.
For more detail: Missle Command video game
Leave a Comment
You must be logged in to post a comment.