I'm on the plane heading to Chicago now, so here's a brain dump of everything I can think of that maybe you wouldn't think of being newer to the pinball community? Apologies if this shouldn't be in this thread or if I offend with basic things you already know...
For non-standard devices like motors, spinning disks, score reels, moving arms, etc., they are all a bit different but your general assumption is correct.. they're all just combinations of drivers and switches. (At least that's how the are in commerical machines. Home-brew tend to use more steppers and servos... more on that in a bit.)
So the spinning disks are a driver output. Enable that driver, motor is running (with gears in Whirlwind so there are three counter-rotating disks from one driver output). Disable the driver, motor stops. (The disks in whirlwind also have a sand paper like surface, so it would be cool to be able to apply a custom grip property to them.) Many things with motors also have limits switches or positional switches that are just like regular switches, so the logic of knowing the motor position is handled in the game code. Your software just has to know the mechanics of how things move when drivers are turned on and which switches activate in which positions.
For motors that move in two directions, they typically use two drivers. Usually one turns the motor on/off, and one sets the rotation direction (e.g. enabled for cw, disabled for ccw) To fully emulate the hardware for these "toys" in the machines, Pinball Labs would need to have some kind of way to specify what movement happens when a driver is enabled or disabled, and what switches would change states depending on where the motor is.
The same is true for magnets which are just drivers. Your software would have to know when the magnet is on and then affect the ball attraction to it. Also many machines rapidly "pulse" the magnets (via pwm) for less than full strength, so you'd want to watch for that and affect the magnetic pull accordingly.
Newer pinball hardware (like the FAST and P-ROC stuff) also supports stepper motors and servos. Those aren't too complex. A stepper is just a single pulse which represents some fraction of a degree of angle change of the shaft. So your software would need to have an option for how many steps (pulses) per single rotation (400, 800, 1600, etc.) and then it just looks for the pulses and rotates the shaft. These pulses happen fast.. less than 1ms each in some cases. Steppers don't know where they are at any given time, so they usually have home switches which work just like any other pinball switch.
Servos are similar except they (usually) have a fixed angle range (like 180 degrees) and they use pwm to control what absolute position the the shaft is in. For example, 0 = full left, 100% = full right, etc.
Some older pinball hardware (early 90s and before) uses drivers to enable the "quick response" devices. So there might be a single driver output that, when enabled, makes the flippers, slings, and pop bumpers work (and then they respond on their own), and when it's off, the devices don't work. That should be pretty straigtforward to implement though.
Some machines use drivers to activate lights or LEDs which flash in a pattern. For example, in Road Show there are "bridge out" signs above the ramps which have alternating LEDs that flash. So the hardware interface is just a driver enable, and then there's a wig-way board (a physical piece of hardware!) that alternately flashes the LEDs as long as that driver is enabled.
For switches, be sure you can support normally open and normally closed, as optos in pinball machines (which are often used for trough switches and ramps and other hard-to-reach places) are "reversed," in that they are closed when a ball is not there and they open when the ball is there.
Also some switches are proximity switches or hall effect sensors.. the inlanes/outlanes in Williiams Star Trek, the dozer blade in Road show, so you'd want to have some kind of "switch" that is basically where in your game designer you draw a shape in 3D space and say "when the ball is here, this switch is active," (or when the ball is not here).
Some switches are activated when coils or drivers operate. Like in System 11 machines, there's an A-side/C-side select driver which also activates a switch when the driver is active, so it would be cool to be able to tie a switch to a driver. Also some older machines fire the pop bumpers via a switch which is hard-wiring to the coil.. so that is not software controlled, but then the shaft of the solenoid hits a second switch and that's how the machine knows that the pop bumper was hit. (System 11 machines have some other complexities with the A-side/C-side select drivers that you'll have to handle, but we can discuss those details later.
For GI, there are also many different ways those work. Some are regular drivers and some are special GI drivers. Some are dimmable and some are not. But again, that should all be pretty straightforward from your standpoint. It's essentially lots of lights connected to a single driver.
There are many cases where multiple physical lights (both lamp matrix lights and LEDs) are connected to a single output line, so you'd want to be able to support that.
Flashers in pinball machines are controlled like drivers (coils), rather than lights, so make sure you can attach "lights" in Pinball Labs to either driver inputs or lamp inputs.
The only thing to add from the standpoint of an API integration with MPF (or Pyprocgame, PyProcgameHD, etc.) is support for those hardware trigger "rules" I mentioned in my other super long post. I will put together a more detailed spec (after Expo), but essentially you just need to be able to have your code handle simple rules that the API writes, like "when switch X is hit, pulse driver Y for Z ms." Then you handle the pulsing of the driver when that happens instead of the controlling software (though you also still report the switch event back to the API so it can do scoring or effects or whatever.)
For score reels, yep, they're just regular drivers attached to solenoids (well, the old EM ones are). One pulse = one position advancement, and there are switches that let the machine know which position it's in. (Not all positions have switches.) New score reels (like in Whoa Nellie) are stepper motors with home switches.
For a classic single color DMDs, there were 1-bit (2 color, on/off), 2-bit (4-shade, most Williams/Bally/WPC games), and 4-bit (16 shades, modern Stern). Most of the displays were/are 128x32, but there were some odd sizes here and there (128x16, 128x64, etc.). So you should let the designer specify the size of the DMD, the number of dots, the number of shades, the bright color, the "off" color, etc. Then the API should accept a byte array (or something similar) with 1 byte per dot. So a 128x32 DMD = 4096 dots = 4096 bytes. So the API could receive a 4096-byte array, and the low bits of each byte control the brightness of the pixel, and each time it receives a new array then it updates the screen.
In the original WPC ROMs, the brightness of the dots was controlled via two separate "bit planes".. One was shown 1/3 of the time and one was shown 2/3 of the time, so if a pixel was "on" in both planes it was 100% brightness. If it was on in just one plane it was either 66% or 33% brightness, and if it was off in both then it was off. I don't know anything about how PinMAME works, but if it's using the oringal ROMs then that bit plane splitting logic has to exist somewhere. (But maybe PinMAME handles that and can just send you a single byte per pixel like MPF or Pyprocgame.) Modern Stern machines with 16 shades us the bit plane as well, except they have 4 planes instead of 3.
Color DMDs are pretty much the same, except like I said they're 3 bytes per pixel. No existing machines support them built-in, so being able to receive 3 bytes per pixel should handle all situations.
Very modern machines like Wizard of Oz, The Big Lewbowski, The Hobbit, and MPF using our Unity 3D-based backbox option have full color LCDs in the backbox (operating at either 720p or 1080p). For virtual pinball cabs, the pinball controller software could just "own" the LCD window in the backbox. For VR, I dunno.. maybe there's some way to accept a video stream or something from the pinball software to show those displays? That is probably also something you don't have to worry about for now.
For the ultimate realism, it would be cool to track the x/y position of the ball at all times and then show playfield wear over time. And rubbers things wear out and break too. ...I'm kidding about this, though it would be a kind of crazy and/or fun thing to try. But not in v1. 
Finally, for the next trivia answer, the "Why is the CPU board called an MPU in pinball machines?" is a good question. It stands for "Microprocessor Unit", and it comes from the late 70s when Bally started experimenting with electronic control instead of EM. In those days, a microprocessor was a new concept and I don't think the term "CPU" was invented yet, so the board that contained it was called an MPU. (This is also what Williams and Gottlieb called theirs in the early days too.) What's kind of funny about this is that the "official" term died off a long time ago. By the System 11 days (late 80s), Williams started referring to that board as the "CPU board" (which is what you'd think it'd be called today), but the pinball community was used to calling them "MPU" and that name just sort of stuck even though it hasn't officially been used in 30 years.
Top
Contributor
are all trademarks of VPFORUMS.