The P-ROC can automatically scan direct, matrix, and burst switches and notify software and/or change the state of a driver when a switch changes states. This allows software to spend its cycles processing game rules rather than implementing very high speed switch scan loops.
Direct and Matrix Switches
The P-ROC has 32 direct switch inputs, and it has 10 switch column drivers and 16 switch row inputs creating a 160 switch switch matrix. The first 8 switch column drivers have dedicated outputs driven through a ULN2803 transistor array, and the other 2 are driven on an 8-bit multiplexed data bus (for WPC machines to use 8-driver boards). The 16 switch row inputs are dedicated inputs, each going through an LM339 comparator that compares the row's voltage against a 2.5V or 6V reference voltage.
Every x milliseconds, the P-ROC goes through a scanning loop during which it first checks all of the direct inputs. It then iterates through the matrix by driving a column and checking the row inputs, then driving the next column and checking the row inputs, etc. The number of milliseconds between each full scanning loop is programmable down to 1 millisecond.
The P-ROC has 32 burst switch outputs (each with two outputs) and 64 burst switch inputs. These are provided for switches, such as long range infrared emitter/detector pairs, that require bursts of activity to function correctly. The timing parameters of the burst activity are fully programmable (globally) so that it can work with many types of switches. The programmable timing parameters determine how long it takes to cycle through all of the burst switches.
While scanning the switches, the P-ROC recognizes when the state of a switch changes. States include:
- Open, non-debounced
- Open, debounced
- Closed, non-debounced
- Closed, debounced
The P-ROC can be programmed to perform specific actions for each state change for each of the 256 switches. Actions include:
- Notify software
- Change a driver's configuration
For increased flexibility, the P-ROC can chain multiple actions together so that more than one action can occur as a result of a switch's state changing. For instance, switch 3 can cause drivers 5, 10, and 20 to turn on, drivers 30-35 to be turned off, and software to be notified when its state becomes closed, debounced. (Crazy example, but possible). It can also have a different set of actions occur when its state becomes one of the other 3 states, such as open, debounced.
In typical applications, users will likely want to simply notify the host of all debounced switch events (for scoring and rule processing). For situations requiring immediate driver reactions, such as pop bumpers popping in response to a pop bumper switch closing, a driver rule might also be used.