The game is centered around an XMega32E5 controller. This controller is nice because it has a 12 bit DAC, which is really easy to use as a digital audio playback system (see also my GPS Talking Clock project). The controller doesn't have nearly enough flash space for audio samples, so to hold them, there is an SPI flash chip. The flash chip has a FAT disk image in it with the audio sample files. There are also 4 buttons and 4 3-color LEDs. The LEDs are in a matrix, where the common anodes are selected by one set of 4 bits and the color cathodes are selected by another 3 bits. There are MOSFET drivers for each to protect the controller. The anodes have pull-downs on them to cut down on ghosting.
The SPI flash chip wiring is fairly perfunctory. It's the one SPI peripheral on the board, so it just gets all 4 of the SPI wires sent directly to it, along with 3.3v power and a bypass cap.
Power for the system is supplied by a pair of AA batteries and a boost converter. The boost converter is the XC9142B331MRT-G. The system has soft power control, which starts with a P MOSFET between the battery and the boost converter. The MOSFET gate has an RC circuit to hold the gate low briefly if it's momentarily brought low (this is principally done to debounce the buttons at power-up). The gate has two mechanisms to pull it down. First, one output of the controller will be an output pin brought low immediately at startup and held that way until the software decides that it's time to power off. The software will then turn the pin into an input (actually driving it high would be bad, as the high state voltage for the MOSFET is not actually 3.3 volts), and the pin will (eventually) be pulled up, turning the power supply off. As a bootstrap, any of the game buttons being pushed will momentarily draw the pin low, where it will then quickly be held low first by the RC circuit and then by the controller. To insure that the buttons are kept separate for the purpose of the controller, a pair of diode arrays allows any of them to pull down the power enable pin, but keeps them from influencing each other otherwise.
The DAC output is fed into an LM4871 push-pull audio amplifier. It's more or less straight from the datasheet. Since it can cause transients on the power bus, a decoupling inductor is before its bypass cap to protect the rest of the system. With a half-way decent speaker, we ought to be able to make some fairly nice sounding audio. The intent is going to be to use audio samples for all of the sounds that go along with each color, plus audio files to mark the end of the game (that is, to taunt the player when they lose).
The firmware sets up timer C4 to run at 8 kHz. This timer will both drive the audio system and give us a tick counter ISR we can use for both to raster the LEDs and other software timing (using an unsigned long counting at 8 kHz would take a bit more than 6 days to overflow, but it's unlikely a pair of AA batteries would be able to power the system continuously for that long). The timer overflow triggers an event on the chip's event router. The DAC is set up to use that event to trigger a conversion. The DAC data registers being empty triggers the EDMA engine to perform a transfer burst to load the next sample. The EDMA engine is configured for double-buffering with two 512 byte buffers in RAM. While audio is playing, the firmware will call a polling routine that will check for either buffer being empty and refill it from the currently playing file. The refill method reads in a half-buffer sized chunk and performs µ-law expansion on it, doubling the size of the read data.
Because it's impossible to light more than one color of LED at a time, the 4 LEDs are rastered by the 8 kHz ISR. We don't need to actually raster them so fast (and on the prototype there was a tendency for the raster frequency to leak into the audio, which sounded nasty), so we only cycle the raster every 10 or so interrupts....Read more »