The M6800 implementation of solenoids uses the 120Hz ISR to control the solenoids. They did this for several reasons:

  • Time out the duration that solenoids are kept on. According to the Bally Theory of Operation document most solenoids need to be kept on for 3 zero-crossings in order to properly energize the solenoid. In reality, they power some of the solenoids for far longer. For example, saucer kickers need to be energized for at least four cycles (30+ ms), and drop target resets are energized for 120ms. Energizing a drop target reset for less time doesn’t guarantee that the targets won’t bounce back down.
  • Solenoids need to be turned off close the voltage nearing a zero crossing so that the life of the transistors can be maximized.
  • Some solenoids (slingshots and pop bumpers, for example) need to be energized as soon as a switch closes so that the response of the machine is quick.

For those reasons, the Arduino implementation controls the solenoids in the 120Hz ISR as well. To reproduce the M6800 timing, I captured several scope waveforms from the M6800.

This is Solenoid 1 (one of the chimes) being rung twice. You can see the solenoid line being held low (engaged) for three zero crossings and released on the fourth. To accomplish this, the M6800 code kept a countdown value that it decremented each time through the loop. When it got to zero, the solenoid line was released.

The way that solenoids are implemented on the MPU-100 and Bally AS-2518-17 uses four lines to engage one of 15 solenoid lines at a time. The sixteenth line (U11B:PB0-PB3 all high) is unused on the solenoid driver board. The solenoids can be prevented from triggering by raising U11:CB2, but I couldn’t find any time when that’s done. Perhaps I didn’t look hard enough. Maybe during a tilt? At any rate, as long as U10:CB2 is low, any combination of signals on U11B:PB0-PB3 will trigger a solenoid, but since this is a 4->16 decoder, only one solenoid at a time can be triggered. An example of that in a moment. First, here are some other solenoid signals so you can have a sense of how they work.

This is one of the chimes being rung 5x in a row (for a 500 score, I believe).
This is the outhole kicker serving up the ball.
This is a target bank being reset – note how long it takes (120ms) to make sure the targets get reset.
This is two target banks being reset at the beginning of a ball. Still 120ms each, but there’s a small gap between them since they were two different events that were programmed in (as opposed to events triggered by switches).
Pop bumper is held for 5 crossings to really engage it.
Slingshot is held for 4 crossings.
A different slingshot – this time for 5. Why? I’m not sure.

All these solenoid signals shown above pretty much engage the solenoid between the zero crossings and disengage the solenoid right at the zero crossing. Turning them off at a voltage close to zero makes perfect sense – you want to minimize the voltage when you turn off the transistors. I don’t know if turning them on when the voltage is high is a requirement. I don’t think so, but I haven’t found anything to say one way or the other. I believe that these solenoids are turned on between the zero crossings because the switch reads are the last things done in the 120Hz interrupt. That would account for the delay in turning them on. If I’m wrong and you know differently, please let me know.

As mentioned above, the hardware can only energize one solenoid at a time. What happens if you hit the switch on two slingshots at a time? With only one ball in play, it’s not likely, but with the glass off I tested it anyway.

The switch from one solenoid to the other is nearly simultaneous, and happens at the zero crossing (you’ll have to trust me on this).

To reproduce this behavior, I created a software solenoid stack. If the switches detect a high priority event (like pop bumpers or sling shots), they push solenoid fires to the head of the stack. The game layer pushes things like drop target resets and chimes to the tail of the stack. Because these machines have single ball play, the stack never gets very deep. In order to play melodies on the chimes, I also created a list of timed events that will happen in the future. When those events expire, they push events to the back of the solenoid stack as well. The Arduino pops solenoid events from the stack during the 120Hz ISR and engages the proper lines. This is done at the head of the ISR so the solenoid will be turned off as close to the zero crossing as possible. Here are some solenoid enable/disable waveforms from the Arduino implementation.

Arduino firing Solenoid 0 to ring one of the chimes. Plus a special message from the scope!
Arduino triggering the outhole kicker.
Drop target bank reset for a little more than 120ms.
Pop bumper hit. I guess I could hold it for 5? Seems to work this way, but it’s a few milliseconds shorter than the original M6800 implementation. I might try it for one more cycle.
A slingshot hit.

I didn’t capture back to back solenoid fires, but they switch right at the beginning of the zero crossing signal.

< Back to Lamps.

Continue to Switches. >

Leave a Reply