API for Buddabing's LED Controller

Please note: This API is preliminary.

Initializing the LED controller via LSE calls

If your code is written in C, you can just add some files to your project. The files you will need are: lse.h, buddalse.h, buddasig.h, lse.c, lsedrivr.c, and osd_lse.c.

Here's the code necessary to load the DLL, initialize, and terminate.

#include "lse.h"
#include "buddalse.h"
#include "buddasig.h"

main()
{
   LSE_LightDriverCMD="programname";
   LSE_Initialise();
   LSE_Ext_Initialize(NULL);

   ... DLL is initialized ...

   LSE_Ext_Shutdown();
   LSE_Shutdown();
}

The "programname" has to be set to something that the DLL understands. Currently, programname has to be "MAME", "playanim", or "ledmaker". Additional program names can be added easily in the buddaled source code. It should be safe enough to use "playanim".

The "LSE_Ext_Initialize" and the "LSE_Ext_Shutdown" initialize and shutdown the extensions I created for gl.tter's code. I created the extensions to work around limitations in gl.tter's code. In due time I expect the need for the extensions to go away.

Initializing the Controller Directly: Down and Dirty DLL

TODO: Visual Basic example, Linux and DOS interfaces.

I created the interface to the DLL so that it would work with gl.tter's Light Signal Engine code. Therefore, you can look at the LSE code and get the necessary source code to run the controller. However, I would like to give a more general example in case someone wants to write an executable that does not use the LSE code.

It is not strictly necessary to put the code into a DLL. I suppose I could put it into a library and have users link against it. I may do that in a future version.

In order to talk to the controller through the parallel port under Windows XP, another DLL must be loaded which handles the low level parallel port interface. This is done because the Windows XP and NT kernels do not allow direct access to the parallel port. Fortunately, the authors of Daphne, a videodisk arcade game emulator, have provided this DLL. They include the DLL in their binary package so that users can interface their parallel port based scoreboards to Daphne. The secondary DLL is called par-io.dll.

The DLL which drives the LED controller is loaded just like any other DLL. Here's the C code which will load it: HMODULE dll=NULL; dll=LoadLibrary("buddaled.dll"); if (dll==NULL) { ...error... }

Once the DLL is loaded successfully, you need to get the address of the function which will allow the program to gain access to the DLL. This is done with the Windows GetProcAddress() function: enum builtin_signal; typedef void (*signal_handler) (builtin_signal, const char *, size_t); // light_driver struct - light drivers expose this via 'LightDriverInfo()' struct light_driver { const char *name; unsigned builtfor_mame_major; // Mame version the driver was built for, unsigned builtfor_mame_minor; // eg. 0 . 96 signal_handler handler; // informational data only (could be displayed) unsigned max_light_outputs; unsigned brightness_levels; // stuff only used by on-screen panels such as the 'virtual panel' unsigned char* ui_pixels32; // 32bit, pre-rotated to match 'ui_orientation' // (or NULL if no panel is used) unsigned panel_width; // pre-rotated unsigned panel_height; // " ui_updater ui_update; }; typedef struct light_driver light_driver; typedef const light_driver* (*lightdriverinfo_func) (void); lightdriverinfo_func info_func=NULL; info_func=(lightdriverinfo_func)GetProcAddress(dll,"LightDriverInfo"); if (info_func==NULL) { ...error... }

The only relevant fields to this API are name and handler. Name is used so that the DLL knows what executable is calling it. handler is a function which is called every time the user wishes to access the DLL.

All the typedefs necessary to access the DLL are located in the file lsedrivr.h.

buddabing AT houston DOT rr DOT com.