Monthly Archives: March 2017

03/26/2017 – New SharpeShooter3 Video

Here is a video showing the difference between different solenoid initial kicks for the flippers and increasing the voltage.  What was once a lackadaisical unplayable machine is revived into a fun to play snappy machine.  Yes!  It really goes to show that it is difficult to set up the initial kick without using a pinball, and how a little bit of extra voltage (24V upped to 30V) makes a ton of difference.  I’m now back to excited about the machine.


3/20/2017 – Interface board wiring complete

Finally finished up the Bally interface board wiring.  It is one of those things where you think that it will be easier to just solder the wires into the board instead of putting connectors on both ends, and then, about half way through it, you wonder if you made the correct decision.  The good part is that I should now be able to plug the boards into the Dolly retheme.  The bad part is that both the firmware isn’t quite done to support the switch matrix, and the backbox has moved to the garage for painting.  (Still hasn’t gotten warm enough to start painting, so it is just sitting there waiting for the weather to turn.)  Now that all the annoyance of wiring the interface board is completed, I’m getting pretty excited to do some initial tests.

Bally Interface Finished

Finished wiring for Bally interface board

I’m not bothering to create a test fixture to test switch matrices, so that will be implemented and tested on the Dolly playfield itself.  The processors are supplying the voltage for strobing the columns, and all of the grounds are tied together so as long as I can get 5v to the processors, I should be able to test that functionality.  A new firmware command will be needed to read the switch matrix inputs.  Similar to the other read inputs command, read matrix will send back eight bytes of data or an 8×8 matrix.  The firmware is going to automatically debounce the inputs for convenience.

At this point, the firmware is complete for re-running all of the SharpeShooter3 code.  I’m still running into small bugs here and there where I haven’t moved from first generation code to Gen2 code fully, but the bugs seem to get easier and easier.  I’ll throw up a video of the current game play.  I have to slowly work on going through each of the modes to make sure that they are working.  When I brought it to Pintastic in 2015, it didn’t have a ball search algorithm.  This meant that if you jostled the cabinet a lot when the ball was being kicked out of the kickout hole, it would never try to kick out the ball again.  That must be fixed.

Another issue is that the flippers are very under powered.  It could be because I set the initial kick without using a pinball.  I can increase the initial kick, or increase the voltage of the SMPS, but I’m just not sure what is the best way.  The other thing I’m noticing is that previous I was running everything at 48V and everything was really snappy and fun.  Now everything seems dead. Bah!  Seems like more time has to be spent getting it back to where I am happy.  Here is the video.

3/14/2017 – Creating synchronicity

Serial communication bandwidth is “precious” in the OPP environment.  The serial commands are designed to reduce the amount of necessary commands that are needed to control the pinball machine.  The two big heavy hitters are reading status, and controlling lights.  Both of those things happen all the time so efforts were made to reduce this traffic if possible.

Right now the status of the inputs are polled constantly.  There has been a request to change the firmware so that it only sends updates when an input changes.  That would certainly reduce the amount of traffic, but it may come at a terrible price.  Right now, if a message gets corrupted, it is simply dropped.  (all serial messages contain a CRC, so that they can detect if an error has occurred and just ignore those messages with bad CRCs).  If there is a parameter that configures the boards to create messages only when inputs are changed, there is the possibility that a change message could get corrupted and dropped.  At this point, I have not seen any evidence of any serial communication corruption that has not been caused by overflowing the serial port buffers.  That may mean that my fears are unfounded, and I can just ignore them.  Of course, it heavily depends on how people wire their machines.

Back to the other heavy hitter on the serial port line.  It is turning bulbs on and off.  To reduce that bandwidth, the OPP firmware supports commands that tell lights to blink slowly or blink quickly.  After a blink command is sent, the firmware makes the updates automatically so the pinball framework processor doesn’t have to bother sending those commands.  Here is where the problem is…how to synchronize all that blinking because each OPP board has its own processor with its own crystal running at its own frequency.  The blinking became very noticeable as the pinball machine ran for a half an hour or so and the state machines drifted apart between the different cards.

Predicting that this would be a problem, the hardware supports a Synch pulse that goes between the boards.  (Synch of course stands for synchronize).  Here is a description of how the synch pulse works with the new firmware.

When the inventory command is sent, the first OPP board suddenly realizes it is the first board and starts driving this signal.  (Nobody can drive the signal before because of the possibility of two processors driving the signal.  That’s not good because one may be trying to drive a high value, while the other may be trying to drive a low value, and that forces the processor driving the low value to sink the maximum amount of current that the other processor can source).  The first board drives the signal high for a short period of time.  All other boards read this signal and can use the rising edge of the signal to synchronize their internal LED state count, so all of the boards are at the same state in their state machines.  Even if the crystals are off by 60 ppm, or so, the processors continuously re-adjusts to the signal produced by the first board.  Nice and simple.

In the repository, this will be image version Gen2.rev0.2.0.2.cyacd to support this new functionality.  On to the next item on my list.

3/11/2017 – Working on backbox modifications

A good amount of time has been spent on the backbox modifications.  All old Bally cards have been removed and will be replaced with brand spanking new OPP boards and probably a Raspberry Pi to drive the rules.  Here are some of those cool mosaics showing all the pictures in a funky rectangle.

The biggest picture is the original look of the backbox.  The second picture is all the cards removed, and the extra pins from the transformer that aren’t needed removed.  The last picture shows the replacements vs the original card equivalents.  The replacement cards are mounted on a piece of plywood to make it easier to move around.  The biggest card is the interface board that I made to convert the Bally wiring harness to directly interface to the OPP boards, so I don’t have to modify any of the wiring of the machine itself.

Here are some comparison pictures to show the size difference between the old cards and the new cards.

First picture shows the MPU card vs a Raspberry Pi.  It is a really old Pi that actually powered my Halloween costume.  Time to put that to some real use.  Next picture is the Bally lamp driver board vs the five OPP incandescent wings.  The sound boards only supported a single speaker, while the new one is full stereo at a higher rate.  (The newest one sits off the USB bus on the Pi.  The analog output from the Pi shouldn’t be used because of its really low quality sound).  The last picture shows the Bally driver board vs the five solenoid wing cards.  The reality is Dolly only used 12 solenoids, so I’m only going to use three solenoid wings in the retheme.

Now I’m prepping the backbox for painting.  All of the art has been removed from the backglass.  The light board has also been removed from the backbox.  I’m going to do string LEDs to illuminate the back of what will essentially be a translite.  Did a little sanding on the backbox to prepare it for the first coat of enamel.  (Still way too cold outside to paint, and there is supposed to be 12 or 14 inches of snow on Tuesday, so it is going to be a while).

I still need to solder a couple more wires into the interface board for the two different switch matrices.  (There is one switch matrix for the playfield and one switch matrix for the cabinet).  All in all, a good amount of progress over the last week.

3/5/2017 – Why bulk capacitance matters

Rarely is there a single change that can be made, where cause and effect is so evident in electrical engineering.  After looking through the equations for solenoid power and running some calculations, I noticed that reducing the amount of turns on a solenoid doesn’t really affect things that much because at the same time, I would be increasing the amount of current in each turn.

Because of that, I came to the conclusion that I would need to throw in a higher voltage power supply.  I had a super cheap 48V supply laying around, and tossed it into the machine just to reset the drop bank targets.  After trying it, it just didn’t work well at all.  Then I decided to add a big bulk capacitor to store some charge so it could respond easier to the firing of the solenoid.  (10mF)  It more than made up for the inability of the power supply to provide the instantaneous current to fire the solenoid.

Here is the video that shows the difference with an without the capacitor: