9/25/2015, Neopixel Eye Candy

Looks like this weekend is the time to try and hookup the Neopixels.  There have been a bunch of small changes that I ended up making to get things working as efficiently as possible.

So I got a little over zealous in the belief that I had infinite processing power.   The SPI bus is running at 2.4 MHz, so each bit is 417 ns.  8 * 417ns =  3.33us.  Hmmm, that’s pretty darn fast come to think of it.  Assuming 1.5 assembly instructions/clock (RISC based processor with most stuff 1 cycle, but  loading, storing, and pushing info onto the stack takes more cycles.  Branches are particularly long since the pipeline may need to be flushed), that means the processor has about 53 instructions.  In a tight loop the processor was not able to keep the FIFO filled.

The processor is only running at 24MHz (the default), so let’s kick that up to 48MHz which is what the processor can run.  That made it so the processor could keep the FIFO full without an issue.  The dream of dynamically determining pixel color is probably not possible without hand coding assembly.  It is much simpler to allocate the required memory at initialization, and update the RAM on the periodic timer.

Kept thinking about what else could be done.  The TX FIFO for the SCB can be changed to 16 bits wide instead of 8 bits wide.  This is somewhat annoying since each pixel takes 9 bytes of data, and now pixels must cross a FIFO write boundary.  Last optimization is using the TX FIFO level to kick off the processing.  If the level is set to 4, there are 5 16 bit pieces of data (4 TX FIFO slots, plus the shift register itself) of interrupt latency that can be tolerated.  That is about 33.33us of interrupt latency that can be handled without underflowing the FIFO and not properly updating the chain of Neopixels.

So for 64 Neopixels, the amount of RAM required is (64 * 9) (RAM for holding data sent on SPI bus) + 64 (holds current command for each Neopixel) = 640 bytes.  The processor has 8K, so only using half the RAM for this allows about 400 Neopixels per board.  Of course, there is no reason that you couldn’t put multiple boards into the machine to support more, but well, that seems ludicrous.

Here is a quick picture of the demo systems setup:

Neopixel Demo

Quick video of the Neopixels working:

There is something weird going on with the first Neopixel.  It might be that I got it a little too hot when I soldered the wires to the strip.  (I didn’t “tin” the pads before soldering on the leads, which meant I had to use a lot more heat).  It could also be a bug in the program, and I should probably send a blank 16 byte word before sending the first bit of data.  At this point, it is good enough to hand off.

I’m getting pretty familiar with the processor at this point, so it is getting faster for me to add new features.  I really have to work on the next serial commands to interface with the next generation of the boards.

9/17/2015, Neopixels, Get Off My Back

So multiple people have asked me about Neopixels and do I support them.  I was so busy looking at other stuff, I simply did not have the bandwidth to look into Neopixels.  As the work on SS3 was winding down this Summer, and I started to look into the next generation boards, I thought that I should do some research to make sure that I didn’t preclude their use.  In July I did read about them, and even included a wing board to make interfacing with them as simple as possible.

I was originally hesitant about Neopixels because it adds one more layer of difficulty to programming a pinball machine.  Right now, the OPP hardware only supports turning on and off lights (either incandescent or LED bulbs).  The framework supports turning the bulbs on or off, or blinking the lights slowly or rapidly.  The blinking happens automatically in the framework so the user doesn’t have to bother with changing the lights all the time.  If I switch to using Neopixels, they are not simply on/off, but now they can support different colors which will be even more difficult to use.

I spent a couple of days trying to figure out the best way to command a “smart” Neopixel controller.  One would be to continuously send the color for each pixel, and that would provide all the features.  That would use a lot of the bandwidth of the serial links between the boards and is very inefficient.

Instead, I decided to use a byte for each of the pixels.  The byte contains a command (turn pixel on, blink quickly, blink slowly, fade quickly, or fade slowly), and a color index which looks up the pixel’s color using a color table.  The color table contains 32 possible colors, and of course there will be commands to change the color table as necessary.  (Each entry in the color table contains the 8 bits for red, green and blue parts of the color).  The blink commands simply turn the pixels on and off with the chosen color in a synchronized fashion.  The fade commands go from dark to bright, then back to dark to allow the pixels to pulse.

I’m planning on trying to get the Neopixel code up and running on the PSoC 4200 board this weekend or next.  (It really depends on how quickly I can bring up the debugger).  I’ll use short button presses to change the color, and long button presses to change the commands to demonstrate that it is working properly.

Here is a concrete example why using the simple generic code that Creator provides will not work and why such code should be avoided.  To talk to the Neopixels, the processor uses the SCB SPI bus component to stream the data.  The SPI bus will be running at 2.4 MHz to meet Neopixel timing specs (3 SPI bits for every 1 Neopixel bit, matching the Lady Ada Uberguide specs).  Every 20 ms the Neopixels will be refreshed.  (This is so things such as automatic blinking and fading can happen automatically).  That boils down to 9 bytes of data/neopixel * 64 max neopixels = 576 bytes of data/20 ms.  (It will support more Neopixels, but 64 seems like a good starting point).  The standard functions created by the tool are blocking calls.  Blocking calls wait in a busy loop if they can’t put all the data on the Tx buffer.  If a solenoid needed to be fired at that time, it couldn’t happen because the processor would be busy updating the Neopixels.  Not very efficient at all.  Instead, the code will watch for the FIFO empty interrupt and when that happens toss another 8 bytes of info onto the FIFO, and then go back to normal processing.  This means that the processing of the Neopixel data is distributed over the 20 ms time period, and latencies for other processing will be reduced.

So why is the name of this post “Get Off My Back.”  I’m hoping that either this weekend or next weekend I will have the code up and running, and be able to hand off a demo unit to allow Dave to play with it and see its capabilities.  He currently makes replacement backbox lighting mods for Stern machines and does a really nice job.  This should give him a very low cost solution so he will be able to make his backbox mods that much more exciting.

8/31/2015, PSOC 4200, The Good, The Bad, and The Ugly

Nice name for the entry seeing as though it is already ten days after I started writing this post.   This entry is going to be mostly on bringing up an embedded processor from scratch.

So I started working with the PSoC 4200 over the last couple of weeks.  After going down a good number of rabbit holes, and not being able to figure out if certain tools would work together, I decided to simply suck it up and use the Cypress Creator software to start.  The bonus of that is that within a couple of hours I was able to download the example project, and burn it onto the board and run it.  I then made a small change, recompiled and threw that down onto the board to make certain that I was actually programming the board successfully.

When I bring up a processor from scratch, I like to follow a pretty rigorous path.  It basically moves from the absolutely easiest stuff to the more difficult stuff.  Here is the order that I tend to tackle the projects, or embedded programming 101:

  1. Blink an LED.  Almost every board has an LED on it, and if not throw down a resistor and an LED on one of the output pins.  The first incarnation uses a loop and a counter to blink the LED on and off.  I then modify the counter in a loop to make it blink either faster or slower to prove to myself that I am altering the code successfully.  (At this point, I hook up a debugger and make sure that I can view and step through the code to make sure that I have the debugger set up properly.  Currently, I don’t have a debugger, but I’m hoping to grab one in the next few weeks).
  2. Blink the LED using a timer to change between the LED on and the LED off.  This proves that I understand configuring the timers, and understand the clocks within the chip.  It is very easy to accidentally miss clock divider, or be off by a little bit.  This step also requires understanding clock routing within the chip.
  3. Use the timer to cause an interrupt and change the LED on/off state in an interrupt.  Requires understanding of interrupts, interrupt vector table, and how to clear the interrupt sources.
  4. Transmit words continuously on the UART interface.  Make sure that I have the baud rate set up properly for the UART, and can see the data coming back on a PC.
  5. Echo received characters on the UART interface, back to the transmit interface.  When a type an ‘x’ on the keyboard, I should see that echoed back.

After finishing those five simple steps I’m usually familiar enough with the processor, that every thing else is simply reading documentation and digging through registers.   Doing the above steps forces the programmer to read and understand the documentation since every company documents their chip in very different ways.  Some companies have a single 2000 page programming reference guide, while other companies break each hardware subsection into a different document.

So one of the absurd things with the Cypress Creator IDE is that it tries to force the programmer into using their canned components as opposed to actually programming the processor.  If a UART is needed, drag and drop it into the fake processor schematic and fill in a couple of fields.  No need to understand the registers that actually are underlying the component.  Same thing with I/O pins, SPI buses, etc.  The down side to that is the code becomes very large, because it requires all of these generic components where most of the functionality is not being used.

Here is the actual code C code that blinks the LED on the board:

typedef volatile unsigned long R32;
typedef unsigned long U32;

#define GPIO_PRT1_DR        0x40040100
#define GPIO_PRT1_PS        0x40040104
#define GPIO_PRT1_PC        0x40040108
#define GPIO_PRT1_INTR_CFG  0x4004010c
#define GPIO_PRT1_INTR      0x40040110
#define GPIO_PRT1_PC2       0x40040114
#define HSIOM_PORT_SEL1     0x40010004

int main()
   /* Initialization code */
   U32 count = 0;

   *((R32 *)GPIO_PRT1_DR) = 0xff;
   *((R32 *)GPIO_PRT1_PC) = 0x00180000;
   *((R32 *)GPIO_PRT1_INTR_CFG) = 0;
   *((R32 *)GPIO_PRT1_PC2) = 0;

   /* Send the GPIO bit to the hardware pin */
   *((R32 *)HSIOM_PORT_SEL1) &= ~0x0f000000;
      /* Place your application code here. */
      if (count == 0x10000)
         *((R32 *)GPIO_PRT1_DR) = 0x00;
      if (count >= 0x20000)
         *((R32 *)GPIO_PRT1_DR) = 0xff;
         count = 0;

Looking at the above code, it is a grand total of five initialization statements, and then a simple loop with a counter changing the LED bit on and off.  Compiling the code, takes maybe two or three seconds.  It produces 100 bytes of object code.  Using the Creator tool, and a PWM to blink the LED on and off, it takes a little over twenty or thirty seconds to compile, and generates a couple K of functions that I may or may not use.  The long compile time is caused by auto generating code, routing and configuring clocks inside the chip, and running the FPGA style generator.  I’m not really using any of those resources currently, so it is simply a waste of my time.

The other issue is that Cypress has allowed their documentation to take a back seat to their code generation tool.  The documentation is not only poor, but it is incomplete.  I tried to find the address of certain registers, and it is not located in any of the documents.  I had to dig through their generated code to figure out the addresses of the registers.  I would say that their documentation is very poor, even below Microchip if that is possible.  Right now Freescale and ST Micro have very good and very complete documentation.  Microchip, and Cypress don’t compare.

They provide a bootloader.  That is fabulous especially if it is written well.  The only problem is that it seems to have been written by a first or second year co-op student.  The bootloader size should be as small as possible.  The Microchip bootloaders I wrote were either 768 or 1024 bytes depending on the processor.  The Freescale bootloader was 1024 bytes.  (It was actually about 530 bytes, but because of the flash protection scheme, code could only be protected in 512 byte blocks, so I had to move to two blocks).  Their bootloader component is 6400 bytes, or 1/5 of the 32K of code in the processor.  What the heck are they doing in there?  Maybe they are running the SETI program with the unused cycles.

A second issue with the bootloader is that it requires RAM for the interrupt vector table.  Admittedly, that is the easiest way to write a bootloader, but it means that 196 bytes of RAM are sucked up by that table.  A better, but more complex method is to create a jump table in the low flash, and move the exception vector table into the application code and not rely on .  While it will incur a couple extra clock cycles of delay during an interrupt, the RAM is preserved for use by the application code.  That would have been a show stopper with the old processor that only had 8K of Flash and 512 bytes of RAM.  Since this processor has 32K of Flash, and 4K or RAM, it is less of an issue.

Right now I don’t have a debugger.  I’m gonna grab a Pioneer board (costs about $25) which includes a debugger and a PSOC 4200 processor.  Having a debugger will really accelerate the speed of developing the code.

8/17/2015, Why have I never stopped at Flippers in Grandy, NC

Disclaimer:  No technical content on this blog entry, so if that what you seek, just skip over this one.

My family has been visiting the Outer Banks in NC since 1968.  To get there you drive down to Norfolk, VA, and then take little two lane roads until you reach the Outer Banks.  This year, the drive down from Boston was split into two days and spent the night in Norfolk.  Getting up in the morning, we got a jump on the traffic and I got a chance to stop at Flippers.

Wow, the arcade is fantastic!  They have both old and new machines.  This is where the NC state finals are held, and it is very easy to see why.  They probably have 50 or 60 pinball machines, and all of them are in exceptional condition.  The machines play like they should play.  They haven’t clearcoated all the playfields so that all the shots are easy.  The playfields are the original playfields, and they play how they did 30 years ago.  Spectacular.

Here were some of the highlights:

  • Humpty Dumpty machine that you can play for a nickel.  First flipper machine ever, and it just has to be given a try.  It almost seems like a nudge machine instead of a flipper machine.  It is very difficult to move the ball up the playfield and a flipper can only move it up one level.
  • Big Bang Bar.  Set at 50 cents per play.  Actually all the machines that I played were 50 cents a play.  I now understand why people call it a single shot game, but it was really fun to play it.  The callouts are not for the kids.
  • Cactus Canyon revisited.  Very fun game.  Seemed to have lots of different shots and a good amount of depth.
  • Monster Bash.  First Monster Bash that I have played that didn’t have major issues.  Tons of fun to shoot Frankenstein and electrify him.
  • Medievel Madness.  Always a fun play.
  • Tons of new Stern machines including Kiss, Walking Dead, Star Trek, etc.  By why play those, when you have so many classic titles to choose?  (Well one reason might be because they are only 50 cents a play)

I’m hoping to break away from the family and do one more trip up there to play for a couple more hours.

If you are going to the Outer Banks in NC, you will be driving past Flippers, and you should really stop.  Stop for a couple of minutes to play some really rare machines, or spend more time, and really get a chance to experience the best arcade that I’ve ever seen.

8/11/2015, Second Gen Boards arrived

Good gosh!  I am consistently amazed at how quickly boards can be produced in China and get shipped to the US even with slow Hong Kong post shipping.  The boards were ordered on 7/28/2015.  It is now 8/11/2015, so the boards were received in 2 weeks even choosing the slowest shipping option available.  (They did up their shipping rate by $3 which annoys me, but it continues to be a really good value for the money.

It is funny how when laying out boards, it is always zoomed into the board, so it seems like they are rather large.  Then when they are received, wow, they are really itty bitty boards.  Each wing board is approximately 1″ x 2″.  When eight of them are thrown down on a single PCB (i.e. the mashup which is in the repository), it is still only 4″ x 4″ of PCB (or < 10 cm x 10 cm).

Last night I cut out all the boards using the tile saw.  Next time, I might change the mashup layout a little bit to minimize the number of cuts that I have to make, but all in all, it worked out really well.  It took about an hour to cut out the 80 boards.  I soldered up two of each of the cards and I’m shipping them out to somebody who is interested in working on the embedded code for the next generation boards.

After looking at the PSoC 4200 in a little bit more depth, I’m not really that jazzed about their initially programmed bootloader.  It uses too many resources and does not seem “hardened” enough.  One of the lower priorities will be to rewrite that piece of code.

Here’s a quick picture of all the boards cut out:


Here are the boards that are populated.  Note:  When I tried to do the mashup, I lost the VLED voltage plane, so I had to add a wire.  I fixed that issue the day after I ordered the boards, so the Gerbers in the repository are correct.


Here is a mockup of the PSoC 4200 with the wing boards.  This guy supports 4 solenoids, 8 inputs, and 16 incandescent bulbs (Note:  Inputs don’t require a card because they are attached to the inputs of the processor.  You can see the connector soldered straight to the board):

Sol4, Inp8, Incand 16

Here is a mockup of the PSoC 4200 with the wing boards.  This guy supports 8 solenoids, 8 inputs, and 8 incandescent bulbs:

Sol 8, Inp 8, Incand 8

Last mockup with the wing boards.  This guy supports 4 solenoids, 16 inputs, and a SPI interface that can be used to talk to WS2812 chips (Neopixels):

Sol 4, Inp 16, SPI

I did some quick power measurements on SS3.  Power for SS3 in Attract mode 142W.  Power holding up both flippers 202W.  Base power for the four power supplies creating 48V is about 50 to 60W.  Taxi in attract mode is 110W.  Holding both flippers up is 140W.  I’m going to be removing 4 of the PC power supplies and replacing it with a single 36V supply.  That should reduce the power by a good amount.

7/30/2015, OPP, the second generation ordered

This week there was a good amount of time to work on the next generation of OPP hardware.  The hardware design/layout is all completed and was ordered on Wednesday through ITeadStudio.  The cards should show up in three to four weeks.  All of the parts from Mouser have been ordered including the processor cards.  The processor is separate so all of the embedded development can happen even before the cards from ITeadStudio are received. Here are the major changes that are in this new version of hardware:

  • The main processor has be changed from a MC9S08SE8 to a PSoC 4200 processor.  The original processor’s package has been End of Life’d.  That means either changing packages (which would mean moving to a surface mount package), or switch to a different processor with a development card so all the cards can keep using through hole parts.  I chose to switch processors.  The choice was then between the Teensy LC, STM32 discovery boards, and the PSoC 4200 Prototyping kit.  They are all Cortex-M0 processors, but only the STM32 and PSoC are 5V processors.  (Useful when enabling/disabling FETs without needing to voltage shift).  The STM32 boards have a larger footprint, so I ended up choosing the PSoC 4200.  Here is a quick link to the prototyping kit from Mouser.  The prototype kits are $4 which is below my target price.  Since it has 32 useable I/O pins, each card can support up to four “wing” boards.
  • The original processor required a debugger to program the chip.  The new processor has a bootloader built in at the factory, so no debugger is needed.
  • Connections between cards was previously accomplished using a 4 pin 100 mil header.  The new boards will use an eight pin ribbon cable to make wiring between cards easier.  The 8-pin ribbon cable adds a couple extra signals including 12V and a synchronization pulse.
  • The solenoid cards used to use an individual spade terminal to kick the solenoid, and a 2 pin 100 mil header for each switch input.  The new solenoid cards use a six pin 4.2 mm spaced Molex connector to kick the solenoids and return the solenoid current, and a single 4 pin 100 mil header for all the solenoid inputs.  Having only two connectors will make it easier to remember the location of the connectors.  This was particularly a problem with the input card since it contained 16 individual connectors that all looked the same.
  • The input only “cards” now have a single 8 pin 100 mil spaced connector for all the inputs.  There is actually no board needed for the input only functionality, the 8 pin header is simply soldered into the PSoC 4200 board.
  • The new board supports an incandescent wing board.  Previously, the incandescent drivers were driven using a SPI bus which was bit banged from the main computer.  The new incandescent wing board can support eight incandescent bulbs, and communicates using the normal UART bus.  A synchronization signal has been added to insure that all incandescent boards can synchronize their blinking if desired.  Instead of using four  2 pin 100 mil spaced headers to drive the bulbs, a single 8 pin 100 mil spaced header is used.  Again, this makes it easier to remove and re-install cards and keep track of wiring.
  • A card with support for a SPI bus or a Neopixel driver.  After talking to a bunch of people at Pintastic, many people were interested in driving WS2812 LEDs.  I have shied away from this for a long time because I don’t believe I have the artistic ability to utilize colored LEDs.  It is very simple to use the SPI interface which is part of the 4200 to command the multi-colored LEDs.  The 4200 running at 5V means no level shifting is necessary to talk to WS2812 based strip LEDs.
  • Previously, each board (input or solenoid) had a different load of firmware on it.  The new boards have enough flash memory that a single version of firmware will support all of the “wing” boards.

The PSoC 4200 has two 8 bit wide ports on the left side of the card, and two 8 bit wide ports on the right side of the card.  (It also has a USB to serial port converter on top of the card, which kind of looks like a head because it is made to be easily snapped off).  Two “wing” cards are soldered to the left side ports, and two “wing” cards are soldered to the right side ports of the processor, making the whole setup look sort of like a dragonfly.  Up to four wing cards can be populated if desired.  In some cases, it might make more sense to add another PSoC 4200 board to keep wiring lengths to a minimum.

The new mashup PCB which is in the repository contains the following “wing” cards:  three solenoid drivers, one input board, two incandescent boards, and two interface boards per PCB.  The PCB is laid out to fit on a 10 cm x 10 cm board.  Each solenoid board can drive 4 solenoids.  The input board can drive a single SPI interface (probably used to drive multicolor LEDs).  Each incandescent board can drive eight incandescent bulbs (or LED bulbs).  The interface boards contain ribbon cable connectors for communication and a communication connector that matches the first style of OPP cards for backwards compatibility.  (Two pins are reserved on the ribbon cables to insure that the cables can’t be plugged in incorrectly.  These could easily be converted to support differential transmit/receive signals if I find it is necessary.)

Here is a quick picture of the mashup PCB:

Mashup, Gen 2

There was a Pinside thread which discussed the differences between PROC and Fast pinball controllers.  Both PROC and Fast controllers are great solutions and available right now.  During that thread, both of the people that have the original OPP cards chimed in about using the OPP hardware.  (Thanks guys, it is always nice to hear that you have had positive experiences so far.)  The original poster mentioned that the OPP hardware was not going to be a possibility because there is no “Buy it Now” button.  I have stated to many people that I am not going to manufacture cards because I work on pinball as a hobby.  That being said, how would a person get the OPP hardware that they wanted?  Up to this point, all the people have contacted me via email, and if I think that they have a real project to work on, and they sound like they have a chance to finish the project, I agree to send them out hardware.  (In all those cases so far, I have both populated and tested the boards)  That is not a sustainable model in the long term.  My current thoughts are that people contact me, and I send them out the bare boards, and then they order the parts to populate the boards locally.  (Through either Mouser or Digikey).

When ordering boards (an order costs $30.50 which includes shipping to the US), ten copies are received from ITeadStudio.  (Each ordered board contains the eight individual cards).  I believe that it will take 2-3 PCBs for a pinball machine (depending on the desired features).  So for a single order, you can build approximately three pinball machines.  It doesn’t make sense for each user to order boards themselves since they will only use 1/3 of the order.  That is why if they contact me, I can take care of sending them the boards that I have available and they don’t need to order from a board house.  That should remove many people’s fears of needing to learn Kicad, talk to a board house, etc.

Let’s talk about the people that should not use this board set.  The board set does not support DMD interfaces, or old style displays.  It is assumed that a computer (such as a Raspberry Pi, Beagle bone black, etc will front end these cards, and will provide display capabilities).  The board set is tailored towards wiring a machine from scratch.  I would like to encourage people to put these boards below the playfield to make the wiring as minimal and simple as possible.  The board was designed as a distributed system, and bringing all the wires to the back box removes most of those benefits.  The one concrete reason why this board set may not work as a replacement boardset for a standard pinball machine is that the solenoid switches may be part of the switch matrix.  To make the solenoids fire as quickly as possible, I have assumed that solenoid switches are not part of the switch matrix.  I am going to attempt to update a machine this Fall without rewiring it, and just attaching the cards in the backbox.  Since I haven’t done that yet, I can’t be certain it is going to work without requiring wiring changes.  Both the PROC and Fast controllers are meant to be drop in replacements for many old boards.  Choose whichever one of those best matches your needs.

So how much is this going to cost to build a set of these boards to support a pinball machine.  I will use the SS3 features to calculate complete costs for the boards.  SS3 uses the following rev 1 boards:  two solenoid boards, two input cards, and six incandescent boards.  That means that it will require four PSoc 4200 cards to run the system.  The total cost for the whole system, including connector costs and shipping costs is $95.83.  Actually a more apples to apples comparison would be to drop out the connectors which brings the price down to $66.75.  (I’m guessing when they quote PROC/Fast prices, they don’t include the connectors that you need to actually use the boards.)  Here is a link to the Gen2Board Board Cost that calculates all the costs.  If I switched the insert lighting to WS2812 style serial LEDs, the cost would go down even further.

I am currently hoping that all the embedded code is updated, running, and tested by the end of this year.  It should not take that much work, I just don’t want to over promise and not deliver.

7/24/2015, Thoughts on Pintastic

I took SharpeShooter III to Pintastic as promised.  I’ll start by giving my thoughts on Pintastic, and then my thoughts on how SharpeShooter III performed.

Pintastic was probably the best pinball event that I’ve attended.  My feelings on the event are probably colored by the fact that I had all day Friday to talk to friends and just play a ton of pinball without the day ending in a six hour drive home.

Here’s how the weekend went…  Took off work a little bit early and drove down to Sturbridge.  I escaped Boston before the traffic got too bad which made for a more pleasant drive.  When I got there, Gabe and Derek had  a good number of dollies available to move machines from cars.  I moved the machine in and put it back together fully expecting to have issues.  Twenty minutes later, it was all together, kicked on the power, and the machine was up and running.  (I had every tool I could think of to fix any issues, but it turned to not be necessary.  The biggest issue I had was with one of the light sockets shorting out, which made two or three of the GI bulbs not work.  I tried to fix it with the soldering iron, and found out that the insulation for the socket was failing and didn’t have another socket with me.)

Now the bad.  On Tuesday and Wednesday, I added a couple new features.  I didn’t really have time to test the changes very thoroughly, and hoped that I got them right.  It turns out that I introduced a couple of bugs, that I didn’t find until I got home after the show.  I should have known better than to update the code without testing it that close to the show, but they were new features that I really wanted to have available.  (i.e. having the Aerosmith Sharpshooter song play when the game was in attract mode, and adding a timer to the kickout hole so that only a single callout would happen.  The kickout hole change ended up introducing a bug where the kickout hole would not fire if certain modes were active.  I checked on the machine every couple of hours, and there were a number of times that I saw the ball stuck in the kickout hole.  It took me less than 5 minutes to fix it when I got it home, but unfortunately I didn’t have time to look into it until I got home.)

Thursday, after I finished setting up, a random person walked into the room and he got to be the first person who is not my family to play the game.  It worked well, and I watched a couple other players play a couple of games.  Since it was part of the Restoration Throwdown Contest, it was in a room with only one other machine.  It was a strange setup, where I’m guessing that most people didn’t really understand the point of the machines in the room.  I changed the machine to start up automatically when plugged in, tested it, and it worked first time.  I left the show and drove back home on Thursday night.

Friday was the big day.  I woke up early, and drove back to Sturbridge, getting there at about 7 am.  Plugged the machine in, and it came right up.  (Oh, yeah, I never ended up getting around to installing an on/off switch, so yeah, it is simply plug in to turn it on, unplug to turn it off).  Turns out that there isn’t much to do until about 8:30 am, so went to the McDonalds and grabbed some coffee.  Saw LTG (got to thank him for answering so many of my technical questions on pinside), and saw Jersey Jack and talked to him for a bit.

At 8:30 am, the pinball began, and really continued mostly non-stop for the rest of the day.  There were probably about 100 or more machines to play, and so with the number of people there, I never had to wait to play a machine.  Every couple of hours, I would go back and check on SS3, and make sure that it was running properly.

There were a couple of new games that I wanted to try in the dealer area.  First one was Full Throttle.  I got to play three  or four games on it, and it was a blast.  It is really, really fast.  It is really, really fun.  I hope one of the local arcades, or someone who buys new machines in the area grabs one.  Next machine was the Lexy Lightspeed.  I really wanted to hate the machine because I tend to dislike pinball mixed with video games.  It turns out that I think that Gerry did a good job of striking a balance between those two.  It was less video gamey, and more pinbally than I was expecting.  I enjoyed the game a lot, and wished I would have been able to play a couple more games to get a good feel for some of the modes.  I have to say I was very impressed.  The flipper buttons lagged the flippers by a couple of milliseconds which was strange, but I think you would get used to it.  Last game was the Hobbit.  I ended up playing three games on it, and it was so lacking in features, I couldn’t really get a good feel for the game.  The machine had one of the rollover switches disabled so that you couldn’t get into some of the modes.  Seemed almost like I was playing a whitewood.  We played in groups of four, and I never saw Smaug.  Maybe that was one of the things you couldn’t get to because the switch was disabled.

A friend from CT showed up with his daughter and we got to play a ton of games on Friday morning.  As it got towards noon, I decided to grab lunch at the restaurant by the lake.  Glad I did it at that point, because the lunch took over two hours to get our food.  Sloooowwwww.  It was time for me to give the talk on creating SharpeShooter III.

So here are the quick links to the videos of the talk.  The first video is the main portion of the talk, and the second video are the questions and answers.  The sound is not that good, because, well, I didn’t speak directly into the microphone.  Here are the links:



Link to the slides:


Luckily not many people showed up for the talk, and of the people that did show up, I knew most of them.  I don’t know why random people would show up and watch the talk.  I’m guessing that they were tired and needed a place to sit and rest.  The strangest thing was that Roger Sharpe showed up to hear the talk.  I hope I didn’t bore him too much.

Another nice thing about the first year of a show is that it is pretty small.  Just walking around the halls, you would run into people.  There were three or four times that I ran into Roger with my family, and I’d point at him and go, that’s Roger Sharpe, and my kids would go, “ooooohhh” (with awe in their voices).  They only know of Roger Sharpe as the person that the machine is based around.  I wish I would have had a chance to watch Roger play the machine.  I’m guessing he would have been able to hit the shots, and I could have talked him through starting a couple of the modes.

So, finished up the talk, and a bunch of local friends had some questions.  We meandered over to the SharpeShooter III machine, and I took off the glass, lifted the playfield, and showed the OPP hardware.  I also pulled the backglass so people could see what was back there.  At one point, I was pulled up the pinball framework, and showed you could run the code, simulate switches, and play a “game” on my laptop.  It was a great discussion, because some of the things that we talked about gave me some really good ideas on what is next for the OPP.  More on that in another blog entry.  After an hour of talking in the seminar, and another half an hour answering questions, my voice was spent.  Mark and I adjourned to the lake for some relaxing.  It was a great chance to catch up with him.

The pinball hall was supposed to close at some point, but even after announcing it would close in five minutes, nobody moved, and we continued to play for another couple of hours.  We then moved  over to the Friday night JJP after hours party.  I missed the discussion, but just when I thought I couldn’t play any more pinball, Mark and I found out that they had opened up the hall again.  We ended up playing another two hours of pinball, and that is when I got the chance to play the Hobbit.

Saturday was much less pinball related.  The kids showed up, but both had been sick for the previous week, and didn’t feel like doing much.  They played about three or four games of pinball, and then decided they would rather relax by the lake, or go swimming in the pool, or play a round of mini golf.  The pinball hall was really loud with all the machines, and that turned them off a little bit.  I got a chance to catch the Roger Sharpe talk and ask a question.  I grabbed a couple of games on some machines that I had missed such as Sopranos, and Simpsons Pinball Party.  Teardown was Saturday night and they had a band playing which was really fun to hear as you are working away.  I wish I would have been able to spend more time listening to the band.

So there were a couple of issues with SharpeShooter III which I just didn’t have time to fix before the show.

  1. First major issues was the incandescent driver boards.  I calculated the input and output impedence for the shift registers, but ended up messing up the math.  This meant that the clock pulse was reflecting on the long lines, and ended up glitching the lights.  I started with 56 ohm resistors on both the clock and data lines, but they should really be increased to 500 or 600 ohms.  That would make the game look a lot better.
  2. I would say that the code was pre-alpha.  There was definitely a bug at the show that would get the machine into a state where it couldn’t be played.  My bad for trying to update the code on the first morning of Pintastic and not having enough time to really test the changes.  I should never have done that, and should have had a code lock for a week before the show instead of trying to add new features.
  3. The game is too hard.  To start a mode, all inlanes and drop targets need to be collected.  Drop targets are pretty easy to collect, but the inlanes are difficult.  Since the drop targets don’t get reset until the mode is started, or the ball is lost, it can be very difficult to get the last inlane.  The code should be updated to reset the drop targets in easy mode  as soon as they are collected.
  4. Sorry to all the people that played the game and saw some of these errors.  Next year it will be that much better, and hopefully will be complete.  Should only take a short amount of time to fix these issues, but with the time crunch, I was not able to get it done.

I’m tired of typing and need to do some other things.  I promised my wife to work on many things so that I could get a pass and work on the pinball machine for all of June.  That pass has now been returned, so now I have to work on a bunch of items on the to do list.  (Of course, I’m still working on other pinball things when I have time, but probably nothing major will happen for the next few months.  Updates to the blog will probably only happen once a month for the next couple of months.)