Reflex Game using MC9S08QG4

When the display shows "0," players must turn on their light switch as quickly as possible. The player who activates their light switch first is declared the winner. It is important to note that the display does not immediately show "0" following the "3," "2," "1" countdown; this occurs sporadically when certain random conditions are met. The game operates entirely on randomness and alternates between various "game modes," including counting up and down (by 1 and 2) as well as displaying random numbers. These modes can function at either normal or fast speeds, with a specific probability of randomly reaching zero or displaying zero after the "game mode" concludes. A random selection of game modes is initialized before the game commences, and each mode can be repeated a predetermined number of times. The game modes are executed in a random sequence, with game durations typically ranging from 15 seconds to 5 minutes. Some players prefer the brief games lasting 15 seconds or less, while others favor the more intense sessions lasting up to 5 minutes. The game introduces entropy, which is utilized in subsequent calculations, based on the time difference between a player starting the game and flipping their light switch. An example game setup involves the 8-bit Freescale MC9S08QG4 microchip. Two pins from the MC9S08QG4 are connected (with pull-down resistors) to two light switches that provide player input. Three additional pins are connected to the inputs of a 74LS47, which drives the display. The firmware for the MC9S08QG4 was developed using Freescale CodeWarrior in C and assembly language. A note regarding CodeWarrior: it is not ideally suited for code editing, as it does not auto-tab correctly, and the auto-complete feature is non-functional. Code was primarily edited using jEdit and then copied into CodeWarrior. However, its features like Device Initialization and reliable operation upon first connection are commendable. The circuit diagram and associated custom parts library were created using Eagle CAD's free version, developed after the circuit was physically built, wired, and tested—this explains the omission of the "on" switch. The MC9S08QG4 operates at 3.3V, which is accommodated by using only two of the three AA batteries (1.5V + 1.5V = 3V ≈ 3.3V). A 100nF bypass capacitor and a 10µF bulk capacitor safeguard the MC9S08QG4 against power fluctuations. The 74LS47 display driver converts binary input from the MC9S08QG4 to decimal output for the 7-segment display. The 74LS47 includes its own 100nF bypass capacitor, which is not depicted in the circuit diagram. The HDSP-5551 common anode 7-segment display was chosen due to prior availability. A 390-ohm resistor is used between the display and the 74LS47, based on surplus stock. Although the display draws approximately 24mA of current, the resistance could be optimized (5.5V / 24mA = 229.2 ohms). The light switches are standard inexpensive models obtained from Home Depot, wired with a 10k pull-down resistor to prevent floating pins at the microchip inputs. Debouncing is not implemented, as the switches are large and not connected to interrupt-enabled pins, and the game is designed for reflex-based responses without delay from debouncing processes.

The circuit design for this game leverages the Freescale MC9S08QG4 microcontroller, which is well-suited for handling the input and output requirements. The microcontroller's two pins connected to the light switches allow for quick detection of player inputs. The use of pull-down resistors ensures that the inputs remain stable when the switches are not activated, preventing erroneous readings. The 74LS47 display driver is crucial for converting the binary signals from the microcontroller into a format suitable for the HDSP-5551 7-segment display, which visually communicates game status to the players.

Power management is effectively handled with the choice of capacitors, which provide stability to the microcontroller's operation. The circuit's design is optimized for responsiveness, ensuring minimal latency between player input and display output. The microcontroller's firmware is responsible for managing the game logic, including the randomization of game modes and the timing of the countdown. This design exemplifies a straightforward yet effective approach to creating an engaging electronic game that relies on rapid player reactions, incorporating both hardware and software components cohesively.When the display reads "0", players turn on their light switch as quickly as possible. Whichever player turns on their light switch first is the victor. Don`t get the wrong impression-the display doesn`t go to "0" right after the "3" "2" "1" countdown-this only happens once in a while when all the random conditions are met. The game is completely random and shifts between different "game modes"-counting up and down (by 1 and 2) and random numbers. It can do all of these in a normal or fast speed. It can do these with a certain chance of randomly going to zero, or going to zero after the "game mode" is finished. A random number of game modes are chosen and initialized (randomly) before the game starts. The game modes each can be repeated a certain number of times. The game modes are then iterated over in a random order. Games usually run from 15 seconds to 5 minutes. Some people enjoy the short games lasting 15 second or less-especially me-while others enjoy the wrenching games up to 5 minute long.

Entropy is introduced (and used in subsequent calculations) by the time difference between a player turning on the game and flipping a light switch. An example game: The game is built around the 8-bit Freescale MC9S08QG4 microchip. Two pins on the MC9S08QG4 are wired (with pull-down resistors) to two light switches which provide the necessary input from players.

Three other pins are wired to the inputs of a 74LS47, driving the display. I was too lazy to wire the extra pin to the display or provide support for a third player. I wrote the firmware for the MC9S08QG4 using the supplied Freescale Codewarrior in C and assembly. An off-track note about Codewarrior: It`s not actually suited to editing code. It can`t auto-tab correctly and auto-complete isn`t functional-not that I needed autocomplete for this project. I usually edited code with jEdit then copied & pasted it to Codewarrior. It`s other features like Device Initialization and work-the-first-time-I-plug-it-in are fantastic, though!

The above circuit diagram and ensuing custom parts library were made with Eagle CAD -the free version. It was made after I actually built, wired, and tested everything-which explains why I forgot the "on" switch.

Many people-from hobbyists to industry professionals-make the mistake of designing and reviewing and testing their circuits before building them-well not me! The MC9S08QG4 takes 3. 3v for power. I accomodate this difference from the 5 volt devices (74LS47 and HDSP-5551 display) by only using two of the three AA batteries (1.

5v + 1. 5v = 3v = ~3. 3v). A 100nF bypass capacitor and a 10uF bulk capacitor protect the MC9S08QG4 from fluxuations in power. I use a 74LS47 display driver to convert the binary input from the MC9S08QG4 into the decimal output for the 7-segment display. The 74LS47 does have its own 100nF bypass capacitor not shown on the circuit diagram. I use an HDSP-5551 common anode 7-segment display. The choice for the HDSP-5551 in particular was heavily biased-I already had one. I use 390 ohm resistors between the display and the 74LS47 because I had a large amount of 390 ohm resistors lying around.

Could I do better I think the displays draw around 24mA of current (No I`m not going to check the real value). 5. 5 volts / 24mA = 229. 2 ohms-yes I could do better. The switches are the standard cheap-o light switches (purchased at Home Depot). They are wired with a 10k pull-down resistor-the pins will float otherwise-to the inputs of the microchip.

Debouncing enthusiasts seeking such will be displeased-there is no need to debounce these switches. They are fairly large swithes and not connected to an interrupt-enabled pin. Plus, I do not want to wait for any debouncing business (cap charging or SR-latch computing) to occur, as this is a reflex game. I used the Device Initializer to generate most of the initialization code. I disabled the BKGND pin so that I could 🔗 External reference