Mastermind: Schematics

Once the coding was completed for our Mastermind game we just needed to create two circuits: one for the serial communication between TeraTerm and the A3BU, and one to power the LEDs. The communication circuit was the same MAX232 circuit that was used in previous labs, and can be seen on the left side of the breadboard in the picture below. The circuit to power the LEDs we designed ourselves, and can be seen on the right side of the breadboard.


The LED circuit required several components for each LED leg, including a 1K resistor to moderate the current, and a transistor to provide ground.


In our circuit, the LED leg went to the collector of the transistor, and the emitter of the transistor went to ground. Then the outputs from the A3BU (labeled as inputs in the diagram below because we were viewing them as inputs to the transistor, but they are still output pins) would go to the base of the transistor in order to power the leg of the LED and turn it a certain color.


Mastermind: Code

Rather than jumping head first into coding our Mastermind game in Atmel (see “Smoketown USA – The Big Picture” blog post for overview of the game), we thought it would be a better idea for us to get a version of the game working with just code written in C – using the Dev-C++ Bloodshed Software – and then move forward from there. We started by having the program generate four random numbers between 1 and 6. This would be stored in an array and act as the master code. Then the program would prompt the user to enter four numbers ranging from 1 to 6, and store that in a second array. We could then compare each individual element of the input array with all elements of the master array and then tell the user the necessary information about their guess.

Once we had a solid program that worked just from running it in the terminal, we then moved on to begin integrating it into Atmel with our other components. The first component we decided to tackle was setting up the information for the output pins to drive the LEDs. To do this, we used the IOPORT_CREATE_PIN( ) function in order to define a name for each output pin, as shown below:Code_1

Once each output pin was assigned an LED and a color, we could then move on to writing the logic that would turn on each output. To do this, we basically stored a truth table inside a 2D 15×15 array. Each row of the truth table is made up of five groups of three numbers, as shown in the image below. The first number of a group indicates red, the second number of a group indicates green, and the third indicates blue. The first group of three numbers in each row indicate how many of each color LED there: for example, in the first row it shows 4 red LEDs. The next four groups of three indicate the color that each of the four LEDs need to be. So in the first row, all four groups of three have a one in the first position to indicate that all four of the LEDs should be red.


The truth table was mainly used for comparing with the information gathered from the user’s input. Once we calculated the number of digits that were exact (correct digit and correct location) and the number of digits that were close (correct digit and incorrect location) we could then search through the truth table using a few for-loops and if-statements in order to set each of the output pins for the correct LED and color.


Mastermind: The Big Picture

For our final project, we wanted to try to incorporate several concepts from previous projects in order to show what we’ve learned. There were countless possibilities of what we could accomplish, but in the end we decided that we would create our own version of the game Mastermind. This would allow us to build and program everything ourselves to get it working exactly the way we wanted.

The original Mastermind was a board game involving two players: the codemaker and the codebreaker. The code maker would create a pattern of four pegs, with each peg having a variety of possible colors. The code is covered from the second play by a small shield, and then their job is to guess the code. For each guess, there is a spot at the end of the row for four smaller pegs to indicate whether each peg was either: in the correct location and the correct color, a color in the code but in the wrong location, or a color that isn’t in the code.


We decided to make a few changes to the game in order to make it friendlier to use with the A3BU. Rather than trying to figure out how we could use color coded pegs, we decided to switch from a code of colored pegs to a code of digits. The program would randomly generate a four digit code, with the range of digits specified in the code (we used 1-6 most often), and then the user could enter their guess from TeraTerm. Then we wired up each of the three legs from each LED to the output pins on the A3BU, and these LEDs served as the indicator pegs that showed the player information about their guess. If their guess contained a correct number in the correct location, one of the LEDs would turn green. If their guess contained a correct number in an incorrect location, then one of the LEDs would turn blue. If any of the numbers guessed weren’t in the master code at all then that number of LEDs would turn red.

Here is a sample of our finished product: