4/24/2015, Measure how many times?

So the OPP team is getting really close to ordering the final playfield art.  Through my incompetence, this has taken more time than it should have.  Back in January when I had the top of the playfield disassembled, I should have printed out a template of where all the features were on the playfield and verified the positioning of the template.  Well, I did print it out, and looked at it, and said, hey, everything looks about right.  I didn’t take the time to really examine it and make sure everything was spot on.

So in the last two weeks there has been a huge push to finish the playfield art.  The art department (located at OPP mid-west headquarters) had to spend many a late night to get it done, and they came through.  The only problem is I printed out an art proof, and I suddenly realized that many of the inserts were off about .15 inches.  I realized the enormity of the situation around Monday of this week.  I also realized that the first template I printed back in January was not correct because FedEx printed it and shrunk one of the directions to fit on their printer without telling me.  That being said, if getting a printout from one of these places, insure that they don’t “help” you by shrinking it to fit.  The FedEx place that I use can comfortably make prints that are A1 size which is 23.4″x33.1″.  I allow at least 1/2 inch of margin around the edge for safety.  Last night I updated the template, and today I’ll get another printout to verify the newest template.  The art department has already been sent the template, so hopefully this will be the end of the debacle I caused.  The take away is to not rush things.  Spend the time to verify your playfield template even if it means that it will be another week or two until you build the playfield back up.  It will be worth it in the end and will end up taking less time.

So verifying the locations of the inserts was more difficult than expected.  I tried to use the method the Goonie’s guy did with a flashlight, and just could not get enough light to really tell the location of the inserts.  The method I found which worked best was the old 100 watt incandescent bulb in a desk lamp beneath the playfield.  I turned out all the lights in the room and it was suddenly very easy to verify the locations.  The lamp had to be moved a couple of times to get light at different spots in the playfield, but it made the verification really easy.  I then used a digital caliper to measure the offsets.

Here’s a couple pictures of the art with the offsets marked:

Next up was updating the template.  My tool of choice is Gimp because it is open source.  I truly dislike the program, but every once in a while, it surprises by making something easy.  The menus are really non-intuitive to me, and I’m almost always certain that it could do something, but I just don’t know how to make it happen.

Here’s the Gimp process for modifying the template.  First create a new layer from the previous template layer.  Only view the one new layer, and highlight it so you are editing just that layer.  Now change the cursor to rectangular select by pressing the ‘r’ key.  Now for each part of the template you want to move:

1. Draw a rectangular select region around just the piece that you want to move.
2. shft-ctl-L, float the selection
3. shft-ctl-O, offset floating layer.  (Change the units to inches, and change the edge behavior to “make transparent”.  Modify the x offset and the y offsets.
4. ctl-h, anchor the floating layer
5. Repeat the above steps for each item that needs to move.

That makes updating the template a breeze.  (It just took me 30 minutes of searching the web to figure out how to do it efficiently).

Much of the playfield is going to be painted white so that the vinyl overlay will look as good as possible.  The vinyl printers can’t print white reliably.  The options are to use an opaque overlay (the overlay is white vinyl and then the art is printed on top of that), do a second overlay that is simply a white backing layer where necessary, or to paint the playfield white where the wood grain should not show through.  The first option won’t work because the inserts would be too dark.  The second option would work, but doubles the cost of the overlay, and it would involve a lot of xacto knife work to get it right.  The last option seems the simplest to me.  If I get white paint on an insert, I can easily clean it off using paint thinner or water.  I’m planning on two layers of white, then another layer of clear to make sure that the vinyl overlay will adhere properly.

The OPP cabinet department has been hard at work on painting the black background paint on the cabinet.  That is completed, so just one more sanding, then applying a clear coat layer and the cabinet art can be installed.  Then it would be a rough sand and a couple of clear coat layers on top of that to make it rock solid.  I found that 600 grit sandpaper is the sweet spot for insuring the paint is smooth before applying the next layer.  I tried using 440 grit, but it removed too much material.

The OPP software department has finally started to work on the actual code for the machine.  They spent a good bit of time this week, and right now in simulation mode, the game starts, inlanes are rotating using flipper buttons, solenoids are getting reset, etc.  Having written out the rules in advance helps a lot so that the software department can quickly refer to them when questions arise as to what should happen when x gets hit.  There have been some minor updates to the rules documentation, but it is mostly clarifications.  The original version of rules looks like they were written by somebody that was watching TV at the same time as writing the pinball rules.  The second rev cleans up a lot of the language/grammar issues.

Here’s a quick link to the current rules.  All those attending Pintastic can study up to find the holes in the rules and use them to get the highest score possible.  It is saved as an .odt file (open document text).  RuleSheet

 

4/17/2015, So The Teardown Begins

New wordpress interface is giving me issues.  It keeps converting my posts into pages.  Grrr.  Stop it, I just want it to be a blog post.  I apologize if it sent out multiple emails to the one follower I have.

So I’ve played two or three “games” at this point.  A game is essentially as follows:  run the pinball framework which starts in attract mode, press the start button for as many players as you want in the game, the machine serves up the first ball, each switch scores you one point, when the ball drains either move to ball two or the second player, at the end of three balls go back to attract mode.  Truth be told that is all it does at this point.  I have verified all the switches are working, but there really aren’t any deeper rules at this point.

I have a bunch of cabinet stuff to do, so while I work on the cabinet, I can continue coding the rules.  The pinball framework has a debugger built into it where each of the switches can be simulated on the machine.  I don’t really need the physical pinball machine to program it with the simulator, so why not tear it apart.

Two weeks ago I took the cabinet apart and started working on finishing it.  I sanded everything down to bare wood on the base of the cabinet (why?  I could have just rough sanded it, and painted it black, but I didn’t realize that until too late.  Maybe sanding it down to wood will make it look better.)  Since then, I’ve got two coats finished and sanded in between.  I’m planning on at least one more coat of black, then a coat of clear before attaching the vinyl side art.  After that, probably one or two more coats of clear to protect the vinyl.

One of the riskiest things is the playfield art and insuring that it matches up perfectly with the playfield holes/inserts, etc.  This week, I decided to try and reduce risk by printing a copy of the newest playfield art, and verifying the position of each of the inserts.  I did a rough job of this before and moved some of the inserts slightly, but now I want to make sure it is absolutely perfect.  If the first order of the playfield art is exactly correct it will save a lot of time and significantly reduce the time before I can get the machine back together and start really play testing it.  I’m also going to verify every single post/hole in the playfield to make sure that the holes are easy to find when they are covered with the vinyl overlay.  The goal is to get the playfield overlay ordered by the end of this month.  Joe has essentially finished the art, it’s just waiting for me to re-verify the insert positions.

The speakers are finally mounted on the piece of plywood that I cut out so many months ago.  I have a beautiful pieced of pleather which should go with the whole western theme.  I would have like real leather, and to tool a design into it, but I don’t have time for that sort of project.  That might be one of the things that I can eventually update.

That is really all that is happening right now.  Things seem to be on track to get it finished which makes me happy.  When it goes to Pintastic, it isn’t going to be finished, but I’m hoping it will be very playable.

3/22/2015, Quick video update

Most of the point of this post is just to say I threw a new video up on youtube.  Some follow the OPP youtube feed, many don’t, so here’s the pointer to it.  I tried to turn the camera 90 degrees to get a better shot, but it looks atrocious on youtube when it rotates it.  I have to figure out a better way to take videos that show the backglass/LCD and the playfield.

The beginning of the video shows a short LED light show.  The camera angle really needed to be higher to see the insert lighting.  Multiple static  images are displayed on the backglass.   Both of these are controlled by using chaining.  The LEDs use an LED chain, while the images use an image or video chain.  This allows the programmer to focus on rules instead of blinking lights.  Sounds are also being played in a loop, but I don’t have the speakers hooked up yet.

Next in the video, the start button is pressed, and the first ball is served.  The skill shot insert is blinked rapidly.   (Again, nearly impossible to see in the video).  The ball is plunged, and scoring starts.  The left and right flippers rotate the inlanes to help the player complete the inlanes.

The ball eventually drains and the next two balls go similarly.  At the end of the last ball the machine resets and starts going through the attract mode again.  The last scores remain.

That pretty much proves out all the features needed to run a game.  The big pieces of work coding wise are creating the new rules.

The insert lights sometimes flicker when the solenoids fire.  This is partly due to the fact that I did part of the fix for LEDs, but didn’t have enough parts to finish it.  The rest of the parts should be coming in this week.

Double flipping still shorts out the power supply, but the parts necessary to correctly fix it should also be in that package.

A lot of updates to the repository in the last week.  Look at the commit comments if interested.

3/15/2015, Another two weeks, oh how quickly

Another two weeks have come and gone.  Things are moving quickly, but I wonder if they are moving quickly enough.  I guess time will tell.  We are now at less than four months until Pintastic New England.  I noted to one of my friends, “Well, there is no art.  I’ve never hooked it up to a computer to keep score.  There is no sound.  There is no backglass.  There is no front door on the machine.  I’ve never tried to run LED changes, rules, and serial comms at the same time.  You have to follow a very specific boot sequence or the power supplies will incorrectly detect a short.  Besides those minor things, I’m sure it’s almost done.  Yeah, no problem.”

So that being said, let’s look at what has been done in the last two weeks:

Pinball Framework:  Added support for updating multiple LED cards at once by passing list with a mask for each card, and set bits for each card.  Added parallel port processing to support updating the incandescent driver boards.  Updated solenoid kick command and tested.

Started writing actual code for SS3.  All eleven modes have been designed with four different difficulty levels.  There are also a couple side goals to try to get more  points.  It should be full featured enough for the show.

The LED update thread updates the LEDs every 100 ms.  I measured the timing for the update to occur by bit banging the parallel port and it averages 1.5 to 2 ms.  That is probably the most time consuming thing that the SS3 needs to do all the time, so I’m feeling good about it only taking 2% of the processor.

Part of the Pintastic New England contest is to present the final cost of the pinball machine.  This includes the price of the base machine, price of all the pieces added to the machine, and money spent.  Of course, the time put into the restoration is all under the table.  So here is a quick rundown of the costs so far, and what I see in the future:

• Playfield, $75.  It was a populated playfield with plastics.  Everything was on the bottom.  Many of the drop targets were broken.  It included wiring, which I reused.
• Cabinet, $50.  A Gottlieb Gladiators cabinet.  Completely different pinball manufacturer and the only “fitting” that I did was making sure that the playfield fit inside the cabinet.  I assumed everything else could be fixed.
• Backbox, $30.  It is a secret service backbox.  It was a good buy because it contained extra light bulb holders that I could use to replace the broken ones on the playfield.
• Driver/Input cards, $100.  These are OPP cards that I had made about two years ago.  The $100 also includes the connectors needed to connect to the cards.  The boards are through-hole, so I soldered them up myself.  These are the same cards that Joe and Cactus Jack are using.  Some of the FETs and connectors are too close to each other, but Joe actually came up with a great idea of mounting the FETs to the bottom of the board.  I just squeezed everything together which also works.
• Power Supplies, $50.  Simple PC power supplies that are tied together.  Currently using four, but I’m probably going to drop that number down to three because many things are still too powerful.
• Art, $150.  This assumes three orders from BannerBuzz.  I’ve already ordered the side cabinet art.  I expect to need two more orders from banner buzz because the inserts might not line up perfectly.  The cabinet side art was $80 because it is so much area, but it looks really nice.
• LEDs/parts, $100.  Pinball life got a bunch of money for LED light bulbs.  That is the majority of the money.
• LCD monitor, $80.  Originally it was going to be for the backpack pinball machine, but well, it was sitting in the basement, so now it is in this machine.  It fits the cabinet perfectly, so I’m happy with it.
• Old PC, free.  My wife’s grandmother’s old PC that I built for her eight years ago.  It was too old, and she has a laptop now, so she sent it back to me.  I re-purposed it, and hope it is fast enough to run the pinball machine.
• Lockdown bar, free.  Joe provided this since it was sitting around.  Thanks Joe.

So I’m expecting the total for the whole machine to be $635 at this point.  It is going to be interesting going into the restoration throwdown where some of the people threw in a CPR playfield which can be $700 or $800.  My guess is that the end machine, even with overruns will be a total of about $700.

So Friday morning, Google sends me an email that Google code repository is disappearing.  Github has finally taken over the world of open source.  Because of that I’ve moved the repository onto Source Forge for the time being.  I’ve already done the import, and will probably keep the two repositories in synch for the next six or eight months.  At that point, I will stop updating the Google code repository and let it die.  The source forge repository is located at http://sourceforge.net/p/open-pinball-project.  I may eventually move it to Github.

I’ve been running a lot of tests with the incandescent boards, and what I thought was fixed, still has issues.  After running different patterns on the boards, it turns out that I’m not getting clean signals on the data lines going between the cards.  A single walking 0 works, or a single walking 1 works because there is only one data transition.  A pattern of 0x55 or 0xaa causes issues and gets flickering to occur.  The only signals that can have that effect is the data lines between the boards.  Simply put a series termination resistor in there and the problem will be fixed.  Bummer is that I don’t have any low value resistors sitting around.  Grrrrr.

I was going to do a video, but just don’t have time.  I’m pretty close to a breakthrough video, that I’m going to wait for a little bit more before tossing up the next video.  It would be nice to have a good video of the framework running, with sound, etc.  Another couple of weeks and all that should be happening.

 

2/9/2015 – GenPyCode and PinballFramework

The Frankenstein Sharpe Shooter 3 machine is slowly coming alive.  Stealing parts from multiple types and multiple brands of machines is starting to make things difficult for me.  The lockdown bar didn’t quite fit properly, so I needed to modify it a little bit.  That has been completed, but then adding the shooter rod, it seems that Gameplan used a different length of shooter rod than Williams.  (Why???).  I mounted the lockdown bar a little too low in the cabinet, so now I’m going to have to remount it about 1/4 inch higher.  (The good part of that is that I can now mount the flipper buttons, and stop using an electrical junction box to press the flippers).

I stole most of the “rules” running in the game from Joe’s Blue October demo I did over a year ago.  That uses coin drops and presses of the start button to start a game.  Ooop, I don’t have either of those switches hooked up, so I can’t start the game at this point.  Little things like that keep popping up like moles and you just have to keep knocking them down.

A lot of time has been put into GenPyCode the last few weeks. For that one person that is actually reading this and has not been following, the GenPyCode Python program takes a rules file and converts it into Python classes that are then run using the PinballFramework. It takes much of the grunt work out of creating the necessary classes to run the individual pinball machine rules.

I’ll eventually write up a document on the rules file, but a lot of it is self explanatory.  The solenoid section describes how many solenoid cards are in the system and their configurations.  The input cards (switch inputs) section describes the number of switch input cards and their configurations.

GenPyCode is now passed a parameter with the output directory to put the generated files.  In my case, the command line used is:

python GenPyCode.py -rulesFile=ss3rules.txt -outDir=SS3

This uses the ss3rules.txt input file and stores the output in the SS3 directory.  Previously, the generator always used the same output directory and input file name, but it is useful to be able to work on rules for multiple machines at the same time.

The files in the SS3 directory are then moved into the PinballFramework directory to be run by the pinball machine.  The pinball framework has been modified to support multiple rulesets.  Here is my current command line for the pinball framework and SS3:

python PinballFramework.py -port=COM1 -simWidth=854 -debug -rulesDir=SS3

-port=xxxxx Lists the serial port used by the solenoid/input cards.  If this parameter is blank or does not exist, the framework will disable serial communications.  This is very useful since I’m not sitting at the pinball machine most of the time when I’m writing the rules.  Instead, I’m simply simulating the switch inputs, etc.

-simWidth=854 Simulation width of the screen.  The pinball machine runs in full screen mode, which makes it nearly impossible to develop.  Using the simWidth parameter, the LCD screen is scaled down, and a menubar is added so that it can easily be moved around.

-debug Creates the debug window which contains all of the solenoids, input switches and LEDs.  By pressing buttons in the debug window, switch inputs and solenoid inputs can be simulated.  The one problem with the debug window is that it does not have a scrollbar on the side.  SS3 has 2 solenoid cards, 2 switch input cards and 6 LED driver boards.  The debug window is too tall, and the bottom LED boards can’t be seen.  That’s probably going to be the next thing that I fix.

-rulesDir=yyyyy Directory location of the GenPyCode generated files.  It also contains the rulesFunc.py which fills out the logic for the game.  (The generator creates an empty shell for this file called rulesFunc.py.gen).

Joe gave me a bunch of great LCD screenshots which have been integrated into the attract mode on the backpanel.  In attract mode it cycles through the images which is really the first time “rules” are being run on the machine.

Lightbulbs are now brighter than I was expecting.  I’m guessing that I was shorting a 5V to ground through the rotisserie.  (There were a bunch of bulb sockets that were very close to the angle aluminum of the rotisserie.  I thought I threw enough non-conductive foam in there to isolate it, but it seems like I didn’t).  I put the playfield into the cabinet and lit it up using incandescent bulbs and it looks spectacular (in an early 80s sort of a way).  I now believe my calculations that 5VDC on incandescent bulbs are brighter than 6.3VAC on the bulbs which is what the math says.  The LED bulbs are still going to be great in the inserts to make those really pop.  (The mode inserts are a really dark purplish color which is going to mask a lot of the light).

There is a flipper issue when double flippering.  It is drawing too much currrent and shutting down one of the power supplies.  I believe that I have a fix, but don’t have the parts to make it happen.  I need to make a mouser order and get the stuff needed to fix that.

Next up is working on the getting all the lights firing as expected.  That will make the attract mode that much more exciting.  The LED functions also need to have better support for multiple cards.  (Right now they support only four cards, but since SS3 has six LED cards in it, the passed parameters need to move from a single parameter to passing in lists.)

1/19/2015, Backboxes, Playfields and Screens, oh, my!

A couple weekends ago, I finished populating the playfield.  While not a Herculean task, it was a little bit annoying since I filled all post holes because they were almost all pulling out and not holding properly.   After the clearcoat, I used a nail to punch the center of the bamboo skewer, than a small drill bit to drill the pilot hole.  It went surprisingly well, and I’m now happy to report that the playfield is probably in better shape than it has been for 15 years.  Here is a quick picture of the populated playfield.

I decided I wasn’t going to fire up the playfield again until I got the backbox in better shape.  A couple weeks back I installed the power supplies, and the MaxPower card that creates my 48V.  (On a side note, Joe just bought a 48V power supply for dirt cheap (around $20 or $25 with shipping).  Maybe the time of creating your own power supply from multiple PC power supplies is over.  That being said, I will not miss it.  Doing it that way requires a lot of extra wires which most of them are unused.)  The four PC power supplies take up the top 1/5 of the backbox.  The MaxPower board takes up a small amount of space just below them.

I was handed back a small form factor PC (mini-ITX based card) that was no longer wanted.  I had that sitting on the side running windows XP, but it was cumbersome to move that around with all its extra stuff.  I decided to rip that apart and also mount that stuff in the backbox.  That includes another PC power supply, the mini-ITX motherboard, and a hard disk drive.  All of that stuff will be removed and replaced with a single Raspberry Pi eventually.

I mounted a speaker panel which also allows the bottom half of the monitor to show through.  The top half of the monitor is going to be behind the backglass and will have a transparent window in the backglass so that I can display images.

I’m having troubles mounting the monitor, but I’m trying to spend a good amount of time to get it right, so that it can easily be removed for “servicing.”  That involves building a bracket of some sort out of metal.  I have the metal left over from the ground that was in the back of the backbox.  Plenty of metal, but I need to make clean 90 degree bends with a good degree of accuracy.  I don’t own a metal brake, so I’m being very cautious.  Here are a couple of pictures of backbox, and backbox without the monitor.

Last thing that I spent a good amount of time on these last few weeks is adding to the pinball framework or more specifically to the GenPyCode program.  That takes the rules.txt and generates Python files that are used by the pinball framework.  The generation of all the files except one is complete at this point.  For details look at the Subversion repository check-in.  Within the next week or two, I should have that completed and should be back to being able to start working on the actual rules of the machine.

I have not finished wiring the GI, and it is simply a couple hours of work that I need to do.  Since the lights were so dim, I didn’t feel like bothering, but now with the LED bulbs, I’m hoping to get back to that.  I need to start working on putting the playfield in the cabinet, but that is only after all the wiring is done.

It’s been a busy couple of weeks, but things are moving quickly.  It’s amazing how quickly two weeks goes by, and that deadline of the beginning of July is looming ever closer.

Progress 7/14/2014

I’ve been working on the GenPyCode project in the Google code repository, and  rewiring the SharpShooter II playfield.  Progress is slow but steady.

Starting with the rewire of SharpShooter II.  The initial step is to get all the solenoids firing and active on the playfield.  Because the driver boards can statically configured, it is simple to set them up so the machine will be playable.   The machine won’t play a game, but will continually serve the ball onto the playfield, all the bumpers will work, the kickout hole will work, and I’ll probably daisy chain the drop targets so you need to knock down all of them to have the bank reset.  The end game will support two ball multiball, but that would take a bit of programming.

Right now, I’ve routed many of the wires that source and sink the 48V for the solenoids.  The 48V source is brought to the playfield using three lines:  upper playfield solenoids, lower playfield solenoids, and flippers.  Four wires are used to return the current from the two solenoid cards.  Three wires are used to source the current for the lighting.  The playfield GI was originally broken into two circuits.  A third circuit has been added to source the current for the feature lights.  Looking at the current rating of the wires, I’m definitely over doing the number of wires, but it allows for me to the ground wires on the back of the playfield.  (Less soldering for me to do.)

The feature lights for Disaster are going to use LEDs.  Since this is a retrofit, the feature lights are incandescent bulbs.  While the driver that I made was OK for individual LEDs (about 20 mA), an incandescent bulbs need approximately 200 to 250 mA.  That of course means that the original design will not work to sink that much current.  I’ve sketched out the new design for the drivers, which requires an individual MOSFET for each feature light bulb.  The serial register also needs to have open collector outputs so that the FETs can  be used as high side switches and the existing common ground returns can be reused.  The parts for the new drivers are ordered from Mouser.  I just need to get off my butt and layout the driver cards and order them.  I’m sure that I can fit the design on a 5 cm x 10 cm PCB, so  a single order will give me 20 PCBs.

Onto GenPyCode updates.  The GenPyCode Python project takes the simpleRules.txt file and generates the Python files necessary to run the pinball machine.  This is then run using the PinballFramework to operate the actual machine.  I originally did a lot of the code using Java, but since the Raspberry Pi doesn’t have perfect support for Java, I decided to rewrite it using Python.  Since then, the Python version has been significantly updated and more features added.  I’m now going back and adding the newer features into the simpleRules.txt.  It also adds features for more debuggability.   It currently creates python files for solenoid bits, input bits, and LED bits.  It also creates the constants for the sound files.

Next steps will just be continuing in the same vain.  I’m hoping to finish the wiring on SharpShooter II and then take a video.

Progress 6/20/2014

Haven’t had the time to do an update lately, so here it is.  Started by adding two new categories to the blog.  The first one is Pinball Framework which marks the entries about the Pinball Framework.  I went back and marked the last two posts, but probably won’t mark earlier ones.

So I added a couple more things to the Pinball Framework.  The new additions include image chaining, added ability to set player score display positions, support for non-HD aspect ratios, and new GUI for debugging cards.

Joe asked if the background image could be changed by making a call.  I one upped the request and added in support for image chaining, so now a group of images can be shown on the backglass with a wait in between each image.  At the end of the chain, the chain can be repeated to show the images again.  Chaining simplifies the programming of the backglass images since it happens independently of rules processing.

Player score positions were previous automatically located by the software which only worked for a single layout of the backglass.  Now the displays are located by picking the center point of the display, and the number of pixels for the height of the characters.  This gives much more flexibility.  While in that section of code, support was added for non-HD aspect ratio displays which is needed for the backpack pinball machine.

Last thing I added was a new GUI for displaying the state of the card inputs.  Previously there was a python script that needed to be configured for the card that was being tested.  The new GUI auto discovers the cards attached, and populates them in the GUI.  It then polls each of cards getting the input status.  It also supports kicking an individual solenoid.  A good general debugging tool which might end up being easier for other people to use.  It is located at PinBrdGui in the Google code repository.

While talking to Joe, he also mentioned he wasn’t sure he understood the wiring.  I wrote up a quick diagram of the necessary wiring and how it simplifies the required wiring.  Here’s the quick diagram.  Each of the driver boards support up to eight solenoids, but I only threw four down because I didn’t want the diagram to get too busy.

Now the next new category.  It is called Sharp Shooter 2.  I picked up an old racked out Sharp Shooter 2 playfield and a cabinet for it to go in.  Designed by Roger Sharpe who is one of the gods of pinball.  I hope I can make him proud.  So I was taking an old Camelot playfield and driving that with the driver cards.  There was always a nagging feeling that the project would be finished and the machine would be a dog to play.  Got the SS2 playfield for a good price and it should be a better playing machine than Camelot.

SS2 was originally a Z80 processor based machine.  It was produced by Game Plan which truth be told, I didn’t even know was the name of a pinball manufacturer.  Some information can be found on the internet, but I can’t really figure out the rules, and even so, I’m doubting they were very deep.  So I’m going to drive the playfield with new driver/input cards and add an LCD for a backglass/scoring.  The original playfield was driven with 24 volts.   I’m going to use 48V but make the solenoid pulses short.

Here’s a few quick pictures at the beginning of the project.

There is a set of eleven inserts, so I need at least eleven modes.  Here’s what’s currently in the notebook in no particular order:

1. Sharp Shooter – some shooter inserts are lit red, some are lit white, if all white are knocked down reset with new group of red and white.  First red hit ends mode.
2. Hustle & Jive – turn off tilt bob, fill all six upper lanes without allowing flippers to rotate the inlane lights.
3. Sniper – can only hit blinking shooter target, then next one lights, etc.  Get five to complete mode.
4. Target practice – blink random pop, then random shooter, then random inlane, spinner orbit, finish with kickout hole.
5. Check hideouts – must get two standup targets within 60 seconds.
6. Call the posse – spinner lane ten spins, then kickout hole, starts two ball multiball.
7. Bar fight – hit each bumper ten times, each time a bumper is hit, it lights for 10% more time.  At ten hits it is constantly on.
8. Ride for help – 5 orbits, then sink kickout and get two ball multiball.
9. Sharpe Attack – Get five shooter individual targets, no cradling allowed (reconfigure flippers for no hold)
10. Killem all – drop all shooter targets three times, sixty sec to drop bank, resets when bank finished
11. Track the bandits – collect all lanes (can use flippers to rotate), knock down all shooter targets after all lanes collected.

That’s the current thoughts.  I’ll start by simply rewiring the bottom of the playfield for the new driver/input cards.

 

More PinballFramework Updates, 5/29/2014

So as it currently stands, the pinball framework is in good enough shape that a pinball machine could be run using it.  It has been a long journey, but I’m happy with how it currently stands.  Below lists the biggest features that were added in the last two weeks:

• Timer thread processing so now timers can be set up
• Sound chain processing, so now sounds can repeat after a certain delay.
• Background music is now supported.
• Added support for scoring using switch inputs
• Added support for communicating with hardware cards
• Added support for a background image

Unrelated to the PinballFramework…added generated documentation to the archive in a zip file.  Added partially completed BackpackPinball layout…but instead of finishing that, I ended up working on the python code.

Next step will be finishing the BackpackPinball layout (the ruleset is currently implemented using the framework).  The framework needs to have non-HD format sizes supported to support the monitor I bought.  Gotta get the Pi up and running which should magically run the pinball framework without changes.  (I’ll believe that when I see it, but it is why I went with Tk and pygame instead of java.)

All in all, a good couple of weeks.  More coding than I was expecting.  I bought another playfield and that is going to take the place of the Camelot playfield.  Hated to put a ton of time into it, and find out that Camelot stinks.  The Camelot playfield parts are going to be used in the backpack pinball machine.  I also bought a used cabinet so I won’t have to use 2x4s to support a naked playfield on a table.  That will probably be the next big thing that I work on.  More on that in a couple of weeks.

Goonie pinball dude, send me a note some time if you read this.  I couldn’t find a link on your site for your email address, and I wanted to talk.  My email is on this site, so send me a note.  Thanks.

More features added to Python Pinball Framework, 5/12/2014

More additions to the python pinball framework over the last couple weeks.  Here is a list of major additions to the framework:

• Added script files to generate Doxygen documentation.  The Doxygen batch and configuration files are located at Python/PinballFramework/Doxygen.  All of the Python files comments and headers have been updated to support the documentation.
• Added LED chain processing.  A separate thread processes changes to a masked group of LEDs.  That group of LEDs can be changed using LED commands which include turning on/off LEDs, waiting a certain amount of time between LED changes, and repeating a sequence of LED commands.
• Added timer thread processing.  The timer thread looks for timers that are running, and if so, increments the time until the limit is reached.  When the limit is equaled or exceeded, the expired timer bit is set for that timer.
• Added sound chain processing.  This thread is almost identical to the LED chain processing thread except instead of changing the LED state, it can play sounds.  This makes playing a sound every 30 seconds easy, without requiring multiple states to do it.
• Added play/stop background music to standard functions.  Allows a background track to be played continuously.

Next thing that is going to be added is the scoring.  Right now, the only thing that scores is completing all of the targets or completing the three lanes at the top of the playfield.  I’ve just been too lazy to program the rest of the switches to give scores.  Communications also haven’t been finished.  Those are the last two remaining big features that need to be added.

Allentown Pinfest was a couple of weekends ago.  There was a free T-shirt up for grabs for the first person who asked for a free T-shirt.  Well, nobody asked for it, so nobody got it.  That being said, I’ll continue the contest until somebody actually gets the T-shirt.  Rules are same as before except I probably won’t have the extra shirt with me.  If that is the case, I will take your name/address and mail you the shirt.

I spent most of my time at Pinfest playing EM machines.  There are enough machines around in northeast MA, southern NH where I can play a ton of solid state to DMD machines.  The one group of machines that aren’t really represented in the wild are the EMs.  Allentown had a ton of EMs where some were in a good state, while others were a little rougher.  For some reason the week before Allentown, I was remembering an old pinball Gottlieb machine I played as a kid that had a gobble hole in the center of the playfield.  As a kid, it just seemed totally unfair to have a gobble hole where your ball would just be sucked down, and it was gone.  Now, being able to aim the ball a lot better, playing the angles, it is a lot more fun.  I found one EM machine with a gobble hole at Allentown and played it to death.  It was simply a blast.

I was hoping to score a bunch of parts at Allentown, but looking through the flea market didn’t yield anything very exciting.  I did pick up a Bally MPU board for my Dolly so I can put her back into action.  (I’m sick of fixing up a completely corroded board, and the only real way to fix it would be to remove all the chips, clean, and then replace.  Way too much hassle for that game, so I picked up a tested used MPU board which I will toss in at some point.)  I was rolling in my mind of whether I should just gut the machine, add my new driver cards, throw an LCD in the backbox and add some better rules, but seemed like it was a shame to do with a machine that would be working if the MPU was working.  (This doesn’t include the fact that there is a ton of wear on the playfield and the backglass is completely peeled.)

Started working on the layout for the backpack pinball machine.  I started trying to lay it out after doing a couple quick measurements with some of the parts I’ve collected, and low and behold nothing was fitting.  There was a moment of complete doubt if a 12″ x 24″ pinball machine is even possible.  Luckily Joe talked me back from the brink and threw some ideas at me.  With a 12″ wide playfield, there is no space for two inlanes, two outlanes and two flippers.  The lower playfield is going to be very similar to the Space Station playfield.  It only has two outlanes with a very small wire between the slingshot and the flipper to allow cradling the ball.  I laid that out using visual pinball and it should fit with the slingshots and the mini flippers I have from the Shaq Attaq.

The top of the for the pinball backpack playfield certainly doesn’t have enough space for all the stuff that I was planning for up there so I’m now thinking of adding a second level.  That should give me enough space to fit all the rest of the stuff.