ECE 476 Spring 2004
Daniel Chituc and Aaron Zahrowski

High-Level Design

The Idea

PONG, a video game that simulates a game of Ping-PONG between two players, has a long and pervasive history, and is said to be the first video game ever created. This game puts two players head-to-head on a PONG “table” using their home television. In the game the players try to score points by getting a bouncing ball past their opponent while preventing their opponent from doing the same to them. Once a player amasses a pre-set number of points, that player is declared the winner of the game.

For our final project, we decided to pursue PONG with a twist. Instead of lateral (when facing the opponent) paddle movement, our game involves movement along two axes, allowing a player to paddle the ball further up the court. This adds difficulty, increases speed of game play, and adds countless possibilities for ball movement.

Logical Structure

This project is a combination of hardware and software design. Hardware involves a digital-to-analog converter to generate the NTSC video signal, microcontroller hardware timers to maintain this signal timing, analog-to-digital conversion of four independent user inputs, and the fabrication of the unit prototype board and two independent control pads.

The MCU software was coded in C, and much of the code length accounts for video signal generation. Our software design controls the look and feel of the game on the screen, interpretation of ADC results from the user controls, game flow, level progression, and hit/win detection, sound and LED interactivity, and a simple, but fair AI scheme for single-player mode.

Hardware/Software Tradeoffs

Much of the MCU computing power and memory is dedicated to producing accurate video signal timing while storing, updating, and blasting out pixel graphics for each frame. Great care was taken in coding the game software, AI, and controller ADC conversions such that it would not adversely affect critical video timing.

User-friendly interaction and paddle responsiveness is a key feature in our design. To accomplish this, we soldered independent controller pads for each player. With a total of four potentiometers controlling the x- and y-positions of each paddle, we required four pseudo-continuous analog-to-digital conversions. The challenge was to integrate these conversions into the video code without causing flicker or tearing. Eventually, we chose to initiate conversions in a round-robin style, while opting to sample the horizontal movement more frequently for a more eye-pleasing effect.

Standards

NTSC (National Television System Committee): We are utilizing the NTSC standard in order to output a video signal to any black and white NTSC-compatible consumer television set. Our signal will be in the form of a single coaxial RCA output, operating at an NTSC-specified 60 Hz vertical sync and 15.6 kHz horizontal sync, and voltage levels 0.0V sync, 0.3V black, and 1.0V white.

Patents, Trademarks, and Copyright

PONG is a registered trademark (USPTO Registration 2611782) used to represent a game first published and licensed by Atari, whose more than 75 game brands were purchased by Hasbro Interactive in 1998. We believe that our implementation of the PONG idea, which includes a virtual ball and two opposite paddles, can be considered fair use. This project is for educational purposes and will not be used for profit nor will it be publicly displayed, and we are claiming no credit to the intellectual property of the original PONG design. The final code, along with this full report and disclaimer, may be publicly available online for educational use only.

Program/Hardware Design

Program Details

Our program begins with the foundation of NTSC standard video signal generation, explained in the Standards subsection of High Level Design. To create a visual image, the microcontroller stores a digital field array of pixels 128 wide by 100 tall and can be updated using line, point, and text routines, each with the capability of drawing, erasing, or XORing the current value. The updating occurs during the end of frame time of, at most, 3.81 ms, during which we must also fit code execution for the game and its major routines. All of our game code exists after video line 231, when the microcontroller is sending the end of frame blanking signal to the television.

The main game board, center line, and static information is generated during the initialization sequence. The main game code, within line 231, is broken into two major sections, GameStart = 0 and GameStart = 1. If GameStart = 0, the game is not in play, and is waiting for user input to begin. During this time, the user may choose to switch between two-player or single-player mode, indicated on screen by “P2” or “AI” in the lower right corner. If the user presses the start button, “READY” appears on the screen, along with a 3, 2, 1 countdown, and the game begins. Initial ball position and direction (NW, NE, SW, or SE) is randomized using a simple overflowing character within the timer.

During game play, the ball is drawn and erased using the video_pt XOR routine. Due to a presumed memory issue of unknown origin, the microcontroller may only handle four to five line draws during a single iteration. Therefore, some erasing procedures, such as erasing the old paddle positions, were implemented using an interleaving every-other-frame scheme. The ball bouncing was handled using absolute positions of the wall, and positions of the current paddles. A score is awarded to a player when the opponent allows the ball to travel past their paddle. We encountered a challenge when implementing these scoring and bouncing algorithms in conjunction with the interleaving scheme of paddle drawing and erasing, as the ball would pass through the paddle if horizontal movement was too fast. We countered this effect by checking to see if the ball was approaching the surface of the paddle within the height boundary of the paddle itself. If so, the ball position was set to move away from the paddle, and the horizontal position was set to just in front of the paddle. This allowed for smooth game play and added the ability to “push” the ball toward the center of the court, an intuitive new dimension to game strategy.

Next, we added various game levels. We chose to base the levels on cumulative score. The first of five levels gives each player a 30 pixel high paddle. As the cumulative score hits 10, the paddle sizes are reduced by 5 pixels. Thereafter, each increase in 5 cumulative points shaves off 5 pixels in paddle size. By level 5, each player has just a 10 pixel high paddle, resulting in a more challenging and interesting game. Once the total game points reaches 35, the game is over and the winner is prominently displayed. Any user may now press the New Game button to reset the scores and start a new game.

Lastly, we implemented a simple artificial intelligence to take over player 2 during single-player mode. The AI follows the ball based on its relative vertical position to the paddle midpoint, but starts off very slow. As the game levels increase, the AI gets progressively faster and more responsive. At the highest level, the speed of the AI paddle nearly matches the vertical speed of the ball. During AI play, the player 2 paddle is kept at the right wall.

We added two interactivity and user experience features that are not part of the core game structure. First, a bright green LED is lit on a player’s game pad when he or she scores against the opponent. Second, every time the software registers a ball bounce off of the top or bottom game court walls, or off of a user’s paddle, an output pin is toggled to drive a clicking sound through a piezo speaker discussed in more detail in Hardware.

Hardware Details

The first component is a digital-to-analog converter, which takes the digital video signals from PD.5 and PD.6 and converts them through a simple resistive network to create the NTSC standard positive component of the RCA output. See a schematic of this network in the Schematics appendix.

Next, we utilized the integrated 10-bit analog-to-digital converter to sample four signals that will serve as the two-dimensional player inputs. By using 4 channels (PA.0 .. PA.3) and using the left-shifted high 8 bits, we achieved very responsive game play for two players in two dimensions. Due to timing constraints, we could not force four conversions per video frame. Instead, we sampled player 1 and player 2 vertical paddle movement once per four frames, or every 66.7 ms. To achieve a more user-friendly rendering of the paddle movement, we chose to sample horizontal movement every other frame, or every 33.3 ms.

The player interface was designed to be comfortable and intuitive. We constructed two prototype game pads on separate mini solder boards. Each board contains two linear-travel sliding potentiometers mounted vertically to control the up and down motion of the user’s paddle, a Panasonic single-turn knob potentiometer to control horizontal movement, and a green LED to serve as a score and win indicator. Power, ground, two analog signals, and LED leads were neatly wound into a cord. Spare socket pins were soldered to the game pad leads to create a convenient male header, which fit into a matching female header soldered to the main board.

Simplicity was maintained in the game interface. Two momentary-action buttons were used to implement Start/New Game (PD.1) and Single-/Two-Player mode (PD.3) functionality. Switching between Single- and Two-Player mode required state-machine button debouncing, whereas the Start/New Game button is polled only until it is activated the first time.

As an addition to the player experience, we decided to implement the classic PONG ball bouncing sound. Each time the ball bounces off of the court wall or a player’s paddle, a piezo speaker mounted on the main board is alternately sunk from Vcc and sourced back to Vcc (PA.7) to create a gentle clicking sound.

Code Reuse

As a starting point for our project, we used Bruce Land’s sample video generation code, available in its original form at http://instruct1.cit.cornell.edu/courses/ee476/video/Video32v3.c, which was made available for the fourth structured lab assignment, the television oscilloscope. Our code consists of new variable declaration, definitions, additions to the initialization routine, and the game engine placed during the end of frame time.

Attempted

When adding sound for an improved, immersive player experience, we anticipated the bouncing noise to be a louder clicking or popping sound. After experimenting with various hardware configurations and software implementations, we chose to use a single port pin to drive the speaker in an on/off toggle fashion to make the clicking sound. Since a port pin is able to sink more current than it can source, we used the pin to sink the speaker current, with its positive lead tied to Vcc. An alternative configuration for a louder popping sound would be to drive the speaker straight from power to ground using a BJT TIP31 toggled by the port. Although this would have been a good choice for the often noisy lab environment, during quiet times, our current-sinking pin configuration is more than sufficient.