11/19/2014 – So the Teardown Begins

I’ve put an end date on Sharp Shooter 2 (which I’m going to be renaming Sharpe Shooter 3) at July 10th, 2015.  At that point, it must be a playable machine with at least some set of rules implemented.  I can hear everybody yelling…that is so far in the future.  Let’s list off the myriad of things that the machine currently doesn’t have:

  1. Playfield art:  The playfield is currently trashed.  Much of the art has been worn off.  Here’s a quick link to a picture of the current state of the playfield.  Nice wear marks, but since I’m updating the art, it doesn’t matter.
  2. New plastics art:  The new playfield is hopefully going to have a new style of art.  That means the plastics are going to need to be replaced with new art to match the playfield.
  3. Cabinet:  I have a Gladiators cabinet which is in excellent shape.  It needs to be sanded down, repainted, and artwork applied to make it match the theme.  The cabinet currently doesn’t have any way to mount the playfield, so that will need to be fixed.  It also doesn’t have any way to attach the legs, but that one is at least easy.  Oh yeah, the coin door I have doesn’t fit the opening, so that will need to be jury rigged.
  4. Backbox:  I don’t have any backbox whatsoever, so that needs to be created from scratch.  Speakers need to be mounted into it.  The LCD needs to be mounted.  Some sort of backglass art needs to be created.  The backglass will be lit with a fluorescent tube, with a stretch goal of of controlling some lights back there to highlight the backglass.
  5. Computer to run rules:  I could jury rig up a PC, or a stretch goal will be to get the Raspberry Pi running the rules.
  6. Rules for the pinball machine:  Right now I have rules sketched out on paper for 11 different modes.   I would like to have at least 5 or 6 of those modes completed.
  7. Pinball framework completed:  Enough of the pinball framework completed to support the game.  I was originally going to not write any pinball code without using GenPyCode to create the actual Python.  I’m now going to pull back from that, and let GenPyCode create the shell of the files and the chains, and then fill out rules by directly writing Python.  That would mean that the first version of the GenPyCode is nearing completion.

That’s a lot of stuff to do in 9 months.  That being said, I need to work on the long lead items first.  The one on the top of that list is updating the playfield art.  I was originally going to wait until I had finished wiring all the insert lights before tearing down the top of the playfield (more exciting for doing a video), but that really isn’t necessary.

To redo the playfield art, the top of the playfield needs to be completely stripped which was started earlier this week.  Next, the current playfield art needs to be scanned to find the exact positions of all the feature lights, kickout holes, and areas that are covered by the playfield plastics.  I’m probably going to do both a low resolution scan, and a high resolution scan.  Since I’m not trying to fix the art, a low resolution scan should be sufficient to locate everything.  I need to get the scan completed this weekend.  With Thanksgiving coming up, I may have some free time to manipulate graphics images during the break when I won’t have access to the machine.  A perfect time to stitch the pictures together and form a schematic of the playfield.

I’m planning on following this guide to doing a full playfield overlay.  I’m not planning on saving any of the playfield artwork.  It is interesting that during the removal of parts on the top of the playfield, I noticed a lot of the art is hidden under plastics.  I’m going to assume this is probably because SS2 was a lower cost alternative to Sharp Shooter which was a wide body machine.  (SS2 is a narrow body machine).

I typed the previous message on starting Tuesday, and the playfield was completely cleared by Saturday night.  I spent a couple of hours today cleaning up the playfield and taking the scans.  I took all the scans at 600 DPI which is plenty good quality for locating all the features, and stitching together the current trashed art.

I started trying to stitch the art together at the higher resolution, and quickly found my computer doesn’t have enough RAM.   GIMP wants to create a 3GB image file to work with the images, and since I only have 4GB of RAM, it the computer spends all of its time swapping memory to the hard drive.  I’ll drop the resolution down and try that.

I found more problems with the playfield than I expected.  It has been through a lot of tough times.  A good number of posts are cracked or destroyed.  There was a liberal use of toothpicks to keep posts secure.  Many of the screws have been replaced with bigger screws to try and hold onto the playfield better.  There is going to be a good amount of work to bring those aspects of the playfield back.

10/28/2014, hp 4600 scanjet on Windows 8, “I’m not quite dead”

Pinball is made up of people trying to bring machines that, by all rights, have outlived their planned longevity, back to life.  I’m doubting that people who built the first solid state machines would expect their machines to still be running after 40 years, and people still finding parts to keep them running, or coming up with creative ideas to use newer parts to replace the parts that can’t be found anymore.

Here is a story about a scanner that is a fine scanner, but the last operating system that supported it has reached its end of life.  That being said, this post is dedicated to bringing that scanner back to life, and having it fully functional.

In 2003, HP made a scanner called the HP 4600 scanjet, that wasn’t particularly exciting except for the fact that it was a “see-through flatbed scanner”  While this has no value in normal applications such as scanning a single sheet of paper, if you are a pinball geek (ummm, aficionado), it is gold.  You can use the HP 4600 scanner to scan a whole playfield in pieces, and then put those images together using a photo editor.  Since it is a see through scanner, it can easily be positioned so the images overlap, and the images aren’t angled.  It would be very difficult to place a pinball playfield on a normal flatbed scanner and position each scan accurately.

Two weeks ago, I knew about the HP 4600 scanner and imagined I would get something similar when necessary.  I had tried to piece multiple digital photos together to form a large high resolution image.  Each digital image from a camera has spherical aberrations which are caused by the lens focusing the image onto the CCD or CMOS image chip.  The only real way to take large images is through a flatbed scanner that doesn’t have spherical aberrations.  For some reason, Joe feels he wants to buy me a scanner.  Fantastic!  One less thing I need to think about.  The only problem is it is the HP 4600 scanjet where the last supported driver was written for Vista.  (Vista?  That was the last failed Microsoft operating system that I am proud to say that I have never installed, supported, or used.  I completely avoided that cluster.)  HP 4600 scanjets are cheap right now because they are so old.  I think that Joe got it off ebay for about $40 plus shipping.  (I told him I wanted it to be less than $60, but he never responded with how much he paid…actually he just sent me that it was $35 including shipping).

I started my research and it was pretty clear it wouldn’t work on Windows 8.  I did more research, and found a Linux driver, but it simply replayed recorded USB commands.  That means, the resolution couldn’t be changed, the output file format couldn’t be changed, etc.  That was not an acceptable solution.  I am running a 64 bit XP machine, but I could not get the scanner to work with it, and what happens when that 10 year old computer stops working?  I needed to get the scanner working on Windows 8 (or 8.1).

Here are the detailed steps on getting this to happen.  This will hopefully replace some of the bad information out on the internet about how to get these scanners to work.  All the pieces of software are free/open source except for the XP license.  If you need an XP license, go to any electronics recycling and grab an XP professional sticker off any of the dead PCs.  Always remove the XP license sticker before recycling a PC (and smash the hard drive if you don’t remove it).  You never know when you need it (the sticker, not the smashed hard drive of course).


 Download software

  1. Download Virtual Box platform package and the Oracle VM Virtual Box Extension Pack.  The current link is here.  The current version at the time of this writing is 4.3.18.  Note:  You need to download both the normal virtual box installer, and the extension pack.  The extension pack is necessary to talk directly to the USB port and the HP 4600 scanner.
  2. Acquire an XP installation disk and license.  I used Windows XP Professional 32 bit installation.  I know the 32 bit XP works.  Anything else and you are on your own.  If you have a license, and don’t have an install disk (i.e. removed an XP sticker from one of your PCs before you recycled it), you can try and find yourself a version of Tiny XP rev 11.  It is a version of the XP install disk iso with a lot of the fluff removed from it.  It is probably only legal to use Tiny XP if you have a valid license.   Beware if you download the iso from an unknown source since it may contain malware, viruses, etc.
  3. Download the HP 4600 scanjet drivers/software.  One is listed under Drivers as HP Photo and Imaging Software, and the second one is listed under Update as Windows color table driver update.  Here is the current link.

Install Virtual Box/Create Machine

  1. Install VirtualBox.  Double click on the Virtual Box installer to install it.  Choose all the defaults.
  2. Run the Application.  Run Oracle VM VirtualBox.
  3. Create a virtual machine.  Choose Machine->New to create a new virtual machine.
  4. Fill out virtual machine parameters.  Name:  XPPro, Type:  Microsoft Windows, Version:  Windows XP (32 bit), press the Next button.
  5. Set up processor RAM.  Set the RAM to 512 MB, press Next.
  6. Create virtual hard drive.  Select Create a virtual hard drive now, press Create
  7. Select hard drive style.  Select VDI (VirtualBox Disk Image), press Next
  8. More virtual hard drive dynamic to save real hard drive space.  Select Dynamically allocated, press Next
  9. Choose hard drive size.  The default size is 10.00 GB which is good, press Create.  A new machine name XPPro, in the Powered Off state should show up in the VirtualBox Manager window.
  10. Configure virtual machine.  Highlight the XPPro machine, and choose Machine->Settings
  11. Disable booting from the virtual floppy drive.  In the System group, Motherboard Tab, Boot Order, uncheck the floppy drive so it doesn’t try to boot from floppy.  (The CD/DVD and Hard Disk should still be checked).
  12. Put XP installation disk/iso in virtual/real drive.  In the Storage group, highlight the Empty CD/DVD in the Storage Tree box, and in Attributes press the disk icon to choose the disk which is installed in the CD/DVD drive.  Either choose the physical drive that contains the XP installation disk, or the iso image of an installation disk.  The icon in storage tree should now list something other than Empty.  Press the OK button.

INSTALL XP/SOFTWARE

  1. Start the virtual XP machine and install XP.  With XPPro machine highlighted, choose Machine->Start.  Choose Unattended Install (2).  Install Full XP (1).  Enter to install, Enter to install NTFS on partition.  Everything else should complete automatically.  If normal installation, it will end up restarting a good number of times.
  2. Take out XP installation CD/iso, and install VirtualBox guest additions CD.  In the new XP virtual machine, choose Devices->CD/DVD Devices->Remove disk from virtual drive to uninstall the XP installation disk.  Choose Devices->Insert Guest Additions CD image…
  3. Install the guest additions.  On the XP machine, press Start->All Programs->Accessories->Windows Explorer.  Double click to run  D:\VBoxWindowsAdditions-x86.exe.  Use all of the defaults.  Press Finish to reboot the virtual XP computer.
  4. Remove the guest additions from the virtual drive.  In the XP virtual machine window, choose Devices->CD/DVD Devices->Remove disk from virtual drive.
  5. Shutdown the machine by choosing Start->Turn Off Computer, Turn Off.
  6. Install virtual box extensions (downloaded during the first steps).  Double click on the file called Oracle_VM_VirtualBox_Extension_Pack-4.3.18-96516.vbox-extpack that was downloaded earlier.
  7. Restart the XPPro virtual PC by highlighting it in the VirtualBox Manager, and choosing Machine->Start.
  8. Create a share folder.  In  XP virtual machine window, choose Devices->Shared Folders Settings.  Press the ‘+’ to add a shared folder, browse to the folder to share, and select the Make Permanent checkbox.  Press the OK button to create the share.  Press the OK button to close the window.
  9. Copy the two driver files that were downloaded from HP to the shared folder on the host machine (not the virtual XP machine).  The driver files/application files were named col6904mu1.exe, and col5691.exe.

Install Software

  1. Map shared network drive.  On the XP machine, press Start->All Programs->Accessories->Windows Explorer.  In explorer select Tools->Map Network Drive.  Set the Folder to \\VBOXSVR\share.  Insure the reconnect at logon is checked, and press the Finish button.  The explorer window should now show the two driver/application files.
  2. Install the HP tools by double clicking on the col6904mu1.exe file.  It will automatically unzip and run the installation.    Choose all the defaults.
  3. Plug the scanner power in, and plug in the USB port to the host computer.
  4. Create a USB filter.  In the VirtualBox Manager, select the XPPro machine and choose Machine->Settings, and choose the USB category.  Press the ‘+’ on the right hand side, and select the hp scanjet.  Double click the newly created USB filter, and clear out entries for Revision, Manufacturer, Product, and Serial No.  Press OK to save the settings.
  5. Rerun USB detection.  Unplug the USB of the scanjet and replug it in.  The virtual XP box should now be controlling the scanner.
  6. Install newer HP scanjet drivers.  Double click on the newer driver file col5691.exe which should also be located in that shared directory.  If the virtual XP machine is the sole controller of the hp 4600 scanjet, the new version of the driver will be installed, and in the VirtualBox Manager Devices->USB Devices, hp scanjet should show a check mark indicating it is the sole owner.

Ready for First Scan

  1.  Open the application and choose source, set destination folder.  Double click on the HP Photo & Imaging program that is on the Virtual XP desktop.  On the left side, choose Z:\, so the scan will be stored on the shared drive.  Press the Scan button at the top left.  Pick the hp scanjet 4600 series TWAIN 1.0  (32-32) as the source.
  2. Increase resolution to 600 DPI.  In the hp scanning window that just opened up, expand the Resolution category and choose 600.  (Yes, I know that the choice box looks like crap.)
  3. Start the scan.  Press the Accept button and the scan should occur.
  4. The scan will output a tif format picture.

For information on using the scanner outputs/resolutions, and general great discussions on restoring backglasses and playfields check out Ed Cheung’s site on his Space Shuttle Playfield restoration.  The page on restoring a mirrored Space Shuttle backglass is also fantastic (one  of the first links on the page).

Pinball magic talks about how to install a mylar overlay and clear coat it.

10/11/2014 – Bulb wars are over

So in the last post, I had thought that I messed up the silkscreen on the incandescent driver boards.  Turns out that I had accidentally hooked the voltages to the test fixture incorrectly.  The silkscreen on the card is correct.  The incandescent driver board contains two spade terminals for VBulb (voltage for the bulb).  There are two terminals so the bulb voltage can be daisy chained between the cards.  Since I hooked the voltage up incorrectly, the LED test fixture was backwards and I also had to fix that.

So the light output from incandescent bulbs was anemic at 5V.  I thought this was due to the fact that I was running them at 5VDC vs 6.3VAC.  Of course I couldn’t do any side by side comparisons, so it was mostly me remembering how bright the bulbs should look.

This weekend, I built up a test fixture to do some side by side testing of both LED bulbs and incandescent bulbs.  The test fixture involves a DC-DC converter with a potentiometer so I can get voltages from 2VDC to around 11.8VDC.  I took one of the old bulb boards from Shaq Attaq, and hooked that up to the voltage output.  Next I added a .1 ohm current sense resistor so that I could accurately measure the current.

First thing that I noticed was that the incandescent bulbs at 5V were anemic.  Strangely enough, the same bulbs at 6.3V were also anemic.  It seems that in my minds eye, incandescent bulbs are much brighter than they are in reality.  Since the load of the bulb is reactive, the equivalent in DC is 6.3VAC/sqrt(2) = 4.54VDC.  Strangely, 5vDC should be a little bit brighter than 6.3 VAC.  I then applied 12V to the incandescent bulbs, and they looked nice.  They probably wouldn’t last very long at that voltage.

Next I moved onto doing all the measurements.  Dave was kind enough to lend me a bunch of different LED bulbs.  Seems like most of them are Ablaze bulbs.  Here is a link to the document:  BulbMeasurements.

LEDs have a very steep current to light output curve, then it flattens  and additional current is converted into heat, not light.   LED bulbs have a current limiting resistor inside of them.   The value of that resistor determines the location on the curve.  After doing the measurements and looking at the light output, I’m certain that the LED bulbs will look good being powered at 5VDC.

Next up will be adding wiring for all the feature lights on SS2.

9/27/2014 – Incandescent driver board tested

Here is a picture of the populated incandescent driver card:

IncandDrvPop_sm

The picture shows the MOSFETs in the correct orientation, and all the connectors placed the correct way.    The four and two pin connector on the right side should be a six pin connector, but I made due with what I had for the first card.  Same with the two connectors on the top right.

Spent a couple hours today and tested out the incandescent driver board.  To test the board, I built another board to use a computer’s parallel port to drive the SPI signals, and an old PC power supply to prove the 12V and 5V.  The picture below shows the parallel port to incandescent interface on the top right corner, and the incandescent driver tester on the bottom.  I haven’t had a chance to cut the two boards apart yet.

IncandTestBrdVoltCvt_sm

The converter board at the top has spade terminals for the 12V, 5V and ground from the power supply.  It also has the six pin connector that gets connect to the incandescent driver.  I cut a DB25 cable in half and used D0-D2 from the parallel printer port drive MOSI, SCLK, and SS*.

The test board is at the bottom of the picture.  Each pin of the four two pin connectors drives an incandescent lamp.  The incandescent driver board can be used as either a high side switch or a low side switch.  All of the playfields I have looked at in depth use a wire braid to return the GI lighting current back to the power supply.  That means that you need to provide a high side switch (i.e. cut switch the voltage on and off instead of switching the connection to ground on an off).  Since it is a high side switch, and I’m using an N-channel FET, to turn the FET on and off, a voltage is needed which is VLED + Vthreshold for the FET.  The threshold voltage for the BS-170 is 3.0V max, and most pinballs use 6.3VDC, so about 10V is needed to turn on the FET.  The power supplies provide 12V, so that should work perfectly.

So trying to lay out the board quickly, I messed up one signal.  The G* signal on the STPIC6D595 needs to be grounded instead of pulled up.  That’s a simple cut of a trace and add a wire on the back of the board.  The mistake is disappointing, but it is easy to fix.

Since the incandescent driver boards are being used as high side switches, the spade terminals on the card are connected to VLED.  I bought a couple of buck converters to change the voltage from 12V to 6 or 7V to drive the LEDs.  That should make them look a lot less anemic.  Each pin of the two pin connectors go to a light bulb and provide the power to turn it on and off.

Next step is moving towards the Pi.  My laptop doesn’t have a real parallel port, so now I can’t easily run feature lights and the serial interface off the laptop, so it is time to start getting stuff working on the Pi.  That will reduce the amount of voltage conversions that I need to do.  I will end up using a voltage converter chip to move the 3.3V Pi signals to 5V for the old driver cards (won’t be necessary with the next generation of cards), and then the conversion to convert the SPI bus signals to 5V.  I will put down a second chip to convert the 5V from the Tx output from the input/solenoid driver boards back down to 3.3V.

I have to build a bunch of boards for Cactus Jack, but I’m not sure how he is going to drive them.  That might require a few emails to figure out how he wants to drive that stuff.

Oh yeah, here is  a link to the video of the incandescent driver running the test fixture.  A 200ms sleep was tossed in so that it didn’t blink too rapidly to film.  Running at full speed, the flashing was so fast my eyes couldn’t detect it.

9/20/2014 – Incandescent Driver boards

Boards showed up on Friday. The boards contain the next generation of driver cards and four copies of the incandescent driver boards. I got a chance to build up one of the cards and immediately noticed that I put all the MOSFETs in backwards.  Grrrrr.  I originally planned on using one MOSFET, but opted for one that could sink more current instead.  The new one is in the same package, but it is pinned out in reverse.  I’m glad that I picked the new packaged because the current is higher than I expected.

The first built board is always a learning experience. You learn which components to solder first, and where the gotchas are. I rushed the board a little bit too much, and didn’t leave enough space between boards. Because of the tightness between the boards, I needed to use the Dremel tool to cut between the boards instead of the tile saw. When I use the Dremel, I can’t set up a fence to get the cuts perfectly straight. I’m disappointed by that because I feel I could have spent a little bit more time, and made sure there was enough space so I could have used the tile saw.

When I did the initial soldering of the FETs on the card, I used too much solder. I ended up needing to wick off some of the extra solder, but corrected the mistake on the second group of four MOSFETs.  Luckily, since I put all of the FETs in backwards, this was now simply my practice board.  The second board that I soldered went much better and looks very clean.

I measured the current through multiple 44 and 47 bulbs.  These were old bulbs that were already installed in the machine.  At 5V, they measured anything from 200 mA to 350 mA.  That gives them a range of  resistances from 14 to 25 Ohms.  The new FETs (BS170) can sink 500 mA continuously so that should be plenty of headroom.

I would really like to switch over to LED bulbs, but I can’t find any succinct information about the light output at 5V.  All of the LED bulbs have internal current limiting resistors, but without that info, and the spec on the LED itself, it is tough to say what it will look like.  An LED has a steep voltage to light output curve at low voltages, then flattens out at higher voltages.  The current limiting resistor determines the location on that graph, and it may or may not be a huge difference in the amount of light.  (At higher voltages/currents, most of the extra current is converted to excess heat.)   I’m going to ask some people around here if I can borrow a bulb or two for a week to see if I can make some measurements.

The big plans for this weekend are to try and get the incandescent driver board actually driving lights.  I’m planning on using a computer parallel port to test the boards.  I just finished the voltage converter board.  A printer parallel port outputs 3.3V but must be converted to 5V since the STPIC driver needs 4.25V for a logic high. The output of the printer parallel port will drive the gate of N channel MOSFET which will convert the 3.3V level to 5V. The output will be inverted since a high level on the parallel port will turn on the MOSFET which will ground the pullup to 5V.

I will probably end up doing a simple python script to bit bang the SPI interface using the parallel port.  That gives me a simple way to test the boards after I solder them to make sure they are working properly.

Ended up building a simple test fixture for testing the boards.  It contains 8 LEDs to test the 8 drivers on the incandescent driver board.  Take that, add an old PC power supply that I have laying around, and I should be set to go pretty soon to test the boards.

I had big plans of finishing the testing this weekend on the driver boards, but it now seems like I won’t get to it this weekend.  Probably sometime during the week.  The board is populated, the test fixtures are created.  I just figured out that a USB to parallel port won’t work, grrrr.  I started working on the Python test script, but I probably won’t have the time tonight to test, do a video, etc.

So about a month ago, somebody contacted me to get some boards so he could run an old playfield.  I was still looking for another alpha site to make sure somebody else tested the hardware and gave me feedback on the documentation, etc.  Since I tend not to use real names for people, I’m going to call him Cactus Jack.  (The name is completely based on the fact that he has a cactus at the front of his house.  Looks like a nice cactus.)  He has been working hard, and has tossed up a couple of videos and a little bit of a blog entry.  Of course, now he is waiting for me to finish up the incandescent driver boards.

The videos and blog are located at http://www.kerform.com/.

OPP Cards Displaying Status on Remote PC, 9/4/2014

So two weeks ago, a board was sent out to the board house (Iteadstudio) and all was well. I needed to get that work item done, so while it was being manufactured, and shipped I could do other things in parallel. I spent the next week trying to scare somebody away from the project, but utterly failed in that attempt. He has an old playfield Bullseye/301 with nothing to drive it. No cabinet, no electronics…basically a perfect match for using OPP cards. Joe has been dogging it lately (something about being busy with something other than designing his pinball machine), so I haven’t gotten as much feedback as I wanted from him.

I feel to insure the viability of an open source project, it needs to either be so simple that no documentation is needed, or there has to be enough information so that a person who understands the topic can easily find the necessary documentation. Pinball controllers are relatively complex. There are three main boards that are required to control a pinball machine. The overall design, architecture, and implementation are in my head, but how does a person that simply wants to re-use the board designs start with their machine?

The only way that I can make sure the information is available is to get somebody else to use the cards, and to document questions and steps during the process. Essentially take on an alpha customer to force the information to be generated. Joe was supposed to be that person, but alas, building a machine completely from scratch takes a long time. I’ve had the cards for more than two years (actually almost three) at this point, but things moved at a snails pace. (Much of it was caused by fear of actually cutting whitewood. If I had a CNC router, it would be a much easier process, but to build one of those, it is a couple month hit in time.) When the SS2 playfield was purchased, the decision was made to bring it back to life. It does not have a fan layout so that actually drew me to it. SS2 is relatively rare, which makes it more appealing to me. Next big step forward was getting a rotisserie. I had set up the Camelot playfield and batted the ball around, controlled all the solenoids, but it was sitting on blocks of wood, and with every flip of the flipper, it would almost fall off the table. Every time I wanted to work on the underside, it would be a half an hour production to go between the table top setup, and the leaning against the wall so I could solder it. A couple months ago I built the rotisserie, and it lets me move between playing and wiring in the span of about a minute. With the amount of testing that I did on the SS2 playfield and previous tests, I felt confident in the cards. When the new person contacted me about getting a few cards to drive his playfield, it seemed like a good match. He seems technical enough to get it working, and from reading his blog, it seems that he is better with a soldering iron than I will ever be. Once he gets some information up on his website I will post a link to it.

Last week I sent him enough cards to control the playfield and read all the switch inputs. After sending those, I immediately realized that he would need some sort of documentation to start the rewiring of the playfield. Well, all the information is in the blog, but who has the time to go through two years of my random mumblings (most of it pointless) to find the technical details. I’ve started a rewiring a playfield document to provide this information. The initial version of the document should be available in the repository by the time I post this blog entry. There is also another guy, (I think I’m calling him Pierre since he is from Canada), who says he wants to take care of the Google code repository wiki. That would be a perfect place to put much of this information or at least pointers of where to find it.

So last weekend after building cards, shipping cards, working on a document, etc., I finally got back to working on SS2. I finished the wiring for all the switch inputs, and wired the communications between all the cards. I dragged the laptop down to the basement, and ran PinBrdGui.py.

PinBrdGui is basically a debugging aid that I wrote a couple months ago. You tell it what serial port to look at, and it goes out and auto-discovers all the boards on that serial port. In SS2, there are two solenoid boards and two input boards. It displays the current state of each of the switch inputs on the input cards, and it displays if a solenoid has been triggered on solenoid cards. Input cards can also be configured to report edges, but that is not as useful to debug if the switches are working. When a solenoid bit detects the correct edge (usually falling edge since input bits are pulled up, and closing the switch grounds them), the next status read from the card will have a ’1′ in the correct bit position indicating the solenoid has fired. After the status is read, the solenoid driver card clears the status bit automatically. That means if the main processor doesn’t get around to reading the status for a while, it will not miss the fact that a solenoid has fired. In the embedded world these types of bits are called clear on read bits.

So here is a link to the video of the laptop getting real time status of input bits, solenoid kicks, from all the SS2 cards. https://www.youtube.com/watch?v=jKv1SIMZt1w. Couple notes on the video. On solenoid card #1, you can see the lsb fluttering. That is caused by a manufacturing defect on the card (probably a whisker of solder). That should only take about 5 minutes to fix when I have the time. The PinBrdGui helped me figure out that issue immediately since I could leave the switch open and see the fluttering, and close the switch, and see the fluttering immediately stop. Some persistence should be added to the displaying of the solenoid status bits. Since the status rate is so fast and the bit is only set for a single frame, it is easy to miss a solenoid input bit going past. A frame rate should be added. I’ve estimated and calculated the worst case status frame rate, but having PinBrdGui print out the actual number of frames per second would be a great debugging tool.

I have notes to write about 10 more things, and frankly I need to finish the playfield rewiring document. In the above blog entry, I promised the document would be finished before I posted this. I lied. I’ll write more after that is in the first draft form.

Incandescent Driver boards, 8/23/2014

So as I’m typing this, the incandescent driver boards are finished.  Of course, since I can’t bear to waste an inch of PCB, I’ve also started working on the next generation of driver boards.

I’ve decided to start working on the next generation of boards.  This is solely based on the fact that I have extra PCB area.  The incandescent driver boards are 2.5 cm x 5 cm.  The PCB house I use sells 10 cm x 10 cm boards.  That leaves 5 cm x 10 cm of board space.  That happens to be just enough space for the next generation driver design.

Here are the list of improvements:

  • Completely open source solution.  The next generation will switch from the HCS08 processor to the an ARM based processor.  This allows to switch from Freescale’s CodeWarrior, to CooCox and the CoIDE which are both free and open source.
  • The first generation required an $80 debugger to program the bootloader in the processor the first time.  After that, code could be updated using the serial port and the boot loader.  The fact that the debugger is required, makes the first generation more expensive for people trying to independently create a pinball machine.  The next generation contains the debugger on the development board.  There is also an embedded bootloader, so if creating cards from scratch to make them cheaper, that bootloader can be used.
  • The HCS08 in the first version used a DIP package for the processor.  That package for the processor is end of life, so the cards would have to be laid out again.  That would involve switching from DIP packages to surface mount packages which would make home assembly more difficult.
  • The next generation uses a standard off the shelf development board.  The solenoid driver/input driver boards mount to the development board using the breakout header pins.  All soldering remains through-hole components to make it easy for hobbyists.
  • The first generation cards were either solenoid drivers or input cards.  The next generation allows the cards to be either input or solenoid drivers, or a mixture by populating the boards differently.  Since there are less different cards, a single order of 10 cm x 10 cm PCBs can build two complete pinball machines.
  • The next generation of boards have switched from 5V processors to 3.3V processors.  Previously a voltage conversion needed to take place between the solenoids drivers/input drivers and the Raspberry Pi.  Now that everything is running at 3.3V, that converter can be removed.  This makes interfacing between those two cards, that much easier.

So, I don’t really have time to write the firmware for the next generation of cards.  I’ve done minimal amounts of work getting interrupts working on the ARM processor, and blinking LEDs.  I started looking at doing the bootloader, but it would take about a full month of work to get everything up and running.  While it would be fun to do that, I’m busy getting the rest of the framework done.

That put everything on hold for a while, but then, suddenly a couple weeks ago somebody approached me to help with the Open Pinball Project.  This seemed like a natural fit to have him work on the next generation.  He has some Arduino experience, but we will see if he can show production quality firmware.

There are other things that are happening too, but there isn’t enough time for me to do all the updates this evening.