OXO – Part 1

My original blog post details how I came to start this project and why I chose to see if I could construct this using TTL chips and diodes so I won’t repeat those ramblings here. Instead, let’s get right down to seeing if I can build this or not. 

For me, design is an iterative process. I list a key set of features, start designing at a high level how the circuitry for each feature may look, and then start to integrate the features together until I end up with something that looks like it might work. Typically, I then move to breadboards and spend a lot of time head-scratching, experimenting and hacking around until I get something that works as required. This project seems to be going the same way. 

I started to doodle some ideas and came up with an outline of a solution that I think would work.

The diode AND gate.
I think the hardest part of this will be implementing all the rules. My plan is to build the rules using only AND gates constructed from diodes. The advantage of this is you can, in theory, construct diode AND gates with as many inputs as required.  Each AND gate is constructed from a resistor and one diode per input. 

As you can see, this is a pretty simple circuit that can be extended with as many diode inputs as required.
Now, I’ve been bitten in the past with things that appear simple and then not working as I expect, so took some time to build test circuits to make sure it worked as expected. 

If I’m going to use this diode AND gate approach it’s important that it can interface reliably with the rest of the machine’s TTL devices. I’m happy to report it seemed to work fine. At one point I had my test circuit extended to use 10 diode inputs for the AND gate and it seemed to work flawlessly. 

How the machine will work
The machine will work in a similar way that some CPU’s make use of Microcode to create their instruction set.
Within a CPU, each line in the Microcode sets or clears logic levels on multiple internal control signals, with these signals then controlling how the CPU moves information around internally. The machine described here will work in a similar way.

The heart of the machine will be a sequence generator and its purpose is to select the next rule in sequence to execute.
The rule will consist of one or more diodes that form an AND gate. The inputs to the AND gate are sense signals from the machine including which squares are occupied, and by what. The output of the AND gate forms the result of the rule, and this will be used to trigger or reset different parts of the machine.

Keeping it simple.
To keep things simple, it’s imperative that the sequence generator is also as simple as possible. It needs to only be capable of generating one sequence number after another and I don’t it to support branching (jumping to other parts in the sequence) as this makes things complicated. 

Bringing things together.
Hopefully this gives you an idea of how things could work. 

The above image is a section of my first draft of what the machine rules table would look like.
The table is divided into blocks separated by the green line. The first visible block is the one that checks if the human player has won and has 8 lines or rules. Each rule has a simple description so I can see what it’s supposed to do, and then the clever stuff follows.
Each rule is divided into two basic parts; Sense lines which are the inputs to the rule, and Output lines that are what the rule will trigger if the value of the rule equates to true. An “X” anywhere on the line indicates a diode.

So, the first rule in this section (A+B+C) needs to check if a human player has winning line across the top three squares of the board.
There are currently 4 sense lines representing each square on the board.
Player Square indicates the square is occupied by a human player.
Machine Square indicates it’s occupied by the machine.
Empty returns a logic high if the square is currently unoccupied, and InUse returns a logic high if the square is in use by either player.

Now, some of these signals may seem redundant. For example, if a square is occupied by either player, it’s fair to say the square must be in use. However, adding the Empty and InUse signals makes the logic within the rules a lot simpler and meant that I only needed to implement AND gates within the rules. 

​Whilst writing this text I’ve had some thoughts and the rules table will change, so don’t jump for your soldering irons just yet. 

So, the first rule above checks to see if squares A, B & C are occupied by the human player, and if so, the Player Win LED and Disable Clock lines are set true. In any other condition, the output of the AND gate would be logic low so the output lines would remain unaffected. 

The Player Win LED is pretty self explanatory. The Disable clock signal is used to stop the game as once there is a winner there’s no point carrying on.
In this instance, it would be possible to trigger the disable clock signal whenever any of the win or draw LEDs are illuminated which would save same diodes.

Once the machine has made a move, it’s important that no more rules relating to the machines decision process are executed until the play has made their move. The Reset Sequence Counter resets the sequence counter back to the first rule in the list.

How are the rules selected
I’ve already stated that each rule is selected in turn. If we add another input to the AND gate on each rule, we can select one rule at a time just by simply setting this additional input to logic high. This is the job of the Sequence Generator. 
The Sequence Generator; under control of the Master Clock, selects each rule in turn until 

Features or requirements.
Now I’ve got a fair idea of how things will work electrically, it’s time to make sure I know exactly what I’m expecting the machine to do.

So it must play the game of tic-tac-toe (rather an obvious one but I needed something to start off my list).
Player versus machine. 
Option for player or machine to go first
Hardware needs to make sure the player cannot cheat
Simple user interface consisting of some LEDs to indicate if a square is occupied, and some push buttons to allow for a move to be made

Next task
Now I’ve a pretty good idea of how the game will work, I need to properly document the rules and make sure I know what all the rule inputs and outputs will be. This will give me a good overview of how the final hardware will look.



Leave a Reply

Your email address will not be published. Required fields are marked *