Monthly Archives: April 2015

A pretty good twilight zone topper

Twilight Zone, being one of the top pinball machines with collectors and having a very good theme, has led to it being heavily customized, some of them being functional, but most just being ornamental, to make the machine more fun.

One of the cooler ones was done by a guy who took a small hallmark ornament that looked like a TV, put a small LCD display in it, and then used it to display pictures from the TV series while you played. It’s tiny (maybe 1.5”), and it fits inside of the game. And then somebody else did one that showed video.

I was thinking that it would be cool to do something that was game controlled, which is the whole reason I built the WPC pinball lamp decoder. And, instead of making it a small one that would go on the playfield, I decided to make it slightly larger and make it as a topper.

A topper is simply something ornamental that goes on top of your pinball machine. They are almost always lighted in some way, and, with a few exceptions, not controlled by the machine.

Mine would be. Twilight Zone has a bunch of different modes, and my plan is to detect those modes (and other events) by decoding the light state, and use that to play *appropriate* clips on the topper.

I needed a good enclosure. And, thanks to Ebay, it was simple to procure:

This is an early Sony 5” TV, and it was a bit of a design coup for Sony; nobody was doing TVs this small at the time. I toyed with the idea of just using it as a display, but then I took a look inside:

That is one of 3 circuit boards. These TVs have a reputation for being very hard to work on, and I don’t what that sort of project, so we are going to use it as an attractive case instead…

I plan on using as many of the controls as possible; at least the on/off switch and the volume knob.

For a display, I need a small LCD. I found one that is designed for a rear-view camera. Here’s a test-fitting in the case:

Fits but barely on width, but the height is less than I would like (the display isn’t really 4:3). Hmm. If I put it behind the original CRT protector…

That will likely work better. Assuming I stay with this display (and I think it’s the biggest one that will fit without hacking out the control section on the right), I will laser-cut an oval trim plate out of black acrylic that will cover the gaps. I’ll also modify the lens to get the display more forward.

and one more photo of the display working…

A bit about pinball

You may or may not know that I’m a pinball afficianado. Yes, yes, “ever since I was a young boy, I played the silver ball…”

During the arcade boom of the early 1980s, arcades were everywhere, and while they generally focused on video games, there were always a few pins. I spent lots of time and money on both, but pinball had more of a fascination, for three very important reasons:

  1. If you are decent on one pinball machine, you are decent on all of them. This is very much not the case on arcade machines; your skills on Defender help you when you play Tron, but you aren’t automatically decent.
  2. The physicality is much better. You get to shake the machine. No, you are *required* to subtly nudge and shake the machine while you play if you are going to be a good player. You work on your advanced moves. And you enter a society of players who know how to play the right way. It’s a bit of a craft.
  3. You can win free games. Plus, the difficulty level on a pin is mostly linear; yes, it becomes a *little* harder on most games as your points go up, but it’s not a lot harder. What that means is that once you are good, it becomes easier to get high scores. And, every once in a while, probability and skill will align, you will walk into an arcade, put one quarter into the pin, and play for half an hour, with the game knocking to announce your skill when you win a free game. And then, after that time, you will turn to the 12-year-old kid who has been watching you play and say, “I have to leave. Do you want my games?”

So, anyway, I played a bunch of pinball in my young days, but it tapered off when I got older because pins and vids became much harder to find. You could find them in bars, but I don’t do well with cigarette smoke, so I didn’t play as much as I used to.

Then, sometime in my 30s, I realized that a) it was possible to own a pinball machine, and b) I could afford to do so. So, I craftily bought a Williams Bad Cats:

The reason it was crafty is that I bought it because a) it was a relatively inexpensive machine (I think I paid $800 + shipping), and b) it was my wife’s favorite machine.

I reconditioned it, played it for a while, but there was still a problem.

I wanted a Twilight Zone…

Twilight zone is complex machine. A really complex machine, with ramps, ramp diverters, a working pinball machine, a magnetic mini-playfield, and a impressively complex ruleset. Oh, and it has a lightweight ceramic “powerball” that moves really fast, two different 3-ball multiballs, and – if you are worthy – “Lost in the Zone”, a 6-ball timed multiball mode.

In fact, it was so complex that it didn’t really do well commercially; novice players found it too challenging and confusing.

But skilled players loved it, and made it a hot commodity in the resale market. I was lucky/smart enough to buy mine around 10 years ago, when machines are a bit more plentiful, and paid around $3500 + shipping to get it. These days you will probably play twice that.

Pinball Lamp Matrix Decoding–Completed board

I got the boards back from OSHPark a while back, and got around to populating them. Though I have access to a real reflow oven, I’ve done boards like this with the heat gun method in the past, so I got out the solder paste, put it on the solder pads, put on the shift registers, and then went out to the garage.

I use an old license plate as a board holder, so the board goes on that.

Real reflow ovens use a time/temperature calibrated curve.

Basically, there’s a long soaking stage to gradually bring all the parts up to temp, a ramp up until the solder melts, and then a cooling-down period. I attempt to duplicate this with the heat gun, though it’s really not very precise.

The hard part with the heat gun is keeping it at a distance where it does not blow the parts around on the board; as the board heats up the flux will start to flow and the chips want to move. A little repositioning with a toothpick fixes that. You keep heating until you see the solder reflow, make sure it’s reflowed around all the parts, and then remove the heat.

And you get this:

The 34-pin connector and the two test point connections were hand soldered. I do need to test the board itself and then hook it up to the pin and see if it works.

Pinball Lamp Matrix Decoding–Board design

Since I got the prototype working, I now need to convert it to something real. In the past, I’ve typically done this by hand on perfboard. This takes a lot of time to do, and the results are functional but not that great.

This time I’ve decided to go direct to a PC board, so I fired up Eagle. I think this is my third design with it, so I’m reasonably decent at it, but I’ve forgotten how strange CAD user interfaces always are; they were developed before much was known about how to build good graphical user interfaces, they are all different, and they don’t follow UI guidelines. Oh, and they tend to have some weird metaphors as well, and there is no equivalent of github or stackexchange for them.

I installed the Adafruit library by downloading it, unzipping it, copying it to a directory and then adding that directory to the library path (nuget, anybody?) so that I could start with their arduino shield outline. It has all the pins on it. I then searched for the 74HC589 shift registers. No luck, so I stated to design my own, went back, did some more browsing, and found the 74xx589 SOIC-16 design, so I could use that. I need a 34-pix (2×17) connector header; I found a 2×20 and modified it. Then, I built a new version with named pins to make it easier to wire things up.

At that point, I started the wiring. A bunch of work, an “invoke” to get the Vcc and Gnd to show on the shift registers (once again, CAD weirdness), and I ended up with the following schematic.

Basically, we have the 8 data lines and two strobe lines going from the connector to the shift registers, the two strobes heading to Arduino (pins 2 and 3 because they are the ones that support interrupts), and then a bunch of lines between the Arduino and the shift registers. Prettiness isn’t important here, though it needs to be neat enough to know whether it’s correct or not.

I also threw on two test point headers; one for ground and one connected to pin 4. I often use a pin to write debug information for an oscilliscope, so the headers give me an easy way to hook that up. I run the schematic rules engine, fix a few things, and the schematic is done.

Once you have the schematic in good shape, you can create a board to implement it. I should have taken a snapshot at the beginning because it was quite the mess; there are 8 data lines that need to make it to both shift registers, 3 shared lines from the arduino to teach shift register, plus Vcc & Gnd. Lots of overlap potential.

I like doing board layout; it starts out looking pretty hopeless, and you play a little, it gets better, and then finally it sort of jells and then you are doing cleanup. Here’s the board layout I ended up with:

Lots of left-right rights to route all the signals that go to both chips. I’m pretty happy with this layout; it’s reasonably ordered, and you can tell where things go. I run one line right under the pins of the shift registers; something that I couldn’t do if they were through-hole chips.

Two things I could have done; I could have switched pins 2 and 3, and I could have pulled one of the signals off of pin 11 and used pin 7 instead. I didn’t because I would need to redo the software; a small thing, but the current layout works fine.

Once the layout is done, I run through the design rules. It’s really easy to end up with weird stuff; multiple vias slightly overlapping, traces that don’t quite go to pins, that sort of thing. I’m planning on fabbing the board at, and I remember that they have their own design rules, so I download them and run them.

Then the last task is to shrink the design down from full shield size to something smaller to save a bit of money. Oh, and I add a label or two. Upload it to OSHPark, and they tell me $20 for 3 boards. Pretty good.

Decoding Pinball Bus Signals Part 5

In the last episode, I spend time figuring out how to detect and respond to the row and column strobes. Here’s the short list of tasks:

  1. Hook up the shift registers to the arduino and write some code to make sure that I knew how to drive them.
  2. Write some timer code to handle the delay after the row and column strobes.
  3. Test the shift register code while connected to the pinball machine
  4. Integrated in the lamp matrix code that I wrote separately.
  5. Figure out how to get the lamp state out of the arduino through the serial port.

It’s about to get real

Shift Registers

I’ll start by seeing if I can read static values out of the shift registers.

I slightly modified a 34-bit connector so I could plug it into my breadboard, and then plugged in the two shift registers underneath. I pulled out my breadboarding wires from Adafruit, and started wiring things up. The basic setup is like this:

  • The 8 data lines are connected to the data lines on the connector.
  • The RCK line is connected to the strobe line from the pinball. When the pin pulls this line low, the shift register will pull data in and latch it.
  • Vcc and GND are connected.
  • Output enable (OE) is grounded to enable the serial output.
  • SCK is hooked to the arduino. This will be driven by the arduino to shift the data out.
  • SLOAD is hooked to the arduino. We will pulse it low/high to move the data from the latch into the shift register.
  • SER (shift input) is grounded. This is used to gang together more than one shift register, but it’s not needed for what I’m doing.
  • QH  is the serial output and will be hooked to the arduino.

I spent a lot of time studying both the truth table and the timing diagrams in the data sheet, and came up with the following sequence:

  1. Pulse SLOAD low
  2. Get the current bit
  3. Pulse SCK low to get the next bit
  4. repeat steps 2-3 until you have 8 bits

I set up a loop that would do this continuously, wired up each data lines to Vcc or GND, and started it running. Success! I got a value out that looked like the way I had the lines wired. And then, I rewired the data lines, and nothing changed. After an embarrassingly long period of debugging, I realized that since I was running not connected to the pinball machine, there was nothing driving the data strobe (RCK) input. I modified the code to pulse RCK low/high, and it started returning real data.

Now, to check the speed.

I set up a pin to be a debug output, drove it high at the beginning of the routine, and low at the end. I could then hook it up to my oscilloscope and figure out how fast my data rate was (I could have used the logic analyzer but it was in the other room connected to pinball machine and the scope was handy). The period was about 0.2 mS, which makes the frequency about 5000 Hz. I would need to do this twice, which would put me at 2500 Hz. That gives me little time to do the rest of the work that I need to do, and seems pretty slow.

So, I did some investigation, and rediscovered that the arduino digitalWrite functions do a lot of work to protect you, but this work makes it very slow – on the order of 150 clock cycles to do a single call. I found a nice set of replacement macros online, and recoded things, and got the full read down to about 10 uS, which should be more than fast enough. Here’s the code:

byte readFromSerial()
  byte result = 0;
   // pulse SLOAD LH to move data from latches into shift register

  for (int i = 0; i < 8; i++)
    result = (result << 1)  + digitalState(C_QH);
    // pulse clock LH to move to next bit
  return result;

Another option would be to use SPI to read the data. I didn’t explore that because the bit-banged approach is fast enough and I might need SPI for other communication later.

That gave me one shift register working, so I started on the second one. My original idea was to drive both the shift registers separately, using 6 wires:

Shift register 1

OUT1 (aka Qh)

Shift register 2


I have plenty of free pins right now, and this would work just fine, but the speed of the shift register code depends on a fixed set of pins; I can’t pass in a parameter to use. I could easily duplicate the code, but instead I decided to use the output enable feature and share most of the signals. This allowed me to share signals using only 5 wires.

Shift register 1

OUT (aka Qh)

Shift register 2


The first 3 signals are in parallel. I choose between the two shift registers by carefully setting OE1 or OE2, putting one shift register into output mode and the other into high-Z mode. This also requires some care in the setup code; I set both OE pins to high before I turn them into outputs so that the outputs will not fight with each other.

At this point, I have code to read both shift registers working. Yea!

Delay code

The problem that I have to address is the strange behavior of the row and column strobes. Sometimes they show up row, column, sometimes they show up row, column, column, row. Which means that I can’t just base it on the row or column strobe. What I came up with is the following:

void handleDataStrobe()

void rowDataHandler()

void columnDataHandler()

When either the row or column strobe come in, we set the value of the timer2 count register and set the timer so it’s counting. If another strobe comes it, it merely resets the timer value, so we keep counting. Eventually, we hit the last strobe, the timer overflows, and our interrupt service routine gets called:

ISR(TIMER2_OVF_vect)          // timer compare interrupt service routine

Setting TCCR2B to 0x turns off the timer counting, so we only get the interrupt once.

After a bit of tuning, it’s set up and working:

Channel 0 and 1 are the row and column strobes. Channel 2 and 3 are for debugging; channel 2 goes high when the first interrupt handler is called, and then pulses low when the timer expires. Channel 3 is the SCLK channel, and you can see (well, you could see if I zoomed in) two sets of 8 clock cycles to shift the data out.

Here’s the setup. I think that qualifies as the most complicated breadboard I’ve done; there are two 16-pin shift registers, 12 pins from the connector, and then 7 pins out to the arduino.

Testing the shift register for real

Now that I can read data – theoretically – I want to track what data the machine is sending over the bus. The simplest thing to do would be to just add a call to Serial.println() after the data is read.

But the serial port is *slow*. Too slow to be able to capture sequential values of data.  Instead, I allocate 128 bytes for the row and column, capture that many chunks of data, and turn off the capture while the main loop writes the data out the serial port. And then repeat.

I build the code, download, and I start getting data. Lots of data, since the pinball is in attract mode (lots of flashing lights), and that’s not what I need. I flip the machine into single lamp test mode, capture data, and see the following:

      Row       Column
11111110 11111110
11111111 11111101
11111111 11111011
11111111 11110111
11111111 11101111
11111111 11011111
11111111 10111111
11111111 01111111

That is precisely what I had hoped for. The system is walking sequentially through all of the bits in the column byte, and it is setting the row byte values appropriately. It’s not quite as simple as this, because the lamp is flashing on and off, but it’s close.

I did note that the C# code that I wrote has the bitness wrong for the columns, so I went back and fixed it so that both are enabled with a zero bit.

Integrate the lamp matrix code

Finally, I can integrate the C# code I wrote. I do a quick transform into C++ code, and hook it up. I run into a couple of issues, but it mostly goes clean. But the data has a bunch of junk in it; it doesn’t look like the data I was getting before. Thirty minutes yields no clues until I look up and realize the the weight of the Arduino and analyzer had pulled the connector out of the breadboard. A bit of strategically-deployed blue tape holds it in place, and the data comes out fine.

Okay, except for one thing; it’s in row-major form rather than column-major form, but that’s a quick change.

Communicating the state out

To correctly identify the state of the lights, I need to be able to detect three states:

  • Off
  • On
  • Flashing

The way I do this is to allocate a byte for each lamp, and then decode 128 separate chunks of data. Since it takes 8 chunks to cover the whole matrix, this gives us 16 samples for each lamp. That gives us a zero if the lamp is off, a 16 if the lamp is on, and something in between if it is flashing.

To communicate it out we create a 64-character string by adding the value for each lamp to the character ‘0’, so our range is 0123456789:;<=>?@  (I considered a modified hex with 0-G, but that would be a little harder and slower to create), and then send the values out the serial port.

But, as usual, it’s a wee bit more complicated. I don’t have time in the interrupt handler to send that whole string over the serial port, so instead I copy a snapshot of the string and have the main loop write it across the serial port.

And, at this point, this part of the project is all working; I get consistent strings that give me the state of all the bulbs in the machine.

Next steps

Now, I need to convert it from a mess of spaghetti wiring into something better. I have a few options:

  1. A hand-wired Arduino shield
  2. A custom pc board arduino shield
  3. A “Pinduino” design that takes the Arduino Uno reference design, deletes what I don’t need, and adds in the connector and the shift register

#1 and #2 seems the easiest. I might do #3 at some point.

Oh, and there’s the next section, the whole reason I built this thing. But that’s the subject for another post.