Category Archives: Disaster

Eventual name of the first (probably only) open pinball machine

Processing Engine running, 4/27/2014

Spent all my spare time this weekend on getting the rules engine working.  It is now running the code and can change the LEDs, start games, watch balls drain, etc.  It is pretty exciting to simulate a whole pinball game…but, it is only simulated.  I still don’t have the LED engine running, but that is simple in comparison to the rules engine.  The rules engine is using a good number of the standard functions from the macro language which means that many of them have been verified.  In a couple months, I will end up running a verification of all the standard functions to make sure that they are working properly.

The ruleset that is currently programmed is the targeted rules for the backpack pinball machine.  Here’s a quick picture of the simple layout:


Simple Pinball machine from three test cards

I’m going to update the rules set to include a few more features.  The spinner is used to increment a bonus value.  If the inlanes are completed the bonus multiplier is incremented.  If the all the targets are completed, the bonus multiplier is incremented.  If the ball goes in the kickout hole, the bonus is collected.  If the inlanes are completed and targets are completed within a 30 second timer, the bonus is held to the next ball.

One interesting fact about running the real ruleset is that the rules get really angry if the ball can’t be found to start the game.  It means when running the machine, you must remember the order of pressing the switches.  Before pressing the start button, the Ball_In_Play solenoid switch must be closed.  When the game is started, deactivate the Ball_In_Play solenoid and activate the Ball_At_Shooter input.  The game goes to normal scoring mode when it detects the ball going through one of the inlanes.  At that point, the Ball_At_Shooter can be deactivated.  To simulate the ball draining, activate the Ball_In_Play solenoid switch.

Next big thing with the Python pinball framework will be to attach the LED engine so that the LEDs can be automatically strobed.  After that, sounds need to be added back in to get that fully working.  I also haven’t added the scoring back in, except for bonus score for completing the inlanes.

I’m currently adding in Doxygen comments for Python code.  I’ve never used Doxygen for documenting Python code, so I’ve had to spend a good amount of time reworking file and function/class headers to make sure the information is presented properly.

Last time to mention Allentown, 2014.  Just in case you missed the last post, John and I will be attending Allentown on Saturday (5/3/2014) from opening to mid-afternoon.  We will be wearing OPP (Open Pinball Project) T-shirts.  The first person that comes up to either John or I and says, “Give me a free T-shirt”, bam, they get one.  Thanks again to Joe for doing the artwork.

I will probably be doing another code update this week if you are watching the Google code repository.


Update 3/27/2014, Mostly Python

Finished the conversion of prototype code to the real code.  Wow, it looks much better at this point.  Fixed the organization of the code and much better design.  (Actually the design didn’t change, just the implementation).

Moved from 80s code development into the 2000s.  When the original stuff was written, it was tested by what used to be called printf debugging.  Since my background in Python was basically writing regression tests for scientific/telecomm gear, it worked well enough.  Python was used as a replacement for Expect.  (Doubt if anybody remembers Expect anymore, but once it ruled the serial communication world).  Well, writing python as you would expect really doesn’t do justice to python as a language.  This past week the time was taken to re-organize the code to better match pythonology.  (Yeah, that is a made up word).

Took the time to download PyDev as an IDE.  What a breath of fresh air, as opposed to using print statements to debug.  It took about 15 or 30 minutes to add it to Eclipse and get the project pulled into it.  In the next hour, the code was being improved by leaps and bounds.  Background compiling to look for issues, auto code completion, easy project searches, the features just go on and on.  PyDev has helped progress immensely.

What’s up next?  The screen outputs are done in PyGame, and the debug interface will be in TKinter.  Both exist natively on the Pi.  (Took a while to get both programs to play nice with each other since both of them wanted to own the main loop thread.)  Luckily the TKinter stuff is going to just be a debug interface to help people test their rules.  Next big update will include the debug stuff.

If anyone was foolish enough to grab previous versions of the OPP Pinball Frameword, I would suggest grabbing the latest version.  It is significantly better and has more features.

Update on 3/1/2014

I try to keep most of the stuff in the blog purely technical, but I have little to add technically.  Late winter blues have set in and things have gotten really busy at work.  There was a project that was not going to be delivered on time or meeting the features, and it finally got delivered on Friday on time and budget.  It meant a lot of hours to get it back on track, but now it is done.

Why does this matter to the pinball community?  Simple, they gave me a small thanks bonus which I’m going to use some of it to start buying parts for my CNC router.  I think that the Solsylva 25×25 should meet the needs perfectly.  While it only cuts in a 25×25 areas there are no stops on the y axis, so it should be pretty simple to move the playfield to two different positions to cut the whole length of the playfield.  I’ve been researching CNC routers for about six months or maybe a year, and it seems to match my needs pretty closely.  It is meant to be built from standard parts that you can get at a hardware store.  (That of course doesn’t include the stepper motors, drivers, etc).  The tolerance is reported to be about +/- .003 inches (about the thickness of 2 pieces of paper) which should be good enough for what I need.

Besides that, I’ve mostly been futzing around.  The basement is really too cold to do a lot of work, and since my job was so busy, most of my free time was eaten up there.  I built up a bunch of new boards so that I could finish Camelot, but I have not tried them yet.  They are soldered, but no testing.  I need a 60 cent part from Mouser and I don’t want to pay the shipping.  Grrrrrr.  I ended up buying the parts from Sparkfun since the price per part was cheaper, and the shipping was slightly less.

A few last ideas that are worth exploring down the road.  First one is using a screw drive to open and close the outlanes automatically.  It would involve moving the outline post to make the pinball easier or more difficult during a game.  Right now, in all the games the I know of, outlane posts are in a single position during a game.  Allowing the post to move would allow a game to become more difficult the longer it is played, or a player could be handicapped to make two people of different abilities to “challenge” each other.  Another thing that would be cool is that a route game could be set up as relatively easy.  As players get better (i.e. play longer), the game slowly makes the game tougher and tougher.  Kind of like a progression in replay scores.  Another option is when the game is started to start the scoring at higher values, but the outlanes are more open.  When people play a routed game, if the ball drains very quickly, there is little reason to put more money into the machine.  They feel somewhat cheated.  If the game is set up too easily, the operator doesn’t make money because too many free games are won.  Changing the outlane post position might address both of these issues programmatically.

Second idea is going to be incorporated into Disaster.  That is the Sharpe Attack mode (pun intended).  (Disaster and sharks, what is better than that, maybe a Sharknado?).  The Sharpe Attack is simply getting rid of the hold on the flippers.  Since all of the solenoids are controlled by PWMs, it is very easy to make them stronger, weaker, or even get rid of a part of the cycle and make it so the flippers can’t hold.  The name comes from the fact that if you watch a video of Josh Sharpe playing, (or really any good pinball player), they cradle the ball all the time.  It allows more control over the ball because it is starting at a known velocity, and makes the shots much more repeatable.  During Sharpe Attack, no cradling would be possible because the flipper hold would be set to off (or 0 ms in the config).  That would significantly change the dynamics of a game for a brief time period.

There is another pinball machine idea which I’m working, which will involve a reducing the flipper power during certain modes.  (basically a dreamy, or druggy mode)  Power and strength of any driven signal is easy to control since it is just a PWM and the duty cycle can be altered.

Initial Python Mockup done

So traveling over to the repository, the latest version has a python mockup for a pinball machine.   The idea is that there is a translite mounted in front of a monitor.  The translite has cutout areas so that the player’s scores, ball count, credits and current player is displayed.  All of these are in static locations so the translite is just a typical translite.  The simulation automatically scales between a mockup size and the full screen size so testing can be done more easily without having the simulation take the whole screen.

When coding it up, I decided that the monitor also needed to include general illumination fake lights to mock up general illumination behind the translite.  To make it clear, I made the general illumination lights appear like circles so they appear just as if they were 44 or 47 bulbs.  If doing it for real, the general illumination lights could be any shape that would make the most sense behind the translite.  The general illumination lights are turned on and off as a group.

Well if you have general illumination, you also need feature lights to highlight whatever needs to be highlighted in the translite.  You need Santa Claus on the backglass to light up when you pick him up in the Taxi.  The feature lights are triggered off simulated inputs.

I threw in a very simple set of rules which essentially contains a way to add credits to the machine, start a game, and drain the current ball.  Up to four players are supported.  When the game is playing, inputs can be simulated to add score to the active player.

It’s not much of a pinball machine if it doesn’t have sound.  When a game is playing, a background song plays continuously.  Inputs can also be simulated to play sounds on top of the background music.

All of the stuff is written using pygame.  I originally was going to use tkinter, but really wanted to support sound.  It has been “optimized” to only redraw (blit) changes in the screen, so it should run very quickly.  I could have cheesed out and redrawn the whole screen, but who knows how fast the Raspberry Pi will be able to draw to the screen.

This should work on a Raspberry Pi, without installing extra modules.  When I get the power supply boards, and the Pi shield in the next couple of weeks, I will try it out, but I’m not in a rush.  My development environment is very simple on a regular PC, so there is no reason to move onto the actual Pi until later.

It is currently only a simulation, so it doesn’t run the serial commands to interface with the input and solenoid cards.  That’s probably going to be the next step.

Here is a quick rundown of how to run the simulation:

Starting it up, you should see the positions of the player scores, and current player and credits/ball num displays.  The following commands (single key presses) are supported.
‘s’ go to sound mode, ‘0’ to ‘9’ will then play a sound (there are only about 5 sounds installed.  Used normally to trigger sound files.
‘i’ simulate input mode, ‘0’ to ‘9’ simulate an input
‘l’ light mode, toggle on/off feature lights, ‘0’ to ‘9’ simulate an change

Starting a game:
‘c’ add a credit
‘g’ start a game
‘d’ drain the ball

Quick walk through:
Start up the program.  Press the ‘s’ key to get into sound mode.  Press a couple number keys to listen to the sounds.  Next press the ‘l’ key.  (That’s an L)  Press a couple number keys and watch feature “lights” toggle on and off.

Now start a game.  ‘c’ gives a credit, and ‘g’ starts the game.  Background music should be playing.  Press ‘i’ to simulate inputs and add score to the player 1.  Press ‘d’ to drain the ball.  Notice the ball num going up.  (it is assume that the translite will have text indicating to the player which window is the ball num/credits and which window is the current player)  Drain enough balls (3) and the game is over.  The background music should stop.  Press ‘esc’ to leave

There is a batch file in the directory that automatically sets the right parameters on a Windows machine.  The command line is:

c:\Python27\python.exe -port=COM1 -simWidth=854 -actualWidth=1366 -debug

Here is a quick screenshot of the simulation.



Rockin In 2014

Welcome to 2014 and it looks like it is going to be a very interesting year.  Many new things will be happening this year at the OPP, and I predict the starting of a serious shake-up in the pinball industry.  This year is definitely going to be fun!

People like to make resolutions at the end of the year, so here they are for the OPP:

  1. Have a Logo created
  2. Visit at least one show (Allentown or York, and maybe hit both) and bring a prototype.  (Best case, it is going to be a working white wood with almost no rules, worst case, it is going to be the EM converted to solid state using the driver/input cards)

Everybody needs a logo, and the OPP is but one of them.  As mentioned so many times before, I have no artistic talent.  ZERO.  I’ve reached out to my one contact, but nothing has come of it.  If you are foolish enough to be reading this, and have some small thread of artistic talent, send me an email.


Enough with the begging.  On to the technical stuff, which is really where all the fun is located.

The power supply board is completed.  The design will be checked into the Google code repository in the next couple of days.  The board manufacturer is on vacation until 1/6/2014 so some extra days can be spent verifying the design.

Since the board is 10 cm x 10 cm, the extra unused space is being used for a respin of the RS232 interface card so that the communication connector matches all the other connectors in the system.

The last piece of the card is a custom Raspberry Pi shield.  That card contains the Raspberry Pi header, voltage translator, a MOSFET so the Pi can turn on and off the power supply, and all of the connectors necessary to interface with a complete system.  I continue to believe that the Raspberry Pi is going to be my best option.  I love the HD streaming video, and hey, I already have one.  My friend is trying to talk me into switching, but I haven’t found any good reason to consider another platform at this moment.  When I get the Pi shield, it will be more difficult to switch to a different card.

The Pi is going to provide the SPI interface (LED drivers), UART (a COM port running at logic levels instead of RS232 levels) and single GPIO bits for stuff such as turning on/off the power supply.  There are standard connectors for the solenoid drivers, input drivers and LED driver boards.  There are also spade terminals to provide the higher current voltages such as powering the LEDs for lighting.

There is a bug in the current version of the LED driver board.  It is rather simple to fix it using a cut and a jumper, but the first hard bug in a design is always disappointing.  That board was done very quickly and is the easiest of all the boards, which seems to make it most likely to have a bug.  I’ve re-thought the strategy of that card, and will change the connector so that a single control line can turn off all the LEDs at once.  It will make “blanking” all the lights that much simpler.

Kicad has been updated to a newer version, so many of the design files are also being updated.  As a stretch goal, generic part numbers will be added to all the designs with a python look up script to make ordering assemblies that much easier.  Doubtful that this will be completed before the check-in of the boards.

I noticed some of the headers have pin 1 on the left side of the connector and other have pin 1 on the right side of the connector.  I’m pretty vigilant in making sure I don’t mess stuff like that up.  I finally went through the documentation between Molex and TE Connectivity and they pin out their connectors in opposite directions.  Super annoying.  It means that when I build up boards, I have to make sure that I use an assembly picture to make sure all the connectors are rotated properly.  I added pictures of populated boards to the interface document, and that is the safest way to make sure they are correct.  Here is a link to  the current version of the interface document.  Wiring diagrams were also added to make wiring solenoids and inputs a little bit easier.

That’s all for right now.

Status 11/18/2013

Last couple of weeks have been very busy.  Taking an old EM playfield and converting it to modern drivers has been going well.  Lots of things have been  learned in the process.

1.  Don’t use the old wiring.  While it looks very convenient and seems to have many of the connections that are needed, it is from the 1960s and the insulation is made of cloth, not plastic.  It is a pain to strip the wire which makes it difficult to get a good crimp.

2.  The wire doesn’t necessarily run where it needs to run.  There is a common ground for almost everything so even more wire could be removed from the bottom of the playfield.  If the playfield would have been stripped, and started from scratch, only the needed wires would have been added back.

3.  The cheap crimper (KF2510), works incredibly well.  It’s been used for 100 mil spaced connectors, standard pinball molex connectors, and spade terminals.  It has three different sizes for different connectors.  While it isn’t as nice as the $300 molex crimper that only supports one terminal type, it works great for general use.  The trick is to start the crimp so that the ratchet holds the connector in its teeth.  Slip the wire in to the terminal, and then finish crushing the crimp.  The crimps are nice and tight and hold the wires very securely.

After rewiring, this is what the bottom of the playfield looks like so far:


The first picture shows the driver board at the top center of the picture, with an input card on at the bottom of the picture.  Second picture shows the entire playfield.

The solenoid driver at the top handles eight solenoids.  It includes eight inputs so all the real time aspects of driving the solenoids is local to the little card.  The four wire cables on the edge of the is a transmit/receive/power and ground connections.  To each solenoid that is controlled by a switch, there is a single wire to ground at the bottom of the solenoid (NFET configuration), and a single wire to indicate the switch is closed.  The hot side of the solenoids are all bussed together with the high voltage.  The common side of the switches are bussed together with a ground wire.  (Each switch connection has a 2 pin header with one of the pins being ground.  This gives the flexibility of not needing to run a ground bus.).

The input driver board is very similar except there are 16 inputs per card.  Each switch input is a two pin connector which can provide a ground if a common ground wire bus isn’t available on the playfield.

Last big thing that looks out of place is the cheapo power supply.  It is a Meanwell LPP-150-48.  It only provides 3.25A at 48V.  Bought two of them and planned to split the flippers between the two power supplies, but during testing over the last couple of days, it seems like a single power supply might be able to run the flippers.  Of course, the second supply is already bought, so it might as well be used.  Each of the supplies is $9 on ebay.

Nice to hear the bam, bam of solenoids being driven at 48V.  I’m probably going to take a little time to build a second solenoid driver card.  (Right now there aren’t enough drivers on a single card to support two of the pop bumpers and one of the kickout holes.  Parts are already in house for another two driver cards).  Each type of solenoid has been wired up to make sure the driver card configuration is working properly.  The flippers have a 48ms initial kick and then a 25% on the PWM for hold.  The kickout hole has a 48ms initial kick, no hold, and a dead time configured in case the kick doesn’t clear the ball from the kickout hole.  There is a post that goes up and down, which has no initial kick, and only 25% PWM.  Last type is the pop bumper which has an initial kick, no PWM, and a small dead time.

The input card is a little more dull at this point.  It is currently wired up and shows the status on a computer sitting next to the playfield.  Boring.  No scoring, no rules, hey it is just a test bench.  Enough rules might be written so a game can be played and scoring can be added but no real plans at this point.

Status 10/27/2013

Been busy the last couple of weeks.  All last week/this weekend was spent cleaning the Taxi playfield.  It isn’t sexy, but it was just using a large amount of elbow grease.  Lot’s of time you need to take off some mylars.  Maybe two layers of mylar.  This playfield had three layers of mylar.  The whole bottom of the playfield was completely covered.  Removing the mylar using freeze spray always goes really well.  Removing the adhesive stinks.  Especially the adhesive on inserts is very nasty.  I tried to use flour and IPA (isopropyl alcohol) to remove the adhesive.  I believe it worked better than using just goo gone.  I ended up getting blisters on my fingers from rubbing the adhesive off.  I finally finished it this morning at about noon.  As soon as that was done, did some major cleanup on the rest of the playfield with a magic eraser.  The game now looks better than it probably has for 15 years.  I’m hoping to have it back up and running by Halloween.

So two or three weeks ago, I bought an older populated playfield.  I didn’t even know what game it was, but it doesn’t really matter since I’m just going to use it to prove out the driver and input cards.  Turns out the playfield is an old Camelot EM.  I took a couple pictures of the bottom of the playfield swapping over to the new driver card.  After I finish rewiring it, I’m going do a couple before and after pictures.  It should demonstrate how many less wires a distributed design uses instead of a centralized old school design.  I don’t have enough cards to drive everything, but I should have enough to make it play.

Since it is an old EM, I have to add diodes to all the solenoids.  I’ve already run the high voltage line which is basically a 48V wire to the high side of all the solenoids.  That meant removing all the individually run wires and the relays that were controlling the pop bumpers/slingshots, etc.

I bought a pair of crimpers which should make crimping the wires a lot easier.  It can be done with one of the “universal” crimpers that are 30 or 40 dollars, but they stink and do a poor job.  The molex crimpers are about $250 which is too rich for my blood.  I found another , KF2510 Dupont crimper on ebay which costs about $26 total.  Since each input can take up to 32 crimps, and the solenoid cards can take another 16 crimps, it is well worth it.  (I plan to cut these in half by running a common ground wire so you only need a single signal crimp for each input.)  As soon as Taxi is back together, I will finish up the rewiring.  (Still waiting for my new soldering iron to show up.)

The Disaster Java application has been getting some major work.  Most of the code for the compiler has been removed, and now the application takes the rules file and is generating Java code that can be compiled.  This is about 70% done, and I’m getting very close to the first generating working.  It is currently not checked in, but that will hopefully in the next week or two.  I’m not going to talk to much about that since it isn’t checked in.  It was definitely the right decision as suggested by a couple of different people who commented on this site.  Thanks again for those suggestions.

This week I tried to get in touch with the one graphic designer that I know.  She has mentioned that she is still interested, but is currently moving.  Hopefully she will be able to do some graphic magic.