I'm past due so....
This project has had a lot of set backs so there isn't much point in really discussing much of anything. However, I did say I would put something up....
Microsoft thought it was a good idea to reorganize my directories in a recent update so it's taken me a while to sort the mess out. Besides, every time I try to write something out, it comes off as sounding... meh....

It's a wall mounted cab. The "painting" Sketchup did looks like crap, but I'm not inclined to make it "nice" since it's a WIP and I don't want to fuss with painting it when I make my changes.
Originally, I wanted the acrylic to be curved on all four sides, but as I was playing around, it proved too difficult without investing in a vacuum table (something I always wanted since I was a kid but never have the room for it).
As a compromise, I added metal bobs at the top and bottom leaving only a curves on the left and right, something I think is far more doable with my current tool set. I came up with this design about a year ago, and now that I look at it again, I think it looks too much like a pill stuck to a wall. I might add a marquee across the top.

The joysticks are gone and replaced with knobs. I tested a design using hall effect sensors and magnets for longevity but I'm not sure if I'll go with it or Plain Jane pots or even a slotted disc. Even from the first revision, I always intended the CP (tube?) to hinge open to allow access to a set bolt that holds the cab in place on the wall. Remove the bolt and the entire cab can come down for maintenance.
Not sure if it's obvious but the knobs are supposed to be clear (acrylic I suppose) to allow LED lighting. A thin band behind the cab acts as a diffuser for a set of LED's as well, kind of like lit T-Molding. Originally, I needed it because I couldn't rely on my calculations for depth to be dead accurate and the band was intended to be adjustable to allow for any miscalculations on my part. Since I redesigned the playfield to be even thinner, it's likely no longer necessary. The unknowns are now the motor mounts and the open frame PSU which I haven't picked out yet. I did have a cardboard template of the playfield but I realized too late that it was destroyed in an accident involving the cat. Needless to say, I like some of the design choices that Space Base did so I'm likely to integrate that in the final cut.
There are no back lights for the score holes. I just can't stand how LED lights look in that set up. Instead, I decided to juggle some of the materials around and use light rings instead. My tests show a shitload of soldering in my future... oh well. Unfortunately, the cardboard mockup didn't survive the cat. I honestly didn't think the cat would play with the magnet wire. Can cats get lead poisoning?

Long ago, I had originally intended for the entire thing to be comprised entirely of AVR's, but since the project was in cycle for so damn long, that has changed as well. The sensor array is comprised of AVR ATiny828's (a project I called Starfish though I'm not using five AVR's anymore). There isn't much to show since my old post except for a ton of updated Assembly. Doubt if any one cares about that. I misplaced my test rig for the t828 and the t828 itself so when that bubbles up, I'll take a photo of it. Oh crap.... I think it's in the cat.

I still have not selected a "master" controller for the game logic yet. I've been doing all my testing using the
Atmega32U4 MT-DB-U4 from MattairTech
The display went through all sorts of crazy designs including 8-segment LED display run by an Atmega328 until I finally realized using an Android would net me some awesome benefits. Below is a screen shot inside the developer environment. Yeah, sorry, I didn't realize the red on red was going to be a problem. I didn't think it was a good idea to yank Space Base's art for testing. The resolution of the original image is a bit off so it's stretched but that's OK, it was a crazy bug that took a while to get working right. The "engine" I developed uses a static back image, a "player" field that can be controlled and a front-field that may or may not be animated as desired. Right now, this iteration only accepts hard-keyboard input, but the next version will expand to serial support (once

Windows 8.1 lets me install my drivers

thanks for being retarded MS). Eventually, full sound will be implemented as well as full updates via network. The Android gives me the access I need to the SD card so the game can actually receive updates simply by copying the appropriate files then selected in the "Service mode" menu. The cool thing is the game logic need never be updated to support any new sound or graphics. But just in case, I can hypothetically, I can package the microcontroller binary inside the APK and post it up at the Android Play store and push my updates out. A customer of 1 is more than none... right?

The "LED" display is actually nothing more than an Android tablet displaying a simple PNG file and has slots (essentially sprites) for 128 (equal to a 7 segment display) defined by an XML file. There is a second XML which has some limited behavior definitions. For example, a single key on the keyboard properly increments the lower four digits (Once I figure out how to extract a video from the emulator, I'll post that). Or the digits can be directly accessed in an address-like fashion. Either directly, or indirectly. The slots addresses can also be redefined in the second XML file allowing for smaller image files that don't have all 128 permutations.
edit: fixed typos