-
Power trouble
08/16/2019 at 20:40 • 0 commentsOne 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
08/14/2019 at 00:13 • 0 commentsI 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
08/12/2019 at 19:45 • 0 commentsThe 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
08/12/2019 at 01:18 • 0 commentsThe 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
08/02/2019 at 19:57 • 0 commentsI'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.