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.

Display Controller Populated

The first display controller is populated by Mark this weekend.  This is the board that will replace the display controller board.  As you can see, it only has four digits because the other two digits weren’t used.  This is also the only display that will have a micro-controller.  All the other displays are simple i2c slave devices with three 16 bit registers each.  The jumpers for configuring it as the master display or a player scoring display are on the right side.  The connectors on the right are for powering the slave displays.

Here is a picture of the back of the of the board.  The voltage regulator/potentiometer allows the brightness of the LEDs to be changed on a system wide basis.  The processor is the largest chip on the right, and the two small chips are muxes since the processors doesn’t have enough I/O pins.  Only two of the i2c registers are populated since there are only four digits.

We were probably going to bring up this board on pinball night, but Mark now has the flu, so he is probably out for the week.  It should be relatively easy to bring up this card and test it over the next few weeks.  As soon as this card is up and running, we will build the other four player score cards (which use the same PCB) and we should be done with this project.  I’m thinking of making a little wiring harness to make the testing a little bit easier.  (Basically a connector with a bunch of pullups/pulldowns so I can simulate the pinball machine sending two characters at a time to this card.  I originally thought of doing it using the PCs parallel port, but since there aren’t enough data pins (only about 10 easily accessible), it seems easier to simply make a plug header and move the jumpers by hand.

I’ll probably end up with another entry this week on finishing the initial layout for the Disaster LCD.  It is currently streaming video while displaying four players scores.  More on that when I finish it up and get to a good stopping place to put it in the repository.  I’ve also promised myself that I will throw up the Disaster individual board schematics for the three cards that I have fully tested.

It is rather humorous to read comments about how the blog is centered around restoring pinball machines.  I imagine the blog is broken into two different sections:  restoration, and then Disaster which is hopefully going to be a pinball machine completely from scratch.  While the boards for Disaster are not the most whizz bang designs using the fastest processors, each of the processors is more powerful than the processors that are running pinball machines through the late ’90s.

Display boards received

Display Boards:

Display driver boards came in yesterday.  Here is a picture of two of the five showing both sides.  The Gerbers were sent to ITeadStudio on 12/5/2013, so it was about a one month turn.  That speed was choosing the slowest/cheapest shipping method.  Unfortunately, we haven’t ordered the chips yet.  That order will go in tomorrow and will end up taking another week to get the chips.  I’ve identified slightly less expensive displays which might bring the price of the build down slightly.  I’m looking forward to getting this built up, and then doing the testing on the firmware.  I should have gotten ITeadStudio to do the cutouts for the connectors, but originally I thought I could toss another project on the extra space, but there just wasn’t enough room.

Distaster info:  Lately I’ve started the Java framework for running the pinball controller.  I tossed CodeDownload into the repository (actually that will happen tomorrow) so the solenoid driver and input driver firmware can be updated without a debugger.  It is a windows application, but could easily be modified to work on a Linux box by changing some small things with serial port naming conventions.

I’m planning on making a parallel port bit banged fake SPI interface so that I can test the LED driver.  That should be very simple and should give me enough pieces to make the first “fake” pinball machine.  Basically a pinball machine with my boards giving the inputs states to a PC, and the PC showing how the pinball machine would react.  I’ll attach LEDs to the solenoid drivers to show when the solenoids are on.  That is probably going to take a good bit of coding to make that happen but it is a good next step.

I finished my design for a boost converter to try and get 50V from a 12V source, so I will be trying to “bread-board” that and see how it works.  That was an extra piece of work that I wasn’t expecting, so I might put that off for a little bit.  It seems like it is a much cleaner solution than my original solution of bridge rectifier to buck converter.

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.

Layout completed for display project

Mark and I have been working hard on finishing up the display project layout.

The list of changes include the following:  move the silkscreen positions so populating the board is easier, finished adding the power connectors in the current version, moved all of the connectors to the back because the Williams connectors only have contacts on one side, connectors for the i2c bus were changed to right angle connectors to reduce height  (straight connectors were too close to the backglass), added extra clearance for mounting hardware, added silkscreen for connector cutouts, and added silkscreen/copper for revision of the board/assembly.

If you need to grab the newest version of the board and you already followed the directions in the last post on how to grab the board, you simply right click on the directory that you downloaded before and choose SVN Update.  That will grab the latest and the greatest.

The goal is to send this board out to be fabricated this week.  I will also try to update the parts in the board so that a BOM (bill of materials) can be generated in Kicad.  Right now, all the information is in my notebook, but hasn’t been transferred to the parts.  This will allow me to get a final cost on the board.  If you have any questions, feel free to send me an email.

Initial layout for display board

!!! Warning !!!:  The current version of the display driver board is untested.  While I think they will work, Mark and I will be reviewing them this week, and I would not try to build this project until we build the first version.  I’m hoping to send the boards out at the end of this week.   At that time, I should have a good idea of the final cost.  My estimates at this point are under $120 for a full replacement (4 player scores, and the master display) of a Williams system 3-6 display system.

The four player scores, and the master display all use the same board.  Since ordering 5×20 cm boards from ITeadStudio gives you five boards in an order this is perfect.  The player score boards do not populate the microprocessor, or the muxes.  The master display populates these components, but doesn’t populate one of the i2c register chips since the board has four instead of six displays on it.  This keeps the cost to a minimum, and only requires a little bit more programming in the microprocessor.

The code will constantly poll the strobe signals.  Since there are a lot of strobes (more than can be simply attached to pins in the processor), the strobes are muxed into two different groups.  When polling the strobe signals, it first looks at one group of strobes, then another group of strobes.  If it finds that a strobe signal is active, it polls that bank sixteen more times to makes sure that it isn’t a glitch.  At that point, it reads the two BCD nibbles.  We measured a strobe width of about 1 ms on Williams yellow PROMs.  The reading multiple times gives us a simple digital filter and reduces the need of filtering on these input pins.

The player displays use sixteen bit i2c registers for driving the LCDs.  Each sixteen bit register controls two digits on the display.  That means there are three register chips on the player scores, while only two on the master display since there are only credits and ball count.  That gives a total of fourteen register chips for a whole set of boards.  The register chip addresses are chosen using jumpers on each of the boards.  There is also a jumper to pick if it is a player score display or the master display.

Once a new BCD digit is read, it compares it to the current value that it is displaying.   If there is a change, the processor sends the new value across the i2c bus and updates the correct display.  The processor does the conversion from BCD to the register outputs.

The only other part of the design is using a low dropout voltage regulator to control the brightness of the displays.  This is done once for all of the displays with the master display board generating the voltage for all the cards.

The open pinball project is in a subversion repository in Google code.  The easiest way to grab it is to grab a copy of tortoiseSVN (a free windows GUI client for subversion, there are also versions for linux/Mac)  Install that program, and then create a folder where you want to have the open pinball project files stored.   Right click on the folder, choose SVN Checkout… from the menu.  This will bring up a window, and the address of the repository is https://open-pinball-project.googlecode.com/svn/trunk.  The display driver files are under the Kicad/1008-DispDrv directory.  It should have everything that you need.

Mark and I will review the schematic this week and hopefully send it out to get built.  This should be a very good solution if you need to replace all your Williams display boards.