Rationale

For our final project, we knew that we wanted to make a video game of some sort, but we had trouble finding the right one. To narrow down our choices, the game had to fit the following criteria: (1) it should have the right complexity to be a 476 final project; (2) it should be familiar to people; (3) it should be enjoyable to play. After searching through numerous video game sites (see References), we stumbled upon Frogger, one of the CLASSIC 1980's arcade games, and our inspiration for this project.

Background: About NTSC Signals

Televisions use a raster to blast out pixels onto the screen using an electron beam in a "Z"-pattern. The beam starts in the upper-left-hand corner and moves quickly across the screen producing one horizontal line on the TV. When it reaches the right-side, the beam turns off and moves back to the left-side and starts over again. This process repeats itself until all the lines in the frame have been outputted.

Each line starts off with a horizontal sync pulse that is about 5 ms long. This tells the electron beam when to start a new line. To signify the start of a new frame, a vertical sync pulse is used. A vertical sync pulse contains three lines (each about 63.5 ms long) and two horizontal sync pulses.

To reduce flicker, each image is split into two frames. The first frame contains the odd lines, while the second frame contains the even lines. Each frame fills the entire screen, but only paints every other line.

Logical Structure

Our project can be split up into the following categories:

• The Game
• Sound

The Game
The game is the core of our project. This is where we display Frogger onto the screen and get user input from the keypad. We use the Atmel Mega32 Microcontroller with the STK-500 Development Board, which runs with a 16.0 MHz crystal and contains 2 KByte internal SRAM.

Sound
We added sound after we completed the game, using Timer2 on the Mega32.

Hardware/Software Tradeoffs

Our biggest concern is being able to display all the images within 1/60 s. This means that our code must execute within this time, otherwise, there will be image corruption and/or flicker. In order to display the images necessary for Frogger while still complying with NTSC standards, we were forced to display portions of the entire image in different frames. The delay caused by using different frames is not really noticeable to the human eye.

The internal SRAM is another limiting factor for our game. This limits us from displaying at a higher resolution. With 2 KByte SRAM, we have a resolution of 128 x 100 for our screen. If we have more SRAM, we would be able to display more pixels.