OPP moving to MA

We are currently closing up shop in VT and moving to MA.  Updates should start happening again with more development fun.  The rule compiler has gone through a major redesign, and I think the new design will be more robust and will actually be completed more quickly.

I got most of the way through the original munging of the rules, and found that I needed to start optimizations.  The code that I was writing would use brute force to compute complex boolean statements.  Example:  A && B && C.  If A is false, you immediately know the result is going to be false.  The code I was writing ended up evaluating the whole statement even though it was not necessary.  Now I could have started writing optimizations, but it seemed like a path of diminishing returns.  There are people who have spent years working on C compilers and why not just leverage their work.

If I take the rules, and then convert it to actual C code, I can then run it through a standard C compiler which will do a much better job at optimizing the code than I can.  I can also do all the same stuff with predefined functions so it will be easier to write the ruleset.

Upside is the it will run much more quickly after it is compiled, and I will need to spend much less time debugging corner cases in the code.  The downside is that it will take a longer period of time when a new ruleset is first installed on a machine.  Of course in the end product, that will happen very infrequently.  It only really matters during development.

Random mumblings

So I went over to Pinside today to see what was going on in the pinball world, and there was the inevitable thread complaining about the price of a new pinball machines because of flippers.  The specific thread that I’m referring to is http://pinside.com/pinball/forum/topic/are-you-fn-kidding-me-already.

Basically, the thread is complaining about pinball flippers, the high price of pinball machines, scalpers, prices dropping six months after the pinball is out, etc.  One thing that comes up during the thread is if Stern is going to raise their prices because their pinballs keep selling out immediately.  (Specifically the Metallica pinball sold out, I guess, in under 24 hours).  People are of course talking about it being the “best looking” pinball that they’ve seen for years.

Let me describe my understanding of business 101.  When I worked in telecom, the model that we used ended up being that the price of our product was six times our Bill of Materials (BOM).  How that was broken down was that you have the cost of the pieces going into the product (BOM) + the price to make the product (assumed to be 1 * BOM) + price for development over the lifetime of the product (assumed to be 2 * BOM) + the discount given to distributors (assumed to be 2 * BOM).  That gives you the list price is 6 * BOM.  Very simple model.  This gave the distributors a 33.3% discount, and if a distributor didn’t sell enough, he got a lesser discount.  If you scored a sale directly to a customer, that increased your profit margin by that 33%.  Simple.  (I’ve subsequently worked in other industries where they had much more complex pricing models and they really didn’t work any better than the simple one.)

Here is what I don’t get.  If Stern wanted to make more of the profit margin, they should be marketing the new pinball machine to get people as excited about it as possible and drive direct sales.  Far as I know, the number one way to see if a new pinball game is a good playing game is to actually play the game.  Since it hasn’t been made yet, that option is out.  What about a simulation of the game.  Stern probably has the layout already completed, why not release a virtual pinball or future pinball table of the game.  It should be something that your programmers should be able to kick out relatively quickly and should help them hammer out some of the advanced modes in the game.  Another way to get feedback would be to take white board versions to shows to allow lots of people play it and really get a good idea if the flow of the game is correct.  You could do the white board thing with, or without the people even knowing that they are playing a potential future pinball machine.  Might even do this continuously trying out different ideas and seeing how people react to them at the different shows.

My guess is that Stern is happy with their profit margin.  They don’t want to deal with the end user, because it is just too difficult to make that extra 30% profit.  They sell directly to distributors and are willing for the distributors to take out some of the risk because their machines are “sold out” before they make the first machine.  Maybe distributors have the pay a certain amount for each reserved machine, and then that actually funds the development.  That is a nice business model because now you have upfront money for development.

If the above is true, it doesn’t make any sense for Stern to do more marketing.  They have “sold out” all of their machines, and they don’t need to keep hyping them up.  It doesn’t really matter if they produce good or innovative machines because the machine is already paid for before it is produced.  If they produce a bad machine, it will hurt them two or three machines down the road.  They would need to get a name for producing bad or crappy machines before people would stop pre-ordering them or distributors would refuse to pick up their machines.

JJP is trying to take that 30% margin themselves and is selling directly to customers.  Because of that, they make more money per pin, but they need to hire more people to answer the phones, take orders, etc.  They also have to deal with pinball enthusiasts who are a terribly fickle bunch.  They are also a new company and if their first couple of products stink, they will end up going out of business.  (Note:  I have not played any JJP machines at this point, and would love the opportunity.  Jack, if you read this post, please ship me a NIB WOZ machine so that I can properly review it.  When the Pinball Wizard Arcade in Pelham, NH arcade gets theirs, I will make the pilgrimage.)

I’m not going to be buying a new pinball machine sight unseen probably ever in my life.  I’m not that kind of a guy.  (I’m the kind of guy that buys a 20 – 30 year old pinball machine that is proven to be a good machine.)  If you buy a machine that is new without anyone playing it, you are rolling the dice.  Maybe it will be the best pinball created, maybe it will be a complete dud.  You put your money on it without having any true information on how it will play.  (If you like the theme and the artwork, that is great, but I tend not care about pin artwork as much as playability.)  Looking at IPDB, Stern has been producing machines from about 7.5 to about 7.9 in the last eight years.  Here’s the link for the results from IPDB.  http://www.ipdb.org/search.pl?mfgid=303&yr=2005-2013&searchtype=advanced.  I would expect that range of a machine.  Not spectacular, but not a bad playing machine.

If I were one of those people who bought new machines, I would want to play the machine before I bought it.  I would want to see a simulation of the pinball game running.  I would want to a virtual pinball table/future pinball simulation to see if I liked how it played.  If I lived near a large metro area, I would expect my distributors to have a “floor” model that I could play before I actually plunked my money down.  If that wasn’t possible, I would expect early versions of the machines to be brought to pinball shows with them clearly marked as pre-production so I could play early versions before I bought one.

As a manufacturer, I would bring pre-production models to the show to get feedback on a new machine.  There are not that many big pinball shows in a year, and since they draw a lot of enthusiasts, I would want their feedback early in the process.  The earlier that a manufacturer can get feedback in the process, the better chance that the feedback can be used to make it a better product.  I would bring multiple white board pins to shows to try out different ideas and illicit feedback.  These could be completely un-themed.  When I needed to start a new design, I could take these white boards as a basis for a new design.

I’m going to post my blatherings on pinside to get some feedback.  I’m just wondering what other people think about this stuff.  More than likely it will start a flame war.  The pinside topic is http://pinside.com/pinball/forum/topic/rambling-topic-that-ends-by-blaming-buyers-for-high-prices-on-new-machines.

Display boards populated

Mark decided to work on the Flash display drivers this weekend to finish populating the cards.  He is now done, and has tested the boards and they all display.  I know I like pictures so here are some.

Here is the board taped with the Kapton stencil.  The stencil reduced the amount of time to populate the boards significantly.  The second picture shows all of the boards populated.  That would be 4 player boards, and the master display board.

Kapton Stencil for surface mount parts

All displays now populated

One thing to watch for is solder bridging especially around the dual channel FETs for driving the segments.  Here is a picture of two solder bridges that needed to be fixed.

 

Shorted pins on dual N channel FET

The short is the small bit of solder between the bottom three pins.  This is a highly magnified picture and a little touch with some solder wick and a hot iron fixed this right up.  It was relatively easy to find these shorts because the LED segment would be fully on.  Here is a quote from Mark:  “Used solder mask for first time, easier to apply paste although the thinner cross section did not reflow as well leaving numerous shorting bridges. Fixed with scalpel under microscope and retouched each lead with soldering iron to reflow.”

Using the stencil is a lot faster, but there is still a learning curve.  Here is the final picture of one of the displays being powered by the Flash machine.

Initial power on of display board

You can see some of the debug info built into the code.  At initialization, the master card discovers the displays on the i2c bus.  It then either prints the display number that it found, or prints a 0 to indicate the display is missing.  In this case, only display 1 is plugged in, while display 2, 3, and 4 are missing so they are reported as 0 on the master control board.

The cables haven’t been finished yet, but that should happen later this week.  Pinball night is moving to Wednesday because of scheduling conflicts, so maybe we can actually run a couple of games and be able to see how many credits, and which ball the game is on.

The displays are very bright, and I think that we are both pretty happy with how they are coming out.  I’m glad that I added a voltage regulator to allow the displays to be dimmed to the appropriate level.  The mounting holes are a little bit small, so these have to be drilled out a little bit to use the original mounting hardware on the Williams game.

Hopefully another post later in the week about it working, but more than likely it will take another day or two to debug the interface to the pinball machine itself.

If anyone owns a Williams Flash game and would be willing to take pictures of their backglass, please get in touch with me.  That is the one thing that is really messed up on this game, and I want to do a translite, but the more pictures that we have, the better the translite will be.  The backglass on this machine is completely trashed, so any pictures at all would be appreciated.

Williams Display replacement boards displaying characters

The display replacement boards are currently displaying test characters.  We used a single player board to verify the i2c communication for all the player boards.  A new version of the firmware is in the google code repository.  It is much more functional than the previous version of code.

Mark just needs to build up three more player display boards, and then testing in the Williams Flash pinball machine should be able to start.  That code is pretty simple, but I did add a software filter into the control signals, so there might be one or two more bugs there.  The current revision of the code is 00.00.03.  I will rev step the code to 01.00.00 when the integration with the physical pinball machine is done.

Since tonight is pinball night, it might be interesting to throw the single board onto the machine and see if we can get the credits/match to work for the first time.

 

Continuing work on Disaster compiler and display boards

Display replacement boards:  Did a good amount of work a couple weeks back, and the processor is up and running.  It is starting to display some test digits.  I’ve added discovery code to discover how many slave display boards are installed.  The initial code also displays which boards are installed to make troubleshooting easier.  This allows the board to only operate with a subset of the player display boards.

Disaster:  Working on the compiler for parsing the rules file.  I’ve spent a lot of time on this over the last couple of weeks, and I’m just now getting to the point that I can parse the whole file.  Unfortunately it doesn’t do anything with the information, but it is starting to fill out the data structures.  These data structures are going to be the ones that the java uses to run the rule set.  There has been a major update to the rules file.  I went back and forth trying to decide whether the file should look more like lisp, or more like C, and I ended up going with it should look more like C.  This means curly braces and parenthesis instead of all parenthesis.  This was more pleasing to me visually and more what I’m used to seeing.  It will probably continue to take me another couple weeks to finish this work off, and get something working.  I ended up not using pyparse because I could not figure out how to get it to output into my data structures.  I could have had it verify the syntax, but that is not the most difficult aspect of the project.

Restoration:  One of the local people who runs pinball machines in establishments has given Mark and I a POTC machine to fix up.  The last couple pinball nights have been spent fixing that machine.  It is amazing how easy it is compared to the early 80s machines that I have been restoring.  The machine seems to want to tell you what is wrong.  With the other pinball machines, it seems there is a lot of divining what is wrong with the machine.  The nice part about this, is in a night we can fix a lot of things that are wrong on the machine.  The machine’s ship was not working properly and had a lot of other issues including the slingshots not operating.  Fixing the ship was a lot of fun because it was completely mechanical and is a simply great toy on the playfield.  I particularly like when you have one more hit on the ship, and it starts floundering.  Very cool effect.  That machine should be restored in the next week or two, and we might get a chance to work on a few more machines that this guy has in the area.

Starting Disaster Compiler

I came to the realization a couple weekends ago that I needed to write a compiler.  I was hoping to avoid it by simply reducing the type of commands that the pinball machine could run, but I keep coming back to the issue that I want this to be a generic pinball driving machine.  That being said, the pinball rule set must be able to handle all sorts of different instructions.  Some of the instructions will be high-bred instructions to make writing pinball rules easier for users, but many will simply be math like instructions.  I’ve spent a good deal of time trying to come up with a good number of these high-bred instructions, and a good amount of time on the architecture of the rules file.  I will eventually write a document on writing a pinball rules file, but doing a first cut for my simple pinball machine has really helped to make the ideas concrete.

Here is a link to the current rules file  (I’ll point this out so that people can find it more easily and not need to download the whole code base):

http://code.google.com/p/open-pinball-project/source/browse/trunk/Eclipse/1009-HostCtl/rules/simplerules.txt

The first section of the file is simply stating what hardware needs to exist for the pinball machine and names each of the solenoids, inputs, and LEDs.  This is so each used hardware pin can be identified by name.  Next section is variables and indexed variables.  This is going to be implemented as a simple array of integers with the dictionary (keyed off the name) handing back the offset into the array.  Next sections are sound and video clips.  These will be pre-allocated so they can quickly be switched between or even play multiple sounds at once.

The next section contains the processing chains.  This is the section that requires a compiler.  The input pins named in the above sections can be used to alter the operation of the machine.

A simple example would be kicking the ball into the shooter lane.  While it would be easiest to kick the solenoid, and just hope that the ball got onto the playfield, it might not necessarily happen.  The solenoid might not be working properly.  One way to deal with this is to kick the solenoid and check the switch if a ball shows up in the shooter lane (one of the input switches).  At the same time, if the ball doesn’t show up, you want to try to kick the ball another few times just in case the issue fixes itself.   (Maybe two of the balls were interfering with each other, or maybe the solenoid was a little sticky, and a second kick would work.)  If the maximum number of retries is exceeded, the pinball machine should display an error and not allow anybody else to put more money in the machine.  This simple action of the pinball shows that it needs to support timers, math functions (incrementing the retry count), comparisons, and reading switch inputs during the loop.  The process chains that implement this are Proc_Start_Ball_Init and Proc_Start_Ball_Start.  The init function is run once when a mode is entered, while the start routine is run after each tick.  At the end of this chain, the pinball machine will move to the Mode_Ball_In_Play or Mode_Error.

I originally thought that I could implement this with a simplified amount of functions, but during writing the rules file, I found it was much easier to assume that I had that ability to use anything that is available to me in any normal language.  That means that it is time to write a simple compiler.  (Luckily it is only the top end of the compiler to convert command lines into pseudo-code.  I don’t need to write the bottom end of the compiler.  Of course, if I would write the bottom half of the compiler, it would be much faster, but then I would need the parser to create code and then compile the generated code.  I currently believe it will be fast enough without doing this last step, but it is arguable that it would be a cleaner design using self generated code.)

This has taught me not to laugh at my friends when they were taking compiler theory in college, while I was taking fields and waves.  Maybe I should have taken it as an elective.  Somebody on the web wrote a article about how a pinball machine is the ultimate renaissance man machine.  It requires electrical engineering, mechanical engineering, graphics design, animation, and computer science disciplines.  I have certainly enjoyed the strange paths that it has taken me and allowed me to probe some new areas that I was not expecting.

Anyhow, there are also high-bred commands.  An example would be the LED_ROT_RIGHT/LED_ROT_LEFT commands.  These commands are very useful for implementing the “change lane” function.  In most modern pinball machines, when you hit the right flipper, the inlanes, or outlanes lights rotate to the right so that it makes it easier to complete all of the lights.  The left flipper sometimes does the same thing to the left.  (It actually freaks me out when playing early 70s machines where you actually have to shoot accurately instead of just rotating the lights to complete a set of lights.)  In the pinball machine, hitting the right flipper simple rotates the subset of lights.  The high-bred command rotates the group by using the LED_ROT_xxxx command, then providing the mask of bits to rotate, and the variable containing the currently lit bits.  The Proc_Flipper chain does this processing.  It is a high-bred command because it does a lot processing beneath the command, but the user just has to write a simple upper layer command to get it to happen.

If anybody has any comments on what they would need in a rules file, I would be glad to hear them.  Once the framework is finished, it will be simple to add more commands, but suggestions would be appreciated to make sure that I don’t miss major functionality that is required.  It is always best to plan for major features at the start to make sure that the architecture supports them.

Java, java, java and working on the language

So I drew up a simple pinball machine to verify the scripting language is working.  I always find it easier to try and implement a real example to make sure I have most of the functionality that I need to implement a machine.  Hopefully when you click on the picture, you can see enough of the writing to understand what I’m trying to do.

Simple Pinball machine from three test cards

I populated three of the cards (a solenoid driver, an input card, and an LED driver card).  Here is the quick pinball machine that I drew up to make sure that the machine could be implemented with the “generic” scripting language.  I’ve spent the last few days trying to write up the script for this machine to make sure that I have everything that I need.

If you currently grab the newest stuff from the repository, the java code resides under the Eclipse directory.  VLC needs to be installed on the base machine, and in the build_notes.txt file it lists the flags that need to be handed into the VM and handed to the base class to start the pinball application.  Right now it simply runs two different movies, one after the other and repeats.  If you press the ‘s’ key, it swaps to the other movie.  If you press the ‘x’ key, it exits.  I did this to verify that I could swap between movies quickly enough during game play.  I’m happy with the response on my PC (which isn’t the zippiest in the world), but I’m pretty sure it will work well enough on the real hardware.  I will eventually put this all together in a single application.

The script file that I’m working on is named simplerules.txt.  I’m still adding functionality to the script language, but I’m pretty happy with how it is coming out.  Here is some general information about how it will work.

The scripting file is broken down into a couple different areas:  hardware identification,    variables,  modes,  and chains.  (Actually after popping it open, I need to convert all the tabs to spaces to make it look a lot more readable.)  I’ve made all keywords capitals.   (These are reserved words for the scripting  itself.)

Hardware identifies the number of cards in the system, their configurations, and the names used to refer to each of the hardware bits.

Variables are broken down to single variables (one per pinball machine) and indexed variables.  A good example of an indexed variable is the player’s score in a multi-player game.

Modes are the states of the pinball state machine.  When playing a game, the controller moves between these states and does things differently for each state.  One state might be attract mode which tries to get people to add coins.  Another mode would be press start mode which happens after they add credits.  Then of course there are tons of different modes when a game is being played depending if you are in a multi-ball mode, or a special scoring mode.  These are highly dependent on the game rule set.

Chains are processing chains.  They can alter the mode if something happens, or change LEDs on off, etc.  I’m planning on having multiple chains per mode.  These chains are the init chain, processing chain, video chain, audio chain, and LED chain.  The init chain happens once when the mode is entered.  The processing chain happens every tick (approx 10 or 20 ms).  The video chain allows videos to be streamed during each mode.  (Multiple videos can be in a chain, so it will play one, then the next, then the next, and repeat that chain.)  The audio chain allows songs to be streamed.  The LED chain allows a series of LEDs in a certain sequence.  All attract modes use something like this, and most modes like multi-ball would use something like this.

Well that is the idea behind the script.  Hopefully by the end of the weekend, I will have finished the rule-set for the simple pinball machine.  Next would be coding the java which shouldn’t be that hard, but will probably take a couple weeks.