ECE476 – Spring 2003

Microcontroller Design

Final Project

Tetris on TV

Designers:

Jeffrey Brzuszkiewicz

Robin Yip

Introduction

For our 2003 ECE476 Design Project, we designed a Tetris game that was playable via a 16 button keypad and was displayed on a black and white television at a resolution of 128x100. The heart of the hardware system consists of the ATMEL Mega32 microcontroller and an STK500 test board. The game mimics what you would expect of the original Tetris game, where you would advance in level (and increase in speed) as you progress by “completing lines” in the game.

Although the game Tetris may seem like a simple program, the limited computing power and memory space of the 16 Mhz microcontroller make this tasks more challenging than one would anticipate. Instead of hooking up a computer to a television screen, we merely used a small microcontroller chip and several simple circuits to implement our design.

We wanted to design a project that would fully harness the processing power of the 16 Mhz Mega32 processor. Yet we understand that performing graphic manipulation on a television screen can be extremely CPU intensive. Therefore, we chose a game that at times had significant amount of graphical changes, but the game for the most part did not require a tremendous amount of calculation during normal game play. Furthermore, debugging the game required hours of game play, which did wonders for our Tetris skills.=)

High Level Design

Rationale/Sources of Project Idea

We wanted to design a project that would fully explore the processing power of the 16 Mhz Mega32 processor. We understand that performing graphic manipulation on a television screen can be extremely CPU intensive, therefore a game of the appropriate level of sophistication was chosen. At times significant processing power was required to handle the graphical manipulations (that are sometimes divided between multiple cycles), but the game for the most part did not require a tremendous amount of calculation during normal game play allowing the processor to catch up. Furthermore, debugging the game required hours of game play, which did wonders for our Tetris skills.=)

Logical Structure

Although the game is in black and white on a television screen, it includes the standard features that you would expect of a Tetris game under any gaming platform. The game initially requests the user to press a button, between one and nine, to select the corresponding level (appropriate speed) for the game to begin in. The game then advances in level (and increases in speed) as you progress by “completing lines” in the game.

Figure 1: Our Tetris Game in action! Figure 2: You got a new high score!!!!!

Don’t forget to enter your initials!

After the initial speed selection, the following buttons on the keypad are used during game play:

Button Assignment for the Sixteen Button Keypad

1 – Not Assigned	2 – Not Assigned	3 – Not Assigned	A – Pause
4 – Not Assigned	5 – Not Assigned	6 – Not Assigned	B – Not Assigned
7 – Not Assigned	8 – Rotate Block	9 – Not Assigned	C – Not Assigned
* – Move Left	0 – Move Down	# – Move Right	D – Send to Bottom

At the conclusion of a game, the high score (and its corresponding initials) is saved in the EPROM of the chip, so that this data is retained even when the system is turned off. At this time, Buttons *, 0 and # are used to change each of the three characters of the high scorer’s initials. The user can then proceed to initiate a new game by selecting a new game speed. Additional features in the game include the ability to see the next block ahead in a small panel on the right and also the ability to pause the game via the ‘A’ button.

Hardware/Software Tradeoff

Our project explored the broad range of applications which software can be used for. We used a highly software intensive implementation to create the television signal, along with the game environment. Some of the television signal generation could have been done with dedicated hardware; however we wanted to explore the ability of the microcontroller to handle the entire task.

Initially we wanted to implement a color version of the game with the help of an RGB to NTSC converter, but due to the limited computing power and memory space on the Mega32 we restricted our design to black and white. Even in black and white, some of the graphic manipulation became quite intense at times, and we were forced to fine tune the code and break some processes down to multiple cycles. Furthermore, if we moved to a color design, we would certainly need more memory space because with close to 2500 lines of code and intense computation from the graphical updates, we were running out of memory space even with our black and white design. (For more details of the obstacles that we encountered…see the Hardware/Software Design section.) Needless to say, moving to a color design in our short time constraint would have been difficult, so we spent our time fine-tuning and perfecting our code instead.

Hardware/Software Design

Hardware Design

The hardware setup consists of an ATMEL 16 Mhz Mega32 processor on an STK500 test board.

Figure 3: Below is the hardware circuitry for our Tetris game. The STK 500 is the green PCB that you see below. The Mega32 processor is a black chip that is sitting on the left part of the board. The video DAC and keypad wiring are on the white breadboard. The black device on the top left corner is the TV where the game is displayed

The following components are connected to each port of the STK500:

(PORTS)	(CONNECTED COMPONENT)
PORT A	A.0 is for audio
PORT B	LEDs (For Debugging)
PORT C	16 Button Keypad
PORT D	D.6 and D.5 are for video and sync respectively

Pin 0 of PORT A is connected to the audio input of the television via an RCA cable connected across a 5K resistor (included to dissipate power), connected between A.0 and ground. All 8 pins of PORT B are connected to the LEDs on the STK500 for debugging purposes.

The 16 button keypad is connected to PORT C of the STK500 board with pins 0-7 of PORT C being connected to pins 1-8 of the keypad respectively. Thus by using a standard key pad scanning scheme in which the first four pins are polled while the second four lines are driven and vice versa the key presses can be detected. A schematic of the keypad is shown below:

Pin 1 -- row 1 2 3 A

Pin 2 -- row 4 5 6 B

Pin 3 -- row 7 8 9 C

Pin 4 -- row * 0 # D

Pin 5 -- col 1 4 7 *

Pin 6 -- col 2 5 8 0

Pin 7 -- col 3 6 9 #

Pin 8 -- col A B C D

(a) Each switch shorts one row to one column.

(b) Each pin should be connected to one bit of an i/o port.

(c) The i/o port pins will be used both as inputs and outputs.

When they are inputs, they should have active pullup resistors.

The video is connected to the television by and RCA cable connected to its video input port. The video DAC is connected to pin 5 and pin 6 of PORT D as illustrated in the diagram below, and the cable is connected across the 75Ω load resistor of the DAC.

Software Design

We utilized the MEGA32 base code for video generation that was provided on the ECE476 website: (http://instruct1.cit.cornell.edu/courses/ee476/video/Video32v2.c) From there, we added a debounce state machine to handle button pushes.

We allocated an area of the screen 64x96 in resolution to display the falling blocks and divided that area to provide space for 16x24 blocks where each block is 4x4 in resolution. To simplify computation during the many manipulation of blocks in game play, we allocated an array of size 384 (16x24) to track the location of each block and updated both the screen display array and block array during any graphical manipulations. Furthermore, for each graphical manipulation, we tried to create separate functions to simplify and consolidate code.

Some of the more challenging parts of the code were creating mechanisms to clear the complete lines and rotate the falling blocks. The most challenging part was clearing multiple lines and redrawing the rest of the lines in the correct location. When we tried to do everything in one cycle, we would experience flickers and artifacts on the screens, so we broke that process down into multiple cycles, where only one line shift would occur per cycle (see the obstacle section below for more details). Also, the rotation mechanism could not be generalized easily so a particular manipulation was done for each block in its various possible orientations.

For sound, we extracted pieces of the sound code from the sample code on the ECE476 website (http://instruct1.cit.cornell.edu/courses/ee476/video/videosnd.c) and modified it to suit our needs. We made the system beep every time a line is cleared and played special music when one advances to a new level or loses a game.

Finally, we began to utilize the EEPROM memory to save a high score which would be saved even when power to the microcontroller was lost. This would allow the high score and players initials to be saved and then loaded each time the game was run.

Obstacles

At a resolution of 128x100, some of the graphics tasks were too intense for the 16 Mhz processor to perform in one cycle. During initial testing, we experienced flickers and artifacts when more than one line were cleared together; therefore, we refined our code by dividing the load over multiple frames, so that only one line is cleared per frame. The divided load eliminated the flicker and there was almost no noticeable visual difference between the two versions during normal game play, once the flickering and artifacts were removed.

Another problem we noticed was the limit in the stack size, if we set the stack size to exceed the limited available memory capacity, the complier would complain about “out of memory for global variables.” If we set the value near the limit of the available memory, we would be able to successfully compile the code and download it onto our microcontroller and the graphics would appear as expected, but the buttons on the 16 button keypads will not respond. Lowering the stack size to a less aggressive value eliminated the problem.

We also experienced problems trying to debug some portions of our code. Some time was spent trying to find what was causing a problem in which dots would be drawn in seemingly random locations on the screen. Because of the randomness of this problem and the limited ways to debug these circuits it took considerable effort to find what was causing the problem.

Results of the Design

Speed of Execution

The speed of operation for our system was of critical importance for maintaining the quality of our video signal. Thus to avoid flickering and other performance degradations other tasks had to be designed to run around schedule of the video signal. We had to make the game functionality, along with any other tasks run in the down time for the video signal in between each frame being output. For this reason some tasks had to be divided over multiple frames and the amount of computation had to be kept somewhat short.

Input to the game had to be done on a time frame which would not interfere with the video. By running a debounce state machine in the down time for the video we were able to effectively keep track of user inputs. There is some tradeoff between the speed with which the button presses can be detected and sensitivity with which game play can respond, however we believe that a happy medium has been reached.

Accuracy

The accuracy of our video sync signals is good enough to avoid any type of flickering or other noticeable performance degradation. The use of a clever scheme to put the processor to sleep between each line of video creates a very consistent sync signal which creates clean video. Our audio tones are accurate enough for our purposes. If we were using it for musical playback we would want a more accurate output, however our accuracy of ~1% is good enough for sound effects in our game. There was some interference between the audio and video when both we occurring. The audio signal seemed to cause some distortion of the video being displayed, probably due to the capacitance associated with the parallel lines that they were run on.

Safety

There are not many safety issues to take into account in our game. Of course periodic breaks should be taken to avoid any kind of repetitive stress injuries or eye strain. We tried to avoid the use of flashing objects to avoid causing seizures in people we are prone to that try of reaction.

Interference with Other Designs

Our design did not use any types of wireless transmission or high power circuitry so noise and interference with other people’s designs was not very applicable to us. Besides some periodic annoying noises our project did not bother the other groups too much.

Usability

The final result of our game was a very playable version of Tetris. The controls take some time to get used to, much like those of any game however after playing for some time the player will get very accustomed to them. The time that we spent playing to debug the game made us very used to the controls, playing the game with total control. We allowed a friend of ours to play the game for to evaluate its playability and after a few minutes of practice he was able to play the game with a high level of control. The game plays as it would on any other platform, without any performance glitches.

Conclusions

Results

Our results matched our expectations fairly well. We were able to create a video game which mimicked Tetris well. The game play has no noticeable flaws and performs just as the original version did on other platforms. Originally we planned to make a color version of the game, however as time began to run down we did not believe we would have time to make the changes associated with changing processors and adding external memory which would be have been needed. So, we decided to stick with the black and white design and use the remaining time to fine tune the game chasing a couple of minor bugs and adding smaller feature to make the game complete. We had also thought of using the controller from a more conventional game pad, such as a Sega Genesis controller however we felt that this was not necessary since the game controllers were easy to get used to and function very well with some practice.

Some recommendations for next time would be:

Test every modification of the program thoroughly. This will help avoid wasting time trying to find errors from simple functions that you assumed which went unnoticed for some time.
Think over your final design carefully so you can start with the final circuitry and avoid changing to another processor in the middle of the design and its associated changes in the necessary code.
Start early and work on the lab frequently, doing what can be done outside of lab to efficiently use valuable lab time.

Intellectual Property Considerations

There is little opportunity for this project to be considered for any type of copyright or patent protections. The idea behind our project was to emulate an already existing video game so our design is not original. The original game was most likely copyrighted, however we are just reverse engineering the software for educational purposes and do not plan to use this for our gain. We also incorporated some of the code and ideas that Professor Land had presented for previous lab experiments in the class. We started with and modified his code for generating a black and white television signal, and also used his sample code for generating an audio signal.

Ethical Considerations

Being electrical engineers we are compelled to follow the code of ethics presented by IEEE. One of their points which we dealt with while working on the project was improving the understanding of technology. This project forced us to look at new types of circuitry that were available and decide upon their appropriate applications and whether or not they would work well with this project. Another point which we dealt with while working on the project was assisting other colleagues. Many people in the lab would be working on similar types of projects, so people would ask questions about how we were able to accomplish something and look for our assistance understanding how something worked. Also, when in the lab people would see the project we were working on and give advice on how it could be improved. It was thus our duty to listen to suggestions and improve our design. When writing up this report and presenting the project in class we also need to represent our project truthfully, realistically representing our results to others. Working in a group as partners caused us to think about the duty to only undertake tasks which we were each knowledgeable enough to undertake. We both needed to make sure we knew how to do the tasks and that we would not be hurting ourselves, wasting time trying to undertake jobs that we did not know how to do. While working on this project it was not too difficult to follow the code of ethics by just doing what we thought was the rite thing.

Appendices

Appendix A – Source Code

http://www.people.cornell.edu/pages/rcy5/final_project.c

Appendix B – Schematics

The 16 Button Keypad is connected to PORT C as illustrated below:

Pin 1 -- row 1 2 3 A

Pin 2 -- row 4 5 6 B

Pin 3 -- row 7 8 9 C

Pin 4 -- row * 0 # D

Pin 5 -- col 1 4 7 *

Pin 6 -- col 2 5 8 0

Pin 7 -- col 3 6 9 #

Pin 8 -- col A B C D

(a) Each switch shorts one row to one column.

(b) Each pin should be connected to one bit of an i/o port.

(c) The i/o port pins will be used both as inputs and outputs.

When they are inputs, they should have active pullup resistors.

The Video DAC is connected to pin 5 and pin 6 of PORT D as illustrated in the diagram below:

Appendix C – Cost

For our final project, we only utilized parts that were provided to us in lab (keypad, television, resistors, etc.); therefore, the financial cost for our Tetris game is ZERO, but the experience that we gained from designing this project was certainly “priceless.”=)

Appendix D – Specific Tasks

Playing Tetris (to debug off course=) – Jeff & Robin

Coding – Jeff & Robin

Hardware Circuitry – Jeff

Weekly Progress Reports – Jeff

Project Webpage – Robin

Appendix E – References

Cornell University ECE476 Video Generation with AVR Microcontroller Reference Guide.

Cornell University ECE476 Lab 5 Handout

CodeVision C user manual

Mega32 summary

Mega32 full data sheet