1/18/2016, Love that new code smell

So I started writing the MPF interface for the OPP hardware.  Brian offered to write the interface, but I know a lot more about the OPP hardware so I think that it is just as easy for me to write it and get it correct and optimize it properly.  I didn’t want to get into a situation where Brian spent a bunch of his time, I looked at the code and wasn’t happy with it, and rewrote it myself.  That would waste both of our time.

Installing MPF did not go as smoothly as possible.  MPF assumes that it is the first time that Python, Pygame, and PySerial are installed on a machine.  I had older versions of all three of these programs, so when I tried to start the demo machine in MPF it failed.  “DLL load failed: %1 is not a valid Win32 application.”  I’m was thinking to myself, oh great, I’ve just set myself on a couple day hunt and peck to try and figure out what went wrong.  Luckily it simply required uninstalling PyGame and reinstalling it again over the the new version of Python.  (I blame this issue on upgrading from Python 2.7.6 to 2.7.10).  I then had trouble running TK.  (import TKinter was giving the same issue as above.)  I uninstalled Python 2.7.10 and reinstalled it again, and now I was able to import TKinter.  MPF does not use TKinter, but my pinball framework uses it for running the debugging window.  I was happy to see that I could now run both frameworks successfully.  Last configuration change I had to make was to allow Python connections through my computer’s firewall.  MPF BCP connect sockets using a local loopback connection.  These were actively rejected on my laptop (Win 7 Enterprise Edition), so I had to Control Panel->System & Security->Windows Firewall->Allow Program Through Firewall, and browse to c:\Python27\python.exe.

Woo, hoo.  Up and running with the demo machine executing.  That was actually relatively painless.  (A couple more error checks could be used in the install script, but it does clearly state that the script assumes that no previous version of Python, PySerial and PyGame are installed.)

The thing in MPF that is used to support actual hardware is called a platform.  There isn’t currently any information on writing your own platform file, so you basically look at previous examples of platform files, and reverse engineer what they return to the rest of the framework.  There are already platform files for the FAST and the PROC and P3-ROC platforms.  They support some of the same functions that I support in the OPP hardware.  I based the OPP platform file off the FAST platform file.  I don’t think it would have changed things significantly to base the file on the P3, but I happen to choose the FAST file.  It is going well, but the new platform file isn’t done being written yet.

One thing that I do miss using C, C++, C#, etc is that it is very easy to define an interface.  Python does not really have any concept of what an interface is.  It also has the added benefit that if somebody calls your object, expecting a certain function and it doesn’t exist, it just crashes.  (Yeah, no type checking because that would restrict how things could be used)  Do you get a compiler error, oh no.  That wouldn’t be the Pythonic way to have to know what type of object you are talking to.  Instead it simply gives a back trace dump.  Hopefully all the functions are called frequently enough that I can easily find all the interface errors.

So, first thing I have to say about the MPF is that the documentation is really great, especially for a beginner.  Within a couple of hours, I was easily able to get a simple machine working that would do an attract light show, flip through my attract slides, and start a three ball game.  Most of that is built right into the framework which is really nice.  If you are following the tutorials, everything works really well.  In the tutorials, some of the background processing is explained which makes extending the example and modifying it to your liking easy.

When you get to the end of the tutorials, things become a little rougher around the edges.  I was not willing to dig into the core MPF code, but had some difficulties doing some very simple things.  There are currently no tutorials on playing sounds.  From programming my pinball framework, I knew this functionality should be very simple to get at using Pygame.  My main problem was that I didn’t know how to do it in MPF.  I immediately went to the forums but had difficulty finding information.  It was great that MPF has forums, but they aren’t very useful at this moment because they aren’t searchable.  After a day or two of mucking around, I finally figured out how to get it to work, so I could play a sound at the start of a mode.

I am planning on moving all of the SS3 rules over to MPF and posting the final files.  Hopefully this will give others a working example of running a full featured pinball machine using MPF.  This little exercise should force me to examine the differences between the two pinball platforms.

One major thing that needs to happen is that the MPF forums need to be made searchable.  I remember seeing a post that was related to something that I was putting off implementing, and even after going back and searching for a few hours, I could never find it.

Here are two quick pictures of comparisons between running the OPP framework and MPF.  I will describe more of the differences in a later post.

OPP Framework:

MPF Framework:

One quick thing to note is the jaggedness of the score font.  Both of the frameworks are using the exact same true type font file.  I might have to look into how MPF is generating its text.  This is one area that the OPP framework was optimized for printing text because it is assumed that it is going to be used for scoring.  The MPF framework puts much more emphasis on DMDs, and I think the code to display text is less mature.

When the OPP framework prints text, it is always right justified so it looks old style pinball displays.  I haven’t found an easy way to get this to happen in the MPF framework.  In MPF, the text anchor is always on the top left corner, so I will have to pre-process all scores to add extra spaces to get the text to not move as the score goes up.  MPF also post-processes numbers and adds the commas automatically.  That would be great, but in some cases, I don’t want to add commas to the numbers.

1/4/2016, What the Heck (not Ben) am I doing?

I was looking back at the archives to try and figure out what the goals were from the previous year and if I met them.  Fortunately I can’t find any goals, so that must mean that I met all of them.  At the end of 2014 I came up with a dopey idea of bringing a machine to the Pintastic show.  That happened, but it was a knock down flat out fight.  I was personally not happy about many aspects of it (mostly the software that was running the rules) and just didn’t have enough time to really work out the bugs.  (Yes, I was the guy huddled over the pinball machine the night before the show updating code.)  Some of the updates worked well, while others introduced bugs.  I didn’t have enough time to really play test the code, and some of the long timers that I was using to kick off songs in attract mode didn’t work or didn’t clear properly.  The majorly fatal flaw was that I had a mode where I didn’t clear the kickout hole, so if it went into that mode, the ball would get stuck and never clear.  My bad for not having enough time to do the proper things.

After Pintastic, I was pretty much done with pinball for quite a while.  I needed a vacation.  At some point Joe told me that I should keep going.  After discussing some design ideas with Joe, I decided to start working on the second generation of cards.  Those cards are about twice as dense as the original cards (meaning up to 16 solenoids, 32 inputs, support for Neopixels, etc).  They were also a good deal cheaper to make.  If there wouldn’t have been a significant improvement to the cards, I doubt if I would have pursued making them.  I sent out for a few boards to be made and decided hey, I’ll get to the code when I get to the code.  At some point around October, I decided that I was going to give myself a hard deadline of finishing the firmware on the cards by the end of the year.  That put a whole bunch of pinball hobby time into the end of the year, and finally, today, I finished testing out a card and sending it to somebody else to play with it.

My wife asked me why I was working so hard over the last month or so…what was the point.  Well here is the deal.  There are another couple of guys who have spent the last year and a half of their lives working on another aspect of making pinball more accessible to the masses.  Out of respect for them, and all of the countless hours they have spent working on their project, they deserve me spending the month or so of my time to support them.  It was a foolish deadline to tell them it would be done by the end of the year, but when you give somebody your word, you should try and keep it.

Yesterday morning I was crimping wires and my wife again asked me what I was doing.  I responded it was so when they get the card, they can immediately start playing with it.  I wanted their barrier to trying the stuff out to be as small as possible.  Here’s a quick picture of the demo board that they got:

Gen2 Test Board

So the card is a little bit of a Frankenstein board.  Instead of using the normal communication channel, I used the USB to serial adapter that comes with the card.  (I didn’t want them to have to get a USB to serial port adapter or a RS232 to 5V converter and the board contains all that stuff anyway)   After initially using the board for a while, I wasn’t happy with the USB connection which is simply a card edge connector that is plugged into a USB port.  Grabbed an old USB connector, soldered the wires onto the edge connector, and added some epoxy for stress relief.  Now it never loses connection.  I also didn’t buy any parts to make these cards.  I just used left over parts and modified things that I had laying around because I never expected to send these cards to anybody.  This card is made up of the original cards (I built two of each) that I built for testing the hardware and nothing else.  Haven’t done a Mouser order at all, so the solenoid Molex connector is actually a cut down 24 pin header, not the real 6 pin header.  The 8 pin headers, are two 4 pin headers soldered side by side, etc.  Totally Frankenstein but it should be plenty for the integration they need to do.

So that project is done.  I have some more features that I want to add, but I could easily make a working pinball machine out of what I currently have working on the card.

The question boils down to where does the OPP go from here.  Joe (my head of marketing) says that people don’t want to populate their own boards.  I optimized the boards so they could easily be hand built by anybody with a very limited soldering ability.  The value proposition that I imagined was that you get a set of boards that you can run a pinball machine for half or a quarter of the cost of regular boards with a very little bit of work.  (It’s not like a person creating a pinball machine doesn’t need to know how to solder.)  I basically felt this was a fair trade.  At the most I would send blank boards out to people for whatever the boards cost me and be done with it.  (Blank boards cost about $15 for a whole late 80s/early 90s style pinball machine).

So my original idea was to start a Kickstarter project.  I would produce populated boards for two backers.  The first version of cards were originally sent to two people that were able to create flipping white woods, or flipping rewired existing playfields.  They were excited by their progress, but neither have produced a machine that interfaces to a controller for running all the pinball rules.  The only OPP machine that has a full set of rules is the SharpeShooter 3 machine that I created.  It doesn’t really tell me if there is enough documentation to create a full up pinball machine.  What would I really be getting out of Kickstarter except being able to maybe say that I had a successful campaign.  (I would fail to mention that the campaign was only for $100 dollars total).  The other downside is that Kickstarter takes 10% off the top, so I’d have to raise supporter rate accordingly.

After discussing Kickstarter with Joe, he mentioned I would need to do a video.  I don’t know any video editors (I guess that I would choose Blender which I have at least minimal experience), so that would be a problem.  Joe said he would help with the video editing, but that would be a huge burden on him.  He suggested instead to put something on Pinside.  In lieu of that, I’ll first put a note here.  If I can’t find the two people through the blog, I will consider adding a note to Pinside.  This gives the best chance to not bother Joe with doing any more free work for me.

So here is my email address if you are interested.  You can’t click it, you just have to type it into your email client.  I’m hoping this reduces the amount of spam that I get.

If you become one of the two lucky chosen supporters, I’ll build your boards and talk you through all the wiring.  Just for reference SS3 required 3 solenoid wings (3 * 4.01), 4 input wings (4 * .27), and 6 incandescent wings (6 * 1.60), $15 for the PCBs, 4 PSoC 4200 (4 x (3.75 + .76)) = $55.75 total.  Note:  There is currently a bug in the incandescent boards that I have which I will spin a new version to fix the issue which will also allow the implementation of lamp matrices.

Oh yeah, happy new year.