Playfield stackup ideas

Woke up this morning, checked the blog and wow, lot’s of new hits.  Seems like somebody posted the blog to another website called Dangerous Prototypes.  That kicked the stats up significantly for the day.  The only error I found in the article is that it stated no code is currently available.  If you go to the Google code repository, you can find about 150 different files with the code in them.  These vary from the C files, to project files, to actual S-Record files that can and have been downloaded onto running hardware.  I posted the schematics in 1000.pdf, but I never posted the Gerbers to actually build the board.  The reason for that is I wanted to get more of the board testing done.  Currently the solenoid driver, input driver, and RS232 interface boards are completely tested.  The LED driver has not been tested, but I’ve used the same design on the EEPROM project so I’m pretty sure it is going to work.  (I actually stole the chips that I was going to use to make Disaster to make the original EEPROM burner so that we could get Mark’s Flash up and running.)  The main microcontroller board definitely has some issues which I know what they are, but now I’m thinking about not using that board at all so it doesn’t matter.  (You need some pullups on the debug bus to get the processor to boot without a debugger attached.  Simple fix, but annoying none the less.)  The last board not tested is the bridge rectifier/power board.  It is populated, but I haven’t bothered using the Variac to test it.  I’m not happy about the amount of current I can get using the TL783, so I’m thinking about converting my design to a boost converter.  The added benefit is I could use a standard PC power supply and step it from 12V to 48V DC or whatever the highest “safe” voltage for CE marking.  (I don’t care about a CE mark, I just like to use their safety standards because I dislike being hit by high voltage electric.)  That would allow me to use the same design internationally.  (Why would somebody from Europe want one of my machines?  Who knows?  I’m currently amazed that I’m as far as I am on this design and the number of people from Europe that check out the blog.)

So I’ve been pondering playfield surfaces.  I have clear coated machines and been really happy with the outcome.  Of course, it takes an average of 4 or 5 months to clear coat a playfield, so that process seems unusable.  The second thing is that it costs me about $20 for the Varathane that I used.  I know that if I started using an automotive finish, it would be cheaper, but I don’t have the work area or equipment to do that.  This got me to thinking about using acrylic to cover the playfield.   Acrylic is supposedly more scratch resistant than Lexan (polycarbonate) which is the most important feature.  Acrylic can also be repolished to get rid of scratches if necessary.  So I’m thinking the playfield sandwich would be a layer of acrylic on the top (1/16 inch),  the graphics/art layer sitting on a 2nd layer of acylic, and then a thick layer of plywood.  Insets would be formed by using a CNC machine to get rid of the plywood.  This would allow LEDs to be mounted below, and would make sure that insets would never sink/rise out of the playfield.  Every restoration I’ve done, the first annoying thing is to reset all the insets properly.  This would make the playfield incredibly fast so I might need to tone down the solenoids  a little bit.  Not a problem since I can configure them on a per solenoid basis.  The cost of a piece of acrylic (24″x48″ is $25.00)  Two sheets plus the plywood plus the art hopefully comes in under my $100 target price for that section of stuff.  It also means I don’t need to pay for insets and gets rid of a lot of the assembly headaches.  I might be able to get rid of the second layer of acrylic, but I’m not sure what I would apply the playfield “translite” on.

P-ROC versus open pinball project solution

A couple people have wondered why I’m not just using the P-ROC solution instead of rolling my own.  It is a very valid question and the design reasoning behind my boards may help some people decide what is best for them.

The original open pinball project design was to use a Xilinx Spartan 3A FPGA for doing all of the solenoid driving, lighting, and digital inputs.  If you jump over to the P-ROC site, they are using the exact same FPGA.  One benefit that they have is that they can use the BGA part.  I can’t solder a BGA part at home, so I would need to send it out which is far too expensive.  My other option would be to use the QFP part which increased the price and reduced the number of outputs significantly.  (The 144 pin part is about $22 each in quantity 1 and it only gives you about 97 I/Os, or $22/97 = .22/I/O pin)  Next I looked at the price of the small crappy processors in quantity.  (Remember, I’m only going to build 10 pinball machines at a time, so price in low quantities is very important.  Using the same chip in multiple locations gets my quantities up significantly)   The design uses 24 solenoid drivers (3 driver boards), and 64 inputs (4 input boards).   (I chose the MC9S08SE8 because it came in a 28 pin dip package which is really easy to dip solder.  It gives you 20 usable I/Os per chip.  So that’s 7 processors/machine or 70 processors at a time.  Because of the price break, it is cheaper to buy 100 processors than 70, so 100 processors is $108.  My price per input is $108/70 processor/16 I/Os = .10/I/O pin.  This is about 1/2 the price of the Xilinx solution).

Last part of the solution is to use 74LV595 to run LED lighting.  These are simple shift registers with a latch bit.  I can run these at a lower voltage so I can get rid of the current limiting resistor on the LEDs.  There are 8 of these per pinball and each chip is $.60 in quantity, so they are .075/output pin.   My guess at my design is that I need 8 of these  per pinball machine.

Some of the functionality that the P-ROC is using is not necessary in my case.  The P-ROC supports a DMD display.  When I looked at the price of a DMD display in low quantities , it was significantly more expensive than using a 22-inch monitor.  Look at the Jersey Jack website.  The reason that they went with an LCD display instead of a DMD display was not because it looked snazzier, but because it costs significantly less, and gives you more functionality.  (By the way, I stated I would use a display before Jersey Jack announced they would use a display, but my reasoning was simply based on price.)  A display/mini computer solution is currently less than $200 in quantity 1.   The only downside is that you need a really good graphic artist to do all of your video clips.  That is going to be a big pain to figure out how to pull all the video stuff together because I have no talent in that area.

By the way, displays are now so cheap, wouldn’t it be cool to embed a touchscreen in the playfield so that it could track the ball as it goes across the playfield?  You could have graphics of jet trails following the ball, objects on the playfield that the pinball needs to hit, etc.  This would be different than pin2k which is using a screen to project objects on the playfield, but still uses physical switches to register hits of these objects.  Wouldn’t it be cool to have a pinball with flames following it?  All of these ideas should be relatively easy to implement with a touchscreen below the playfield.  The only problem is whether the touchscreen can stand up to the abuse.

Firmware for solenoid driver board done

Firmware has been completed and tested for the solenoid driver board.  I added a little bit more functionality to allow inputs that are not used to kick a solenoid to be used as state inputs.  That works swimmingly well.

The solenoids can now be kicked using either the input, or the processor setting the bit to tell the solenoid to kick.  If set by the processor, the solenoid can be configured to automatically clear the bit, or it can keep the input set until the processor tells it to clear.

The solenoid can be configured to use an initial kick of variable length, or it can be configured to give a hard initial kick, and then a PWM to “maintain” the solenoid.  (i.e. good for flippers where you want a hard kick, then a sustain so you don’t burn up your coil.)  It also has a configurable dead timer so a hardware errors can cause a solenoid to kick so frequently that it burns up its coil.

Next up is to make up an LED driver board (simple since it is a single chip and about ten connectors) and test that one.  Of all the boards, that is probably the simplest. )  After that, all that is left is trying to finish the macro language to run the actual machine.  At that point, I should have a complete card set to run a pinball machine with a simple way to create a set of rules for scoring, and moving between modes.

I’m starting to worry that the Raspberry Pi won’t be beefy enough to run what I need.  I started looking into running Java on the pi so that I could run vlcj.  (vlcj are the java binding for the VLC player).  I don’t think the VLC player is currently supported on the raspberry pi using hardware acceleration which seems like a big issue.  It means that my video playback is going to eat up a lot of the CPU time.  It might be that the raspberry isn’t quite ready, and I simply do my prototyping on some mini-ITX platform.  (That was my original plan before acquiring the pi, but I got excited that I might be able come up with a simpler/more elegant solution.)  Now I’m starting to worry that the CPU will be underpowered when using video playback.  I’m assuming that there will be a video playback loop running continuously to tell you what mode you are in, for splashiness, etc.

Firmware for input board completed, testing solenoid driver

It’s been a busy week and a half, but things have been going well.  Bringing up the new processor ended up being more of an issue than expected, but now I understand a lot more about what the debugger is doing.  (The PE Micro debugger sets the frequency of the processor through trimming.  It defaults to a different rate than I was expecting which caused a little bit of concern when the data sheet was not matching with the results I was seeing.)  It is now all working as expected, and things are progressing really quickly.

I made up two of the boards.  I made a single input board, and a single solenoid driver board.  This turned out to be more work that I was expecting.  My soldering ability is rather poor, so I struggled with populating the boards, and then soldering the parts in.  Most of the parts on the boards are two pin connectors, and these things like to fall out when you move them around to try and solder the bottom side.  The labor for making these boards was way too high, so I did a little research and it seems like I need to find somebody with a solder pot that I can use it for a couple of minutes.  That would change the amount of time to build a board from about two hours to about five minutes.  I should have thought about that earlier.

I’m doing most of my testing using python.  Python is currently my “go to” language for scripting.  While I dislike large portions of it, it is really simple to do quick serial port scripts.  If you grab the newest version of the code base, it now includes a python script to test the input board (one of the tests simply polls the board and prints the information continuously), while the other test initializes a chain of boards.  That stuff is really starting to work nicely, and there is a python interface file which makes scripting the commands quite simple.  I will probably break this down into a separate script file that can be used to do all the heavy lifting.  That stuff should translate cleanly to the end product.

Pictures, everybody likes pictures.   Here is a picture of the three boards (the RS232 board is the surface mount, not through hole board, so that would look a little different if you built up the project from the original gerbers I threw up).  I also feel that the pictures show that this stuff is real, and it is progressing.  I don’t know how long the project has been going on, but it is nice to see Disaster is finally moving along more quickly.

Here is the current test setup.  This shows the boards chained together with the LED simulating a solenoid.  It is attached a computer using a standard RS232 serial port.  It is powered using a USB port from the computer (less stuff to drag around).  There is a jumper at the end of the serial chain that wraps the data back to the receiver of the computer.

Up next is to finish testing the solenoid driver code.  The input board currently does edge detection (either rising or falling), and supports a simple reading of the state of the input bits and is completely tested.  I’ve communicated with the solenoid board, but I haven’t verified all the driving options.  That should happen next week.  I also need to build up one of the LED driver boards and start testing that one.

First cut of firmware for Disaster including both input boards and solenoid drivers

It’s time to start the ball rolling.  The Disaster project has been completely idle for the past couple of months.  I’m starting to run out of pinball machines to fix up, so it seems like I have more time to put back into Disaster.    Here’s the current status of the design.

As you may remember, the design is modular and split into three different types of cards: solenoid drivers, input boards, and LED driver boards.  The LED driver boards use the SPI interface with a latch signal.  No processor and all the code is on the main controller, so essentially they are done.

The solenoid driver boards drive eight solenoids, and can use the eight inputs on the board to kick the solenoids.  This gives them very little latency since it is all on the same board.  They can be configured to report back to the main controller when a solenoid has been kicked.  This allows the main controller to poll the solenoid boards at its leisure, and add up the score.  The main controller can also send commands to get the solenoids to kick.  This allows auto re-injection for multiball, let’s the main controller hit the flippers for ball search, and all sorts of other cool features.  (It also increases testability since a test can be run to kick all the solenoids.)  Each solenoid can be configured so when it kicks it clears itself (one-shot style), or continues to be held with reduced power using a PWM.  The control bits sent from the main controller can be persistent, or can be automatically cleared to reduce the amount of communication needed.  The input switches use a software filter to insure that  “noise” doesn’t cause inadvertent triggers of the solenoid.  That firmware is complete.

Last card is the input card.  It has sixteen digital inputs that can be read from the main controller.  This board also uses software filtering.  That firmware is complete.

The main controller sends a command to discover the boards.  This allows the main controller to verify the cards are correctly attached and reduces the chance that something is misconfigured.  This is also complete, and the design can support up to 16 of each type of these boards.

I’ve decided to completely drop the main controller and implement it on the Raspberry Pi.  Since I last visited the Pi, it turns out that many of the functions that I needed can be supported by the base hardware.  This would reduce cost even further.  My design requires an RS232 interface and a SPI  interface.  Both of these are provided on the external interface pins.  The last thing that I need is a 3-axis accelerometer.  The Raspberry Pi also brings out an i2c interface, so I should be able to make a small board for the accelerometer, and to switch between 3.3V logic and 5V logic.

The only thing that I worry about is the real-time features that I need, but since my design moves most real-time aspects to the embedded controllers on the input card/solenoid driver cards, that should not be an issue.  It should also reduce my coding cycle because I don’t need to write one more large piece of code, and move the information from the Pi to the main controller.

What is the next step?

1. Solder the boards that I have in my backpack
2. Test the firmware that I’ve already written.  This can be done very simply using a serial port from any PC.
3. Start writing the specification for the pinball programming language (PPL).  This past weekend, I sketched out the required features, but I’m sure that I’ve missed some stuff.  I need to write up a couple of examples using the PPL and see if it holds together.  Nothing shows weaknesses in a language better than trying to use it to implement things.  My next entry will probably be on that.

That’s it for this week.  As soon as I get the beginning of the PPL down, I’ll be hoping that somebody will comment on it.  It is meant to be used by people who are not “programmers” but are enthusiasts.  I think I have some good ideas, but it needs to make sense to other people, not just me.

Schematic 100% complete and sent to board house

The schematic is 100% complete at this point.  The only changes were to add part numbers into the schematic so a BOM (bill of materials) could be generated.  I then took the BOM and created 1008.mod.ods.  It is an Open Office calc spreadsheet (open office excel equivalent) which uses the correct prices for the quantities needed for this project.  (My standard tool uses quantity 100 for each part, but this project uses far less).  If you find a group of friends that need a couple display completely swapped out, it would be much cheaper than this.  The most expensive part is the LCDs which the project requires 28 and we are playing $1.57 each, but if you could buy 100, they would be down to $1.25 each.

The BOM cost ends up being $142.58.  The only thing that isn’t in that cost is shipping from mouser which is around $5 to $7.  I also included solder paste to make the boards in that BOM cost because I assumed that somebody making this would not have that lying around.  I use Chip Quik which seems to work out nicely.  You could hand solder this but hand soldering the 600 pins of the NFETs would be really really painful.  That in itself is worth the $17 for the solder paste.

To get the PCB price that I quoted, use ITeadStudio and choose a 5×20 cm set of boards.  It is under open PCB->PCB prototyping category.  Choose larger than 10×10 cm and when you are choosing the options, 5×20 cm is an additional cost of $7.  The cheapest shipping used to take about 4 weeks, but they just switched from Hong Kong post, so I’m not sure how long this is going to take.

This is equivalent of the pinscore replacement system.  It includes a potentiometer for dimming the displays.  If you don’t need to buy the setup materials, i.e. the solder paste, the project should come in around $120.  The pinscore displays go for $200, so truth be told, this is not a whole lot of savings.  This is also why I won’t be manufacturing these in any quantity.  Pinscore has the benefit of buying parts in higher quantities that individual hobbyists can’t necessarily match.

Next post on this topic won’t be until we receive the boards.  I think that I need to go back to working on Disaster.

First version of Williams display firmware completed

Worked on the firmware for the display board this past weekend while watching football.  Nice part was that it went really well, and the first cut of it is completed.  It has all of the functionality including an opening message when the the display controller starts.

The display controller works as follows:

First step is the bootloader which verifies the integrity of the application firmware.  While not strictly needed on this project, I work on a lot of safety critical firmware and verifying the code integrity is required in those situations.  (The code was used in one project to identify a bug in a Microchip processor that was not documented in the errata, but all the FAEs know about it.  This is why I never use Microchip processors.  If your chips have known bugs, put it in the errata!!).

Next step is to test if the processor should stay in the bootloader waiting for a code update.  To force the code to the bootloader, boot the processor with the i2c SCL line low.  This should never happen in an operational set of displays because the i2c bus requires pullups.  Code updates through the bootloader can be done using a serial port.  (Added a connector to the card to support this function)  The bootloader also lights a new LED on the display card to indicate it is in boot.

If not staying in the bootloader, a test message is displayed on player scores 1-3, and the firmware version number is displayed on player score 4.  The credits/match both display “88”. This message is displayed for 5 seconds.

Now the processor starts looking for valid strobe signals from the MPU.  If a strobe is active for 200us and the BCD inputs are stable during that time, the BCD inputs are recorded.  If any inputs change, the timer is restarted.  The BCD digits are compared with what is currently being displayed, and if it is different a bit is marked to update that display digit.  This processing occurs in the digital task.  After the update bit is marked, the task waits for the strobe signal to be disabled.

At the same time, the i2c task looks to see if any displays need to be updated.  If so, it clears the bit, and sends an i2c msg to update the pair of digits.  The update pairs are abbacc when looking at the player scores.  (If a player has 123456 for a score, and gets 30 more points, 86 is written to the last two digits since the processor always updates in pairs.  The pairs are a little strange because the display board only has four digits, and there is an unused digit between them.  In the above lettering, the display board only has bb and cc digits.)

That is all the code does.  Not terribly exciting.  The 200us filter should make sure that the board never acts on glitches.

The biggest thing was putting the standard code in the repository.  I wrote the code about 15 years ago, and it used to live on a server running in my basement.  My ISP told me they needed to start charging me for a static IP address, so I turned off the server.  I’ve been meaning to put it back up on the web, so this has been a good kick to make me do that.

I threw up three different projects.  Hexmerge is the utility that merges the bootloader with the application code, and adds the CRC to the application so that the application integrity can be insured.  (It also spits out the CRC of the bootloader, application, and whole image which is nice to make sure that the code is reproducible)  The bootloader lives in the HCS miniboot directory.  (This is the standard bootloader I wrote for Motorola/Freescale years ago, and was originally coded for a Motorola 68HC11.  I don’t know if you can even buy those processors anymore.)  The last piece is the standard library which I wrote originally in 1996.  I’ve ported it to three or four different types of processors/DSPs, and basically it is a template for the minimum functionality required of an embedded system and other utilities.

All the project is waiting for is Mark to finish approving the schematics, and off they go to China.  Mark did verify the spacing of the mounting holes and the LCD digits so that part is completed.  Each player score needs to move the bottom mounting standoffs since these boards are smaller than the originals.  The master display needs to move all of it’s mounting standoffs since it is much, much smaller than the original.