Virtual Driver

The virtual driver simulates every pinball hardware device in memory. It is a complete drop-in replacement for a hardware driver so you can develop and test .cade configurations on any workstation.

Configuration

The virtual driver is configured in a platform block within your Cade configuration file. All properties are optional and control the maximum number of each device type.

platform "virtual" "sim" {
  switch_count = 64
  coil_count   = 32
  light_count  = 128
  servo_count  = 8
}

Properties

Simulated Capabilities

The virtual driver simulates every capability the runtime exposes:

• Switches. State is tracked in memory; every switch starts open.
• Coils. Pulse, enable, and disable commands update in-memory state; pulses complete instantly.
• Lights. Full RGBW and brightness tracking, including batch updates, flash, and fade.
• Flippers. Enable/disable state is tracked per flipper.
• Autofire rules. Enable/disable state is tracked per rule (bumpers, slingshots).
• Servos. Position in degrees is tracked per servo, starting at 0.

Platform Capabilities

Unlike a hardware platform, whose limits are discovered from the boards that are actually attached, the virtual driver reports exactly the counts you configure. Raising switch_count is enough to model a larger machine.

Simulated Behavior

The virtual driver maintains in-memory state for each device type:

• Switches start in the open state. State changes feed the same hardware event pipeline used by physical drivers.
• Coils track energized/de-energized state. Pulse commands complete instantly.
• Lights track full RGBW color values, brightness, and on/off state.
• Flippers and autofire rules track enabled/disabled state.
• Servos track the current position angle in degrees, starting at 0.

What is not simulated

The virtual driver models device state, not device timing. Two consequences are worth knowing before you rely on it:

• Coil pulses have no duration. A pulse is applied and released in the same instant, so a configuration whose pulse timing is wrong on real hardware will still look correct here.
• Flash and fade land immediately. Both are recorded as the final light state, with no blink cycle and no interpolation between the current and target colour. Use the virtual driver to confirm a show reaches the right colours, and hardware or VPX to confirm it looks right.

Everything else — switch-to-score paths, ball lifecycle, enable/disable logic — behaves the same as it does on a physical platform, because switch state changes feed the same event pipeline that hardware drivers use.

Use Cases

• Development without hardware. Build and test game logic on any workstation without a pinball controller connected.
• Automated testing. Drive switch inputs programmatically and verify game behavior in unit and integration tests.
• CI/CD pipelines. Run the full Cade stack in continuous integration environments where no hardware is available.
• Prototyping. Experiment with device configurations, event flows, and game rules before committing to a hardware layout.

Diagnostics

The virtual driver reports the same diagnostics as hardware drivers, so a dashboard or health check that works against a FAST platform works here too:

• Connection status
• Uptime (zero until the driver has been started)
• Events received, commands sent, and an error count
• Counts of configured switches, coils, lights, and servos

The configured counts report devices your configuration actually declares, not the maxima from switch_count and friends — a useful way to catch a device that failed to register.