Bally/Stern Shield and the BallyLib SDK

The SDK provides interrupt service routines to refresh the score displays and lamps, along with a function call interface to read debounced and/or edge-detected switch states, set scores, set lamp states, and fire solenoids (the power-hungry ones are automatically kept mutually exclusive and automatically turned off). I am also willing to share the SDK upon request. I don't post that because I ask my students to replicate some of the interrupt service routine work before I give them the SDK to use for their game play logic.

For playfield switches (things that the ball hits) you can read their raw, debounced, or debounced and edge-detected states either individually or by switch row. Bally and Stern do a good job of organizing switch rows logically, so it is usually most convenient to read an entire row, and then use bit masking to process the individual bits of that row. Note also that edge detection is sticky, meaning that the SDK will retain the fact that a rising edge happened until such time as you get around to reading it, at which time the detection is reset. This means that you don't have to read the switch while the ball is rolling over it in order to catch the event. I use this mode for most of my switch reaction logic, except for capture holes, pop bumpers, and slingshots. For capture holes (like at the top of Mata Hari), the ball may strike the switch and still roll out, in which case you'd rather not strike the solenoid (although it's not really a big deal if you do). For slingshots and pop bumpers you may not have time for the multiple reads required for debounce or edge detection, because the ball may bounce away from the range of the striker. So read the raw state for those and fire the corresponding solenoid ASAP. I have yet to see any spurious solenoid firing from this, and it is better to risk that than to miss striking the ball.

The library does not debounce console switches (like the credit button that adds a player). You'll have to do that yourself in your program (this was actually intentional so that my students would have to deal with it). Bally does this by ensuring there was a low followed by two consecutive high reads. I've always found it sufficient to simply detect a low followed by a high. Technically this is a rising edge detection, which is generally what you want. For example, if you simply debounced the high state, then the machine would keep adding players while the button is held in. So it is a transition from low to high that you want to detect there.

LICENSE TERMS

These works are released under GNU GPL, as detailed at http://www.gnu.org/copyleft/gpl.html.

Please respect my wishes in having released them this way. See the GPL website for details, but in particular please note that ...

1) I retain copyright in this work, I am providing you with a GPL license so that you can use, modify, and redistribute it.

2) I am providing my software and hardware design files to you for free, and expect any redistribution by you to do likewise. Producing boards from my PCB layout for personal use is fine, but producing them to sell for profit would violate this license. The bottom line is: do not attempt to profit from my work.

3) You may thus redistribute these works verbatim, and may distribute modifications of these works, as long as your distribution is also released under GPL and contains prominent notices of that. Your distribution must also carry prominent notices stating that you modified it, giving a relevant date (month and year is fine), and retain prior notices. This means that prior contributors to the work (e.g., mine) must be retained. For the SDK source, such notifications should go near the top of the source files. For the schematic, such annotations can go on the last page. For the PCB, you'll have to squeeze your name and date onto the silkscreen layer somewhere.