Abstracted the notion of outputs. A new module, output.c, now controlsall outputs. Each output is tagged with a name; some standardizationeventually needs to happen on these names, but at the moment it'sfully open. The OSD layer can register with output.c to be notifiedwhen outputs change. From there, it is free to do what it wants. LEDshave now been converted to outputs with the name "led0", "led1", etc.[Aaron Giles]

Added support for notifying external clients of changes in outputstates in the Windows OSD system. See windows/output.h for a list ofmessages that external clients can register to receive. Removed thebuilt-in hacky LED support in the Windows OSD layer. Created a sampleapplication ledutil.exe which subscribes to the external events androutes the "led0", "led1", and "led2" outputs to the keyboard LEDsjust like before. If you want to continue to have LED support, simplycopy ledutil.exe into your startup folder and let it run in thebackground. [Aaron Giles]

Modified the Q*Bert driver to signal a "knocker0" output when theknocker is triggered. [Aaron Giles]

This is great news!! I'm sure someone could write an LEDWiz "listener" app, that could drive the LEDwiz. Unfortuntely it still wouldn't provide the functionality that PowerMAME does i.e. attract modes, light up game controls, speech etc

I'm going to send an email to Aaron, asking if he can enhance his new output signalling system to also send out windows messages containing the name of a rom when a rom is executed, and a windows message when the rom is exited, and also a pause/unpause message. That way an LEDWiz listener app could pick up those windows messages, and from the rom name, process the appropriate lighting sequences, and also perform the speech function when pause is pressed etc..