- Reflexes v1.0 -

INTRODUCTION -

​The very first game I designed was a gift for someone. It was a simple spinning wheel based on a demultiplexer and a button toggling a clock to a 3-bit counter to start/stop the wheel from spinning.
​It has a lot of design flaws, like having an analog demultiplexer for digital signals or using a hex inverter IC only to use one inverter as the clock. However, designing with logic chips was straight-forward so I knew that I would make other projects based on those. This summer, I had the idea to work on a reflex game.

 The game I wanted to make was 'whack a mole' inspired and I decided on several design constraints:
• Only use logic gates and chips to create the game.
• Have a score board that can go up but also decrement if the player plays badly.
• Make the game playable alone but also compatible as a 2-player game.
• 'Start/Stop' menu, and a tunable game speed.

Using a MCU (Microcontroller Unit) or a FPGA (Field Programmable Gate Array) would have been easier, but since I had time and wanted a challenging project, 'easier' was not necessarily desirable. Furthermore, they would introduce some amount of coding, which is something I wanted to avoid for that specific project.

NB - every schematic shared in this blog post is taken from the Reflexes Schematic
which ​is licensed under a CC-BY-NC-SA 4.0 license and available on the Reflexes product page.

​GAME PAD -

The game pad is made up of a 4x4 matrix made with pairs of push buttons and LEDs. The aim is for one LED to light up at random, then all LEDs turn off, then another random one lights up, and this keeps on going, clocked at a regular interval.

Push Button Design -

• The first part of the design (in green) is the actual button that lets 5V through when it is pressed. The 100k resistor to ground acts as a pull-down to get 0V when the button is released.
• the Second part (in red) is a capacitor used for debouncing. This makes sure that when the button is pressed or released, it directly goes to the correct state.
• The last part (in blue) is a Schmitt trigger, which makes the transients to and from 5V fast enough for the other logic chips in the game to recognize them.

Clock Design -

Clocks are needed in this game to both simulate 'randomness' and to set the correct speed of the game. It is made with an inverter and a low-pass filter as the feedback path. This creates a delay between the chip inverting the input, and the inverted output getting back to the input. This then creates an oscillation that can be tuned using both the trimmer potentiometer and the optional capacitor slot I added as a normally opened jumper in the circuit.

Overall Design for the Gamepad -

It is essentially a 4-bit counter (in green) counting in binary from 0 to 15 that gets decoded to 16 (0-15) different LEDs through demultiplexers (in blue). The 4-bit counter (in green) needs a clock, so the bottom clock (in red) goes very fast and clocks the counter. When the top clock (also in red) is low, it turns all the LEDs off, and when it turns high, the counter stops counting and the LED of the decoded number it stopped on lights up.

For example, when the top 'game' clock is low, all LEDs are off. However, the fast bottom clock (the 'master' clock) keeps on making the counter quickly count from 0-15. When the game clock turns high, let's say the counter stops at '7', so the LED associated with the decoded number of '7' lights up. This can simulate 'randomness' as when the game clock stops the counter, it generally stops on a different number each time.

This means that the game now has a 4x4 matrix of LEDs where they all turn off, then one lights up, then they all turn off, and this repeats indefinitely. Each LED is paired with a button that will be used to determine if the player made a good hit.

GOOD/BAD HIT -

Good Hit Design -

• The first part of the design (in red) is comparing each button with their respective LED signals.
• The second part (in blue) is combining all 16 pairs so that any good hit will send the same 'GOOD HIT'.

• the 'Bad Hit' design is the exact same, but every LED signal is inverted first, so any button press with an LED off will be a 'BAD HIT'.

SCORE TRACKER -

To track the score, I could've used the same counter from the gamepad design, going from 0 to 15 upwards. However, this counter only counts upwards which is not compatible with a score that decrements if the player misses a hit.
The counter used to track the score is a 74LS193, which is a 4-bit counter (0-15) but also has the ability to count down.

• The 'UP' and 'DOWN' inputs (in blue) are responsible for either incrementing or decrementing the count, and are tied to the 'GOOD' / 'BAD' hits described above.

• The outputs (in green) will connect to demultiplexers in a similar fashion as the gamepad, only this time it will indicate the score.

• the preset (in red) is tied to 0, which will be used to reset the score when a new game is played (i.e. when the 'START' button is pressed).

Overall Design for the Score Tracker -

​• As stated above, the 74LS193's output is used to light up 16 different LEDs using demultiplexers (in red), giving a score going from 0 to 15.

• When the score gets to 15, a win is detected and that ends the game (in blue).

• The 'GOOD'/'BAD' hits control the counter (in green).

Finally, the circuit needs some logic to make sure that the counter does not loop back to the extremities, as decrementing the counter from 0 will go to 15, and the same thing applies in the other direction (from 15 to 0). With this, the score can now be tracked, and there is a 'WIN' flag that is high if the player gets to 15 points, which will later be used to end the game.

START/STOP CONTROL LOGIC - 

The control logic is important in order to create a 'menu' the player can get in and out of. This prevents the game from always being in 'play' mode. Hence, managing a 'PLAY' flag is a good way to go in and out of the game, where the game only starts when the flag is high, and stops when it is low.

 Overall Design for the Control Logic -

• the 'START' button and the 'WIN' flag both affect the 'PLAY' flag, which is on when a game is happening, and off otherwise (in red).

• The 'PLAY' flag is latched (in blue).

• The 2-player controls will also change the 'PLAY' flag under certain conditions (in green).

2 PLAYER GAME -

Making the game 2-player compatible was an idea that came to mind later in the design process, but I thought that making a board compatible with itself would be a fun challenge to overcome, and also a satisfying feature to have. The initial idea was to use a jack socket, and connect two boards with a TRS jack cable, but this meant that people could plug anything in the game which is not a good idea. It also meant that for it to be self-compatible, the data had to be both an input and an output, which is not possible. Instead of a jack cable, I decided to use symmetry as a way to separate inputs from outputs.

​ Overall Design for the 2-player Connection -

• Using PCB headers and sockets is a good way to differentiate input from output. Furthermore, revolving around the centre means that a flipped board can connect to another board as its inputs will show in front of the other board's outputs.

• The only required signals to send/receive are ground, the board's 'WIN' flag, and the board's 'START' button.

• Hiding the male headers also means a better security and prevents the risk of unwanted connections.

POWER -

​ Overall Design for Power -

• Using diodes, the input power can either come from a 9V battery or a 12V brick, it is filtered and passed through an on/off switch (in red).

• The input voltage is then regulated down to an unchanging 5V for the entire circuit (in blue).

​​ Overall Design for Low Power Indication -

• This sub-circuit first compares the input power voltage (not the regulated 5V, the inputted voltage) to 6.8V with a zener diode (in red).

• if the voltage goes under this break-down voltage, the base of the NPN transistor (in green) stops being high, which essentially cuts the connection from collector to emitter.

• With no current through the collector to the emitter, the LED (in blue) will light up, showing the 'LOW-PWR' sign.

PCB DESIGN -

​ Initial Stages -

Before getting started with a PCB design for the game, making sure it theoretically works is a good idea. I usually simulate circuits using FALSTAD, but considering this only uses logic chips, it can be simulated using LOGISIM which has models for most of the actual ICs I want to use.
The model of the game worked in logisim, so I could go further with PCB design using KiCad.

Layout and Interface Design -

For a PCB with controls and user interactions it is important to start by placing the controls in a way that makes sense and looks good to the eye. I divided the circuit into all the sub-circuits explained above and gave them a reasonable amount of space and layout. The most crucial part was making sure the symmetry with the connectors would work.

Components Placement and Routing -

After placing the components where intuitive and exact placement matters, I placed the ICs in a way that makes sense with the circuit (i.e. close to the buttons or LEDs they control). Finally, routing the whole board was time-consuming but easy as there was plenty of space.
I made sure to divide up the 5V power rail so as to not overload a single track with too many ICs drawing from it. Using one layer for vertical tracks only and the other one for horizontal tracks only (when possible) is a good way to route a board without quickly making a mess.

CONCLUSION -

Prototype and Results -

I received the PCB and its front panel (also made out of a PCB but with no electrical connections, purely panel design). After building one, it worked but there was several fixable issues. Notably, the game speed was too fast even at its minimum speed, which was fixable by increasing the trimmer's maximum resistance to 1MΩ.
However, I was happy to learn that the v1.0 worked as a whole.

Case Design and Choices -

Using Fusion360, I designed a 3D printed case for the game to protect the components on the back of the board, but also to make it easily playable and transportable. I added an optional battery case on the left side of the game which makes the game larger but easily transportable if battery powered.

All in all, the v1.0 turned out great and only needs subtle changes to get the game exactly as I want it to be. There are still a couple of design flaws, most notably the 'random' source which is definitely not random. After testing the prototype, there are noticeable patterns with a fast clock as the random source, which could be a 'feature' but I think the game would work better  with true randomness (e.g. randomly flipping four bits each game clock cycle).
However, as a side project with important constraints (e.g. only using logic chips), this project turned out to be an enormous success, the game is actually fun to play and can be just as fun as a 2-player speed game. I'm very happy about the design choices I made, and even though Reflexes v1.0 might not go for sale, an improved v1.1 might.

I hope you found this post interesting, all the documents for the Reflexes game can be found on its product page in the 'GAMES' tab if you want to take a closer look at them.

Thanks for reading through :)
​NOH-Modular