Close
0%
0%

Симон

The old "Simon" memory game.... with an evil twist

Similar projects worth following
If you haven't ever seen or played "Simon," go Google it.

Simon done the "normal" way has 4 buttons each with its own color (blue, green, red and yellow). The colors are sort of molded into oversized buttons, so the relationship between the buttons and the color sequences in the game are immutable.

What if that wasn't so?

What if the buttons were essentially white with 4 color (well, really three, but yellow is green+red) LEDs? You could then make Evil Simon (aka Симон), where you still had to match the colors, but the colors could appear on *any* button - not necessarily the one you actually had to press.

The name of this project is "Симон," which is just Simon in Cyrillic script. Because I think if Vladimir Putin was going to make a version of Simon, it would be this one.

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 »

Adobe Portable Document Format - 81.63 kB - 08/14/2019 at 16:22

Preview
Download

sch - 251.66 kB - 08/14/2019 at 16:22

See BOM
Download

brd - 104.17 kB - 08/14/2019 at 16:22

Download

Adobe Portable Document Format - 81.80 kB - 08/12/2019 at 19:12

Preview
Download

sch - 251.66 kB - 08/12/2019 at 19:12

See BOM
Download

View all 6 files

  • Power trouble

    Nick Sayer4 days ago 0 comments

    One problem I didn’t catch with the prototype until very late is that playing a sound glitches the controller. The issue likely is that the sudden power draw from the audio amplifier destabilizes the 3.3v bus. This wasn’t an issue with the GPS talking clock because the amplifier there was run from 5 volts, so the 3.3v LDO served to protect the logic system from the transients. 

    For this project I tried adding more bypass capacitance to the controller, but it didn’t help. So I’ll try adding some decoupling inductance in front of the amplifier. I’ll happily accept power instability there as opposed to on the controller’s supply.

    The other issue I’ve discovered is that noise from the LED rastering is making it into the audio. Hopefully just routing the audio line so that it doesn’t cross under any of the raster lines will be enough (which was not the case on the prototype).

  • New form factor

    Nick Sayer08/14/2019 at 00:13 0 comments

    I normally don't put more than one board design in the pipeline at a time, but I'm really confident with this one, so I decided to make a version as a badge. Yes, I know DEFCON just ended, but hey.

    The new variant is a 3.5" circle. It has some holes potentially for mounting in a case, but it also has a badge clip hole at the top (from previous experience and thanks to @Benchoff the spec for that is a 1/4" hole centered 1/4" in from an edge). There's a double-AA holder on the back and the four buttons are on a centered square on the front with the 4 LEDs on a larger centered square. As a badge, some means of mounting the speaker would need to be worked out, but there are lots of potential solutions to that problem.

  • Details for the flash chip image

    Nick Sayer08/12/2019 at 19:45 0 comments

    The flash chip needs to be programmed with the image of a FAT filesystem inside of an MBR partition table. I've got a mac, and the easy way to do this is to open up the Disk Utility and just ask it to make you a new disk image. For best results, make the image just slightly larger than the total size of the audio samples. Disk image will mount the new filesystem for you. Copy in all of the files required and "eject" the image. Once that's done, you need to pad the image with 0xff bytes to the exact length of the chip. Filling the unused portion of the chip with 0xff is better for it, as you're not needlessly setting bits to 0 and writing blocks of 0xff should be fast, as the chip doesn't actually have to do anything.

    The audio sample files themselves are raw (no header or anything), single channel µ-law encoded 8 bit audio played back at 8 kHz sample-rate. You can turn any audio file into this format with sox. The output file arguments are "-t raw -r 8000 -c 1 -b 8 -e mu-law"

    At present, the code in the controller expects at least 6 files. Files "1" through "4" represent the four sounds for the buttons. The nominal order (remember, the game can rearrange them) is red, green, blue, yellow. The next files are "LOSE_n" (where n counts up starting at 1). One of these is played when the player loses while blinking the correct light/button). The last files are called "WIN_n", one of which will be played when the player goes beyond the last level (which is 250, so it's unlikely an unaided human player could do it, but I wanted the firmware to not crash if it happens).

  • First build report

    Nick Sayer08/12/2019 at 01:18 0 comments

    The first prototype boards came back from OSHPark, and they mostly work. There are a few tweaks to make for the next one.

    Firstly, it turns out the boost converter I'm using doesn't actually have the output shut-down functionality I thought it did. So instead of that, I'll just use a MOSFET to shut down the input from the battery.

    There's also a little bit of ghosting in the LEDs. It's probably not enough to matter, but adding pull-downs on the anode side MOSFET drains fixes it.

    I'm also going to switch the next prototype over to using an SPI flash chip for the audio samples instead of an SD card.

    Meanwhile, the initial cut of the software works. I need to do some tweaks here and there to tighten things up a bit. The game should start playing the patterns back faster the further you go, and I need to work on varying difficulty settings, but the code is up and available for folks to play with.

  • Another evil twist

    Nick Sayer08/02/2019 at 19:57 0 comments

    I've come up with another way to screw with players.

    Originally, I envisioned the buttons being a fixed color. But what if the buttons were just part of the lights the same way the original Simon game was? The difference would be that the buttons are all white. They get their color from the LEDs illuminating them.

    So a "turn" in the game starts with Simon blinking the lights and making beeps in the color pattern required of the player (of course, with the color positions all randomized). Then when the pattern is done, all 4 buttons light up with one color each, which allows the player to know where to hit.

    I think everyone now knows where this is heading.

    There's nothing to say that the button colors themselves must remain consistent. Even within a single turn, they could be made to shift around.

    If I can pull this off, it's gonna be a cast iron bitch to play.

View all 5 project logs

  • 1
    How to play

    Press any button to power Симон up. The LEDs will start a circular pattern. This is the Attract mode. If you do nothing, it will timeout eventually and power off. Your choices are:

    • Green: easy - normal Simon
    • Blue: harder - the sounds will no longer be keyed to the color
    • Yellow: hardest - the positions will no longer be consistent with the color
    • Red: nightmare - when it's your turn, your button colors will also shift around each round
    • Black: impossible - when it's your turn, your button colors will shift around for each step

    To select "impossible" mode, press two (or more) buttons at once.

    Gameplay is simple. Remember the colors Simon shows and repeat the colors back. Get it wrong and you lose. Take too long and you lose. If you can go far enough, you'll eventually win, but I strongly suspect that it's not humanly possible.

  • 2
    Building

    There's no special instructions for installing the surface-mount components. Obviously, make sure all of the LEDs and ICs are installed facing the right direction.

    The AA battery holder mounts on the back of the board. Screw it down using a pair of 4-40 1/4" trumpet head bolts. Use a nylon washer under the nuts to protect the top side of the board.

    The speaker wires are soldered to their holes. Note that because the amplifier is a push-pull design, neither speaker wire is grounded. The speaker is intended to be mounted in a case that's not yet designed. If you're not using a case, then mounting the speaker is left as an exercise for the reader.

    To create the SPI flash disk image, first make a FAT filesystem image inside of an MBR partition table. The filesystem should be slightly larger than the total size of all of the audio samples. The filesystem can be FAT 12, 16 or 32. Load in the sample files and then unmount the image. Pad the image with 0xff bytes to the exact size of the flash chip you're using. The firmware doesn't care how big the flash chip is as long as the "0x03" read command works and the chip is large enough for all of the samples. As a rule of thumb, each megabyte of space can hold about a minute of audio.

    Program the SPI flash chip first. If the controller is programmed, then it must be held in RESET or erased while programming the flash chip to insure the SPI bus is kept quiescent. The FLASH programming header has the same pinout as the traditional AVR ISP pinout, with !RESET being replaced with !CS. The easiest way to program the chip is to wire up a Raspberry Pi to do the job. Connect 3.3v power and ground (pins 1 and 6), the MOSI, MISO and SCK and SPI_CE0_N pins (pin 19, 21, 23 and 24) up to the programming header. Use raspi_config to enable SPI and reboot, then install "flashrom" and use it to program the image.

    Compile the firmware with an avr-gcc compiler and link with avr libc. Program the result into the controller with avrdude and a suitable PDI capable programmer connected to the PDI header.

    Note that neither the flash programming header nor the PDI header are 5 volt tolerant. Use 3.3v only!

View all instructions

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates