Project Summary/Goals

A tic-tac-toe game was designed. It was programmed for two players, with the game
recording whose turn it was at a particular time. Possession of a square was indicated by
the lighting of either a green LED (representing x’s possession of the square) or a red
LED (representing o’s possession of the square). The initial project proposal discussed
the possibility of incorporating a sound with the claiming of each square. However, it was
decided to leave that out of the actual project due to time constraints.

Error checking was incorporated into the program, prohibiting selection of the same
square twice. The game continually checked for two scenarios: a winner (3 in a row), or
if every square had been selected without a winner. The game board’s lights responded
differently to each of these cases to indicate completion of the game.

Project Status Reports #1, #2

Background

This was a valid and worthwhile project because it provided insight into the
programming and using the 8051-family micro-controllers. It also reinforced the ideas of
hardware/software co-design and simulation. That is, preliminary code was written as
soon as a sufficient design was accepted by all members of the group. Several changes
were made in both software and the hardware design throughout the process. When the
hardware was actually implemented, we had a good idea that the software functioned
properly due to it’s simulation earlier in the process.

Another worthwhile aspect of the project was the initial tic-tac-toe design (see website)
used several components which were discussed in the Digital Systems Design class, such
as PNP transistors and the crystal oscillator. Likewise knowledge of circuits and
programming was essential to the successful completion of the project.

Code

For the code which runs the tic-tac-toe game, follow this link:

Schematics

Initial Design
Final Design
Connections from 89C51RC2 micro-controller used in our project
Photo of final project

Final Parts List

 1 Solderless breadboard
  Breadboard wire
 89C51RC2 -Controller
 Momentary push-button switches
o Quantity: 10
o Vendor: Digikey
o Description: Light Touch Bi-directional Switch
o Price: $1.0920 each
 Red LED
o Quantity: 10
o Vendor: Digikey
o Description: LED, red clear, round, flat top
o Price: $0.215 each
 Green LED
o Quantity: 10
o Vendor: Digikey
o Description: LED, green clear, round, flat top
o Price: $0.224 each
 470  used limit current through LED’s
o Quantity: 20
o obtained in HKN Student Projects Lab
 10 K resistors for the pull up resistors not present on port 0 of 8051-family
o Quantity: 8
o obtained in G-10 lab of EE building
 1 capacitor from output of voltage regular to ground of voltage regulator
o Quantity: 1
o obtained in G-10 lab of EE building
 7805 5V voltage regulator
o Quantity: 1
o Vendor: Radio Shack (Rolla)
o Price: approximately $1.70
 Oscillator crystal
o Quantity: 1
o Vendor: Digikey
o Description: 11.0592 MHZ Quartz Crystal (HC-49)
o Price: $0.80
 9-Volt battery
o Quantity 1

Summary of Simulation Techniques

Software
To simulate the software, the code was compiled and the debug scenario was
started in Keil -Vision software.
Tin the debugger, values on Port 0 and the first pin on Port 1 were manually changed. 
This basically took the role of switches being individually pressed. Then all of the other
variables were checked to confirm that they were what they should be with that particular
switch simulated as pressed (game board got the right player in the right position, proper
LEDs were lit, a winner was detected when it should be, etc.).  Scenarios such as two
switches pressed at once, and other erroneous possibilities were entered to determine the
reactions of the other variables.  If a reaction was not a desired one, the code was
changed to fix it.  Once the program simulated without problems, it was loaded onto the
microprocessor. 

Hardware
Simulation in hardware was largely a process of trial and error. Many versions of
the program (and test programs) were flashed to the microprocessor in this portion of the
project. If the program was not running correctly, voltages on switches and pins were
measured to possibly detect what part of the hardware was not functioning properly. At
this stage, confidence was high that the code was correctly written, since software
simulation had been completed. Therefore, it was largely assumed that any problems
were due to hardware glitches.

Operation of Tic-Tac-Toe Game

The logic of the tic-tac-toe game is very simple. It follows the basic rules of standard two
player tic-tac-toe and doesn’t allow cheating. The game is played as follows:

1. Turn the game on. This is currently done by plugging in a 9V battery into the
appropriate connector.
2. Press one of the nine game switches to make a move in the spot associated with
the switch you have pressed.
3. Allow your opponent to make his/her move.
4. Continue until the game is over.

The 8051 handles the task of determining whose turn it is, lighting up the appropriate
LEDs, and determining if there is a winner. The basic microcontroller operations, as the
game progresses, are as follows (assuming that power has been attached and the “Reset”
button has been pressed):

1. The green LED is lit up to indicate that it is green’s turn (green always has first
turn).
2. The switches are scanned by a while loop until a switch is pressed—which
effectively grounds the microprocessor pin to which it is connected.
3. It is determined which switch is pressed by calling a location function that looks
for a low pin voltage on the pins connected to switches. The only grounded pin is
the pressed switch.
4. The switch location (and the player that pressed it) are stored in a three-by-three
game board array.
 5. A check is run to see if there is a winner by calling a function that looks at the
data in the game board array and returns the player who won and where they won.
6. If there is no winner and no CAT (non-winning, complete) game, the LED of the
move made is lit up by grounding the pin connected to the LED corresponding to
the player and the position.
7. The current player is changed to the other player and the cycle is repeated.
8. If there is a winner, a function is called which turns off all LEDs but the ones that
correspond to the three locations that constituted the win and color of the winner
and also the player LED of the winner.
9. The computer then waits for the reset button to be pushed (tied to Vcc) to begin a
new game.

Work Distribution

Project Design – Butchko, Hargis, Wingett

Code – Butchko
Code/Software Simulation – Butchko
Web – Wingett
Reports – Wingett, Hargis, Butchko
Schematics – Butchko, Hargis
Parts – Hargis, Butchko, Wingett
Hardware Assembly – Butchko, Wingett, Hargis
Debugging – Butchko, Wingett, Hargis, Jackson
Presentation – not completed yet
Administrative – Hargis

Project Results

The completed tic-tac-toe game met all initial project goals, except the possibility of
incorporating a sound when a space was claimed by a player. That feature was neglected
because the team decided to limit the complexity of the project. The project was a
success, even though at this point we are not sure why the last switch (tied to a different
port than the others) does not work.

Some valuable lessons about design were gained through completion of this project.
When we first began our project, we very quickly came up with a design and began
coding for it. (See our first design schematic and code: WEB ADDRESSeS). We had not,
however, sat down to consider if our first design was the easiest, quickest and least
expensive to implement.

We followed this design through to successful simulation of the code, and obtaining all
the parts. After all of that work, we discovered that port 3 could be used as a general port,
just like ports 0, 1, and 2. Therefore, we had enough ports/pins that we could tie each
individual LED and switch directly to a pin. This was a much simpler and cost efficient
design. Although it was late in the process, coming up with a better design was a great
success, and probably saved us headaches when it came to building and testing the actual
device. It was noted, however, that our initial design would be better if the design needed
to use the fewest pins possible, or if other parts were taking up space on some ports.

In future projects, it would be a wise idea to read some pages out of the parts manual on
the microprocessor before beginning, so specifics about the chip are known.

Reading the parts manual would have also helped in the hardware testing and final
debugging stages of the device. We found out that port 0 needed pull-up resistors external
to the chip. We also found out that it was necessary to tie the EA/ pin high to read from
internal memory, and to tie the PSEN/ pin high while resetting the chip, but allowing it to
float after reset.

This project could be expanded to include the ability to play against the computer. It
could also incorporate the sound feature discussed earlier (however any extra devices
could mean partial redesign, since we used all but a few pins on the chip).