Ok, I have some basic questions from our local EEs with regards to how the CPU board drive the plasma display board on early Williams pinball machines (like 1979 flash).

I would like to do a project to replace the CPU and driver board with a P-roc setup, but I am still scratching my head as to how I am going to drive the old plasma displays.

I have found the pinouts for the master display boards:
masterboard 1.jpg
masterboard 2.jpg

The pinball CPU board connects at through plugs 4j5 (strobe inputs), and 4j6 (segement bcd and blanking).

Is there anyone who might be able to give me a basic description as to the signals the CPU board used to light up segments on the display? I'd like to try to use something like an Arduino Uno to generate the signal based in input form a computer.
Thanks,
Uncivil Engineer

Thanks Barakandl, that was the direction I was looking for. The data sheets are going to help alot.
--Uncivil engineer

Actually, the schematics that were in the ipdb for Firepowers were much clearer.

I think I kinda understand how the circuit operates now. This is how I understand it:

The BCD segment decoders get high signals on the terminals that correspond to the number they are supposed to display. Per the data sheet, if a display is going to show a '1', then it would get a high signal at terminal 'A'. this would cause outlets b and c to go high. This is fed to the Gas display segment driver. Each number place (like the 100,000 - 10,000 - 1,000 - 100 - 10) on each display has an associated strobe input. So if I want to display that 1 from my gas display driver on the player 1 board, I would then hit the strobe associated with that number place (in this case, it would be strobe 6).

So now I just have to figure out the timing all of this has to go on at in order for the strobes to stay lit. I imagine it ran at the speed of the old motorola 6800 that runs the CPU board.

Does anyone know the refresh rate for the displays?

I may have to break down and get an oscilloscope soon..

Lindsey,
I saw your post after I had already purchased a Sain Smart DDS120 20Mhz USB oscilloscope.

http://www.amazon.com/SainSmart-Portable-Handheld-Oscilloscope-Bandwidth/dp/B00FYGEFYM/ref=sr_1_1

It came today, so I got a chance to look at the circuit timing finally.

At least it is dual trace, and it seems to work fine. One advantage of it being computer based is that I can post the outputs here!

So for all of those that are curious, here is what I found:
The strobe inputs are actually opposite of what I thought they would be. Here is strobe 6 that drives the one place on the player 1 board:

Strobe input

It looks like it is high all the time, with just a short pause on about a 56hz frequency.

Here is one of the segments coming out of the BCD chip. I picked an output because the displays are all showing '0' right now, so all four inputs should be low. This input is running at 943hz.
pin9 signal.jpg

You can really see what is going on when you overlay the signals:
combined input 2.jpg
The yellow channel is the strobe, and the blue channel is the segment. If you do some counting, you see that the strobe goes low on every 16th segment signal. There is also a gap in the segment signals every 16th signal. I wonder if this gap is because the CPU needs this gap to calculate the score.

It should be noted that there are 16 strobe inputs into the master display board, and the segment inputs run at about 16 times faster than the strobe inputs. I suppose should have been expected, as the BCD chip is used to refresh all 16 strobes.

I played around some more tonight with the oscilloscope trying to figure out how williams implemented blanking. After finding the blanking lines were not cycling, I came to the conclusion that williams did not implement blanking in system 3 to 6. If they wanted a display off, I think they simply shut off the strobe. The blanking line pretty much always stays just short of 5 volts.

I also figured out the strobes pretty much fire one after another in the order that they are shown on the schematics.

Back to my original purpose: putting a P-roc in my Flash. I went ahead and ordered a Arduino Uno from amazon. One of these should be able to drive two displays, and the programming interface looks pretty easy to use. I just need to find a sacrificial wiring harness (I don't want to cut mine up) so I can build an interface harness to the master display board.

You can find out more about P-roc here: http://pinballcontrollers.com/

Basically, it is a micro-controller board setup specifically for controlling a pinball machine. The actual game code runs on a PC, and connects to the P-roc via USB. The P-roc handles all of the coil drivers, switch matrixs and lamp drivers. The P-roc community has already put together several programming frameworks in pyton that work with the board, and have even created a Williams system 11 interface board that makes converting a pinball machine over to P-roc almost plug and play. They have even adapted Pinmame to run with the P-roc so you can run your pinball machine on either the original roms, or switch over toy our own custom rule set.

Some pretty cool original tables, and updates of older tables have been done with P-Roc. One of my favorites is by a gentleman over in England who did a conversion of Williams F-14, and in the process, developed the Williams system 11 conversion board. You can read about his work here: http://www.pinballcontrollers.com/forum/index.php?board=37.0

My goal with Flash is to create my own custom rule set, but I also want to preserve the original look of the game. This is why I am trying to find a way to run the displays from my own micro-controller. P-roc is setup to run a DMD, but I want to keep my old school look of the six digit displays, so I am looking to using a different micro controller. Ultimately, the display controller will have to talk to a PC over USB to make it work correctly.

Ok, much tinkering has taken place since my last post.

I got my Arduino Uno in the mail from Amazon, along with a Sunfounder super kit. The super kit is just a collection of electronic parts and a guide book that steps you through some projects with the Uno that can be useful to learn how program the Uno.

I went with the Uno because it is advertised as having 20 input/output ports.

To control the score displays, I need 16 strobe outputs, 8 BCD outputs, and 1 blanking output for a total of 25 outputs. My plan was to use one Uno to control two display, thus needing 16 strobes and 4 BCD outputs. However that plan was tossed out the window when I realize that two of the pins on the Uno are setup for transmitting and recieving data. Given that the Uno will be talking to a PC to get the data it displays, this only really leaves me 18 usable outputs on the Uno.

This is where my decision to purchase the super kit kinda saved my project. One of the exercises the super kit takes you through is how to use a 74HC595 register shift chip with the Uno. There is a command in the Uno called shiftOut that allows a user to move 8 bytes of data out to this chip, and use eight of the pins on the chip as eight additional outputs! This works out very well for me, as the BCD runs on a 4 byte word, and there are two of these chips that have to be controlled. So now I can move 8 of the outputs I need to the 74HC595 chip (at the cost of only three output pins on my Uno).

So, this means I need 16 strobe outputs and only 3 data outputs for a total of 19 outputs. This leave me just one output pin short of being able to run all the displays off 1 Uno board. However, I still have one more trick up my sleeve. The 'unit' displays are all on strobe 6 and 14. On these older pinball machines, the until displays almost always display '0', because nothing no the game scores less than 10 points. So I may be able to combine these two strobes into one output, and make it all work off one Uno board. This is kinda the digital equivalent of the eternal '0' reel on old EM machines.

I also won an ebay auction last week for all the head wiring off a Williams Close Encouters machine. This will give me all the plugs I need to hack together a wiring harness to plug my Uno board into my Master display driver board.

Ive taken baby steps so far, and I think I have the hardware side figured out. Now I just need to dust off my C+ skills and work out the software.
IMG_2613.jpg

So I have made some more progress on this since my last post..

The software for the Arduino Uno is done. I now have a sketch that will take input wrapped in '<>', and will create the BCD signals, and output them for the proper strobe. It also has a master kill switch that get enacted when I send the board <B> and a master on switch when I send the board <G>. When I send a player one score, it has to be in the format <P1XXXXXX> where X is the score, or what ever else I want displayed. This is the same for the other player scores, and the two smaller master displays. Also, if I send a 'B' in place of a number, it sends the BCD processor all high signals, and that gets interpreted as a blank space in my score.

I did manage to solve my input problem. Why use one 74HC595 register shift chip when you can use two! Turns out you can chain these register shift chips together to make as many outputs as you want. So now all 16 strobes are controlled by two 74HC595s.

So now I am now creating a prototype using a screw shield board.
soldering up the prototype
These screw shield boards are pretty nice, they allow you to make screw connections to all of the Uno input/output pins, and there is space in the middle for both of my 74HC595 chips.

I have already cut the wiring harness I got in the ebay auction, and it is the last thing I need to attach to my screw shield board before I do the 'fiss-bang' test.

I'm about 80% certain this will work, the only issue I can foresee at this point is the old masterboard not liking the input from the Uno because it operates at a slightly different voltage. The Uno is running off USB power, and only has about a 4 volt range. When a pin goes high, it reads 4.0 volts. The old hardward runs at 5 volts. If the old hardware can't operate with a 4 volt input, I may have to wire the Uno board into the pinball machine power supply so it sees the same 5 volt reference that the master board operate on. This is 5v power at the master board, and it may just be a case of tapping that power. I want to try it at 4v first. I think the worst that could happen is that it simply won't work.

Holy cr@p, it works...

Well sort of.

I finished all the soldering tonight, and being the impatient type that I am, I went ahead and plugged it into my Flash. It only connects in two places, at the BCD inputs, and the strobe inputs.

I then plugged my Adruino Uno into the usb port on my computer and uploaded the program.

The serial monitor gave me an 'Setup Complete', and I went ahead and sent the Uno a <G>, and the displays on my Flash lit up with all 0s. The default variables for the score digits start with 0, so that was a good sign....A VERY GOOD SIGN!

The Adruino Uno running the displays
displaying numbers

So I started testing it by sending scores to the displays. This is where things got interesting.

When I sent a score to the player 1 display, it came up in Player 2. When I sent a score to the player 3 display, it appeared in the player 4 display. so I have got something switch up. I also cant send blanking calls to the player 3 or 4 displays without it instead blanking out players 1 and 2. So I still have some trouble shooting to do, but I feel like I am 90% there.

When I set up my display inputs, I was using a set of schematics from a Firepower pinball machine. I wonder if they switched up some of the inputs for Flash. I may have to do some wire tracing sometime next week to find out.

Ok, I figured out why my scores were flipped. It turns our I was sending the bytes to the shift registers in the wrong order. It turns out when you daisy chain more than one shift register together, the first byte you send goes to the lowest chip in the daisy chain. I had assumed that the first byte when to the first chip in the chain. Oh well, that is easy enough to fix in the software.

Ok, the software is debugged, and I found my other mistake in the blanking routine. I pasted and copied part of the code from the IC5 section to IC7, without changing the reference back to IC5, so it was trying to blank the wrong digits. That is now fixed, and it works as I hoped.