MAMEInterop SDK v1.3 Released for Developers

[headkaze]

https://www.baker76.com/mameinterop-sdk

[loadman]

Nice work 

Will be sure at this to the upcoming Mala LedWiz V2 plugin 

and I'm sure other FE/Plug-in Devs will support this

It can only be a good thing to and more authenticity to some games in various ways

I encorage anyone with the appropriate knowledge to dig a little deeper than 'Dig Dug' going forward   

[Havok]

Nice work - this has a lot of potential...

 

[2600]

This certainly makes things easier.

Also add Q-bert to the list.

headkaze, I've noticed you've asked for source code for dll's quite a few times. 
Any chance you are going to post the source code for your dll?

[edge]

Nice job guys.   

Opens up so many possibilties.

[headkaze]

This certainly makes things easier.

Also add Q-bert to the list.

headkaze, I've noticed you've asked for source code for dll's quite a few times. 
Any chance you are going to post the source code for your dll?

I've only ever asked for the source code to the ledwiz.dll because MikeQ stopped developing PowerMame. I don't know what you mean by a few times other than that.

I'm not going to release the source code for Mame.dll, but Howard will have a copy incase I fall of the face of the Earth so updates can continue. The reason is I want any problems or bugs for the dll to be reported to me so I can make the update to the dll and release a new version of the SDK. That way everyone will get the fix. There is the likelyhood that I release the dll source code and someone will make changes or fixes and not let me know. This way there is a central place and everyone can benefit from any improvements. That being said if you really need the source you can PM me in private.

There are two versions of the dll BTW, one for VB6 and one for the other languages. I wrote a separate one for VB6 because I wanted it to be easy to use, so I did all the Unicode conversions of the strings in the dll before sending them to the host application.

I didn't miss QBert, if you take a look at the readme.txt included in the archive I have a full list of ROMs and the supported outputs.

[headkaze]

I just realised that gorf isn't listed as having lamp outputs but it does. The lists I have are probably innacurate I just went through each driver searching for outputs, then put them into a small util to output ROM names that use the same source file. So there are probably ROMs missing from the list, sorry about that.

[Howard_Casto]

Ok I guess we are greenlit then. 

Just wanted to make a statement to go along with keadkaze's:

First off I have no clue why I got so much credit.  Other than pestering Aaron to finally add output support I didn't do much.  Remember kids, sometimes pitty can work for you. 

The dll implementation hk did is no small thing.  While setting up the mame connection via code isn't impossible (I managed to do it, so it couldn't be THAT hard.), it does require rather hi-level coding ability.  This kit means that anybody that can write a ledwiz app or something to that degree is going to be able to handle communcations with mame.  Heck, we found out via trial and error that the communcation method out-right doesn't work in vb, so a dll written in C was pretty much required for that. 


I've been volunteered to kind of keep track of the project.  While not as involving as say, controls.dat, it's still going to be some work.  In the next couple of weeks I'll be releasing an app based on our example source that will be used both to retrieve outputs from mame and write ini files based on those outputs ... oh it'll do stuff with em too. 

The sdk is the main thing, and it's essentially done, but there are some further steps I want to do as sort of a supplement.  First off, because we are sometimes dealing with "dangerous" output devices like solenoids, we want each individual game to have a config file.  That doesn't mean there won't be a default file to set most of your games, but we want to make sure that the qbert knocker isn't used as a light in other games, for example or else the solenoid would get burned out.  I'm going to write a standardized file for this.  It's going to be very short, sweet, and to the point.  My app will make them automatically when a game is ran, taking care of 90% of the output games.  There are games, however which have a jumble of dozens of outputs, which we will need to go into and comment about the different ones.  Turbo comes to mind, it has something like 40 outputs!!!

As for what to do with the outputs....  we want to standardize that as well.  Nothing complex, it's just that, let's say the user wants to bind the first coin light to the first output on their ledwiz.  We want to have a certain syntax to write turning on that output to be used in the ini file.  We want to try to use that same syntax for every application any of us make, so again, it'll make things easier on the user.  Again, this isn't going to be anything overly complex, I'll make it nice and to the point. I'll also post ideas about it right here.  I want us to all generally agree upon this stuff. 

Lastly, my app is going to be open source, just like the examples.  I WANT people to add new stuff to it.  I WANT it to be ported to other languages.  Think of this as a mini-mame dev situation.  I want to see the app on linux, macos x ect.... I'm gonna do it in vb because I can code it quicker, but it'd be nice if we could get some people to head up a C build and pretty much a build for every langauge we've talked about.   Of course, if you have a C build then pretty much anything can be done with it porting-wise. 

About dlls and stuff.  Neither of us have any problems with close-source dlls, however, if you want "output device x" to be supported in the sdk and in my app, you need to get somebody to explain the interface and post us some examples, or better yet have them do it and release the source. 

Right now, this is what I, personally intend to add:

parallel port outputs
ledwiz outputs
keyboard leds (maybe not, as they are rather useless and you can use the ledutil for them). 
wiimote outputs (rumble, leds and sound)
Force feedback (via directx)

If anybody wants something else added they'll need to help out.


I want to also add serial port support but I'm rather dumb about serial communication so I would need help.  On top of that we want it to be generic enough to allow for different hardware interfaces (for example I'll handle the parallel interface via allowing direct data communication, not as a "turn on pin 1" function). 

Thats it for now, watch this space carefully in the upcoming days, and developers/users that want to help out please either post here or contact one of us privately. 

Also remember to thank Aaron and hk when you get the chance. 

[Howard_Casto]

Ok guys, my app has the ability to write ini files now.
Since digdug is fairly simple, I'll post the ini here and explain the format and what is going on.

digdug.ini

Code: [Select]

[Output]
led0=
led1=
[Id2String]
12346=led0
12345=led1

That's it?  Yep pretty much.  First let me explain what is going on.  See mame sends you a state update when an output changes, but it doesn't send the name of the output, rather it sends a id number.  In this case 12346(led0) and 12345(led1).  Once the first change has occured, you can send the id number back to mame and it'll give you the real name, in this case led0 and led1.  When you constantly call for the name it slows things down, so we setup a buffer (as seen in the sdk examples).  The id2String section of the ini file takes things one step further by saving the number/string relationship so that it never has to be called again.  So basically this section helps out developers and users should never have to bother with it. 

Now the [Output] section above it would be where we bind the outputs to devices, like the ledwiz.  You'll note they are blank.  When the app makes an ini it sets up all the options, but it doesn't fill in the values.  This is for safety reasons. 


Now since it'd be a real pain in the butt to setup each individual game's outputs, we also have a default file.

default.ini

Code: [Select]

[Output]
led0=lw 1 1
led1=lw 1 2
led2=lw 1 3
led3=lw 1 4


Note there isn't an id2string section as id numbers are unique to each game.  I put led0-led4 as examples because these are the coin lights for mame 90% of the time.  The commands I binded them to are fictional, but as you can see setting up mame to liight the coin lights would be fairly trivial.  The app automatically sets up blank entries for outputs in the defualt.ini, so the user doesn't have to guess what is available to them.  I might set this up as an option though as your default.ini gets filled up fairly quickly, turbo, for example, has 35 outputs!!!


I don't want to clutter things up, so in my next post I'll explain the proposed command structure.

[Howard_Casto]

Ok now for the commands you can bind the outputs to. 

I don't want to get into specific commands, but rather how I would like to see them structured. 


Commands will be in this format:

device/function name port#/device# data

So giving a completely made-up example, to bind the first pin of the first ledwiz to led0 you would type.

Code: [Select]

led0=lw 1 1 %s%
"lw" is the name I made up to represent a ledwiz, 1 represents the first out 16 possible ledwizzes, the second 1 represents the first output pin and %s% represents the state data.  See with this we can switch it on and off with the same command  as %s% will be either 0 or 1. 

You might want to use a rgb led though and this would require dedicated on and off states and multiple calls to set the three pins.  Well we can do that by expanding upon the output command.

To just throw out and example:

Code: [Select]

led0=lwc 1 1 48,lwc 1 2 0,lwc 1 3 0|lwc 1 1 48, lwc 1 2 48, lwc 1 3 48
Ok this is going to have the led be red (48,0,0) when it's off and white(48,48,48) when it's on. 
Note the lwc command, again this is fictional, but we'd want to set the intensity, not just turn the led on and off.  There are three off commands, seperated by commas, followed by a seperator bar and the three on commands.  So basically the app would split the commands by "|" and each slot would be for that value.  In this case we have the value 0 (stuff to the left of the bar) and value 1 (stuff to the right of the bar.)

There are instances where a output can be more than 0 or 1, in those instances we can just add more bars and more commands. 

It's a little complicated, but for simple stuff like turning on and off lights it'll be easy.  Also remember that this is just what we PRINT to the ini file, so anybody can jump in and make a nice gui where you can make things more user friendly. 

Some notes about the physical syntax:

Each part of the command is seperated by a single space.
There are no brackets or groupings allowed (this will speed up parse time)
Obviously commands can't contain commas or bars, as they are used for grouping.

Again I want to keep this neat so I can edit later, in the next post I'll explain some optional "extra" additions to the ini format.

[Howard_Casto]

Ok looking back at our ini example from a post ago. 

digdug.ini

Code: [Select]

[Output]
led0=
led1=
[Id2String]
12346=led0
12345=led1


Ok that is gonna do ya 90% of the time, but you might need some setup and shutdown commands depending upon the interface. 

for that we manually add:

Code: [Select]

[General]
onstart=
onstop=
onchange=
[Output]
led0=
led1=
[Id2String]
12346=led0
12345=led1


So we've now got a general section with "onstart" "onstop" and "onchange".  In these three entries you can put any command you would normally put in regular output entries.  Obviously onstart is called whenever the game starts and onstop when the game exits. 


The entry "onchange", however, is more of a future-proofing thing.  On change will be sent whenever ANY output in the game changes it's state.  Why would this be useful?  Mame has quite a few games with segmented displays.  Usually they are in mame as individual digits, rather that the whole scoreboard.  Since interfaces with a segmented display on the pc generally communicate via a line of text, implementation of communicating with these displays would require buffering.  Basically you'd change the individual digit by updating the buffer on an individual output change and after ANY change you'd print the entire buffer (every output) to the device.  So basically it's just there in case we need it later on. 

Again these are put in manually and seldom if ever used.  Unless you have some funky hardware you want to use you'll never have to worry about those.

Alright, that's all I have for now, questions, comments or suggestions would be appreciated before I finalize everything.

[headkaze]

I'm just curious if an ini file is necessary at all. Since weve added in name caching we only have to call the get_name_from_id function once to get a name from a new id. Will there realy be a noticeable slowdown using the current method without an ini file? The ini file will certainly help by being able to lookup exactly what outputs a game has though.

I still prefer having one big ini file for the lot, but this is okay

BTW The output system in Mame wouldn't exist without you, and neither would MameInterop so I don't think there is any more credit than credit is due.

[Howard_Casto]

It's not necessary, but it's helpful. 

Let's say you want to turn all the lights off on startup.  Well you don't know what lights are available unless you have an ini with all the outputs. 

Turbo is particularly taxing on the system.  The game drops to about 5-10 fps for the first minute or so while all the names are being polled.  That is a worst case scenario though.  I've yet to run into another game with more than 5 or 6 outputs. 

[2600]

I'd recommend not putting the id in an ini file like that.  It's possible that the id could change between releases.

[Howard_Casto]

If it changes between releases then the application will note a new id number and fix it.  It is extremely unlikely that the id numbers would ever change anyway because they don't have to be in any particular order.  If a new output is found then it'd just be tacked on by the developer unless some major cleanup takes place, which I don't see happening. 

[Howard_Casto]

Ok I've started implementing commands and here is what I came up with. 

First off, our device string will only be three characters long... this just makes for quick parsing and I figure if operating system file extensions can get away with only three characters, why not us?

I went ahead and started with the led wiz.

The first command is "lwp" and it does exactly what the command does with the ledwiz script syntax, set the power level of the output. 

The format is lwp device# output# intensity

So an example would be:

"lwp 1 01 48"  which would set the intensity of output 1 on ledwiz 1 to 48

Also we have "lws" which sets the on/off state, again just like in ledwiz scripts.

The fomat is lws device# output# state.

An example would be:

"lws 1 01 %s%" which would set the on/off state to the current on/off state of whatever mame output it's binded to.

Finally we have "lwc" (ledwiz colors) which stands for the rgb command in ledwiz scripts.

The format is lwc device# starting_output# R_intensity G_intensity B_intensity.

So an example would be:

"lwc 1 01 48 0 0" which would turn the rgb led hooked to outputs 1 2 and 3 red.

So to recap we have:

lwp=ledwiz power level
lws=ledwiz on/off state
lwc=ledwiz rgb state/color

I'm doing different ledwiz functions as seperate "devices" because the syntax required to set these commands all involve commas, which aren't allowed.  I really don't have any plans to add bank/all output support, but once I release the program somebody else can add em as the function is fairly straight forward.

Future commands I'm working on:

lpt=raw lpt communication.... send the port number followed by raw data you want sent to the pins.

lpe=easy lpt communication... send the port number followed by the data pin you wish to turn on/off

ser=serial communication... I won't implement this personally, but I can leave a space in the function and reserve the key name

wii=wiimote communication... won't be implemented for some time, but drivers/apis are finally popping up.

dff=direct-input force feedback.. send the controller id# followed by the motor# and the state.  Mame doesn't do anything complicated with force feedback, so simple on/off pulses should do.  Things like mapping and recorded actions won't be supported.  (Or at least I won't implement it myself). 

p.s. I'm considering removing the id recording since everyone seems to be so against it.  Also all of the multiple commands per state change and different commands for different states stuff is in place and working fine.  As a test I setup my start buttons to be white when "off" and red when "on".  The ledwiz ocx seemed a little slow keeping up (I'll be switching to a dll soon hopefully.) but the actual functions worked perfectly. 

[loadman]

I might just add the dig dug stuff my own way for now (just for fun)

But I will jump on board with this later

[Howard_Casto]

I looked into force feedback support yesterday....

Apparently you have to create an effect before you can send any data.  That's a real pain in the butt because it means you have to initalize the effect upon startup.  Because of this I'll probably take back what I said about force feedback and allow users to define effects.  I'll just look for effect files in a folder and load either an default effect file or one named after the rom.  They aren't hard to make if you download the m$ force feedback tool.  Also something that might be useful I forgot about is the ability to bind a button to an effect in di.  Terminator 2's recoil, for example is partiall mechanical.  I believe how it works is the gun itself has a board that controls the ratcheting recoil and the board just turns it on/off instead of rapidly firing the board.  So the effect could be binded to the fire button upon startup and then muted via the state (assuming someone ever hooks up the mame river.)

I'll probably go ahead and hookup the parallel port functions as they are a breeze to do.  Force feedback might take all week. 

[Howard_Casto]

Ok I started implementation of force feedback.  It's a real pain in the butt.

You can only access force feedback actuators if you aquire the device in exclusive mode.  Which means that mame can't access the device.  I'm working on a work-around though.  Regardless of this, the force feedback does indeed work.  I just setup a generic constant rumble that is loaded upon mame_start to any force feedback devices. 

the format as-is is

dff joystick# #state #duration of effect. 

I had to add duration, becuase if you want to use the rumble motor in place of a solenoid, mame turns it on and off far too quickly for you to feel anything.  Also since setting it up with the %s% flag would turn it off immediately regardless of the duration the user sets, I had to resort to some trickery. 

we now also have the function:

nll

which is a blank function that doesn't do anything. 

So for a game with a knocker that you want to use a rumble motor for, you can set the script for off to nothing, and the script for on to a rumble with a duration. 

The script for qbert I made looks like this, for example:

knocker0=nll |dff 1 1 50

So when the knocker is off it doesn't do anything and when it is on it fires a 50 millisecond rumble on device 1. 


It works fairly well, but obviously there are still a lot of things to sort out. 

I'll also add a fff (force feedback from file) command as it's fairly easy to implement now the the basic structure is in place. 

I still need to figure out a good way to initalize the force feedback stuff.  Probably the fastest way would be to allow the user to set it manually with the "onstart" entry in the ini file.  That'd definately need a wizard of some sorts though because it's complicated for the average user to do. 


I'll still add the lpt stuff tomorrow... it's easy.

[Howard_Casto]

Ok, I've thankfully figured out the force feedback exclusive mode issue.

Apparently two different applications CAN both have a joystick in exclusive mode.  Unfortunately, when mame starts up, if the game uses a joystick it "unbinds" all joysticks with it's own joystick init.  The solution to our problem was farly simple.  Instead of starting up my force feedback code upon mame start, I start it upon the first state change that uses force feedback.  It works flawlessly.  I can control the rumble motors and mame can still use the controls on the joystick.

So forcefeedback, the long sought after feature for mame, will be a reality!!! 

I still have some cleanup code to do, but that was the only major hurdle in this project.  Expect a test release sometime this weekend followed by a release of the source code if no major bugs are found.

[headkaze]

Nice work Howard, good to see some practical uses for the output system being implemented. BTW How do you know which joystick to send the FF to, or do the output numbers make that clear?

[Howard_Casto]

Well it's just like oldschool 9x programming....

You open up gamepads in the control panel.  Whatever order the gamepads are in is the id number, starting with 0.  When the user wants to fire up a certain pad you just send that joysticks id number.  Of course there are all kinds of checks/error handling in place to make sure the joystick specified actually exists and actually has a rumble motor.  Now I could have went with using the guid (internal device name) but it leads to issues if you have multiple pads of the same type, which most people will have.  Since you'd need to know the guid and the idnumber, it kind of defeats the purpose. 


So basically the same crappy way mame does it.  It sucks because if you re-arrange gamepads then it'll effect your scripts.  I don't think it's a big deal though because if it is sent to the wrong stick the worst that can happen is.. well nothing.

I've went ahead and made the application into a proper taskbar app.  It has a little over 6100k of a footprint and uses 0.0% of the processor when in idle mode so I think it'll be fine for just throwing a shortcut in the startup folder and leaving it on all the time.  With more efficient code I could probably get that footprint down a little, but considering I still haven't added all the functions in, it'll average out the same. 

[Howard_Casto]

Ok, I swiped my j5 output code and now we have three more devices/functions.

lpe port# pin# state

Which is the "easy mode" lpt interface.  You can straight wire up to 8 leds to the parallel port's 8 data pins.  This function allows you to set the state of an individual pin.  The port number can be 1 or 2, representing lpt1 and lpt2.  So if you can hunt up a cheap parallel port card to add a second port you have 16 "free" inputs.  No fancy 40 dollar device necessary!

lpt port# data

Which is the "hard mode" lpt interface.  It's intended as a stop-gap in case somebody comes out with some crazy parallel-port driven interface.  (I know a few already exist.)  You can send raw integer data (remember to convert first!) to the parallel port of your choice. 

Also we have:

kbd key# state

This sets the keyboard leds by pressing the appropriate key.  The key number can be 1-3.  1 is numlock, 2 is caps lock and 3 is scroll lock.  Unlike mame, my function actually checks to see the current state of the keys, instead of randomly pressing the keys, hoping they'll stay in sync.  So you can be assured that setting capslock to 1 will actually light capslock, and not turn it off if it is already on.  My method is only 1 of the 3 used in ledutil.  If you needed the other methods to work, sorry for your luck as they aren't very efficient and I can't get the current light state from them.  This one is more "primative" but it tends to get the job done regardless of if you are on 9x/xp and if you have a usb or ps2 keyboard. 

We are getting close as most of the functions I wanted to implement are in place. 

I need to add code to read the onstart/onstop/onchange ini entires and do a ton of cleanup, but things are on track. 

I'll look into wiimote support tomorrow. I know a c++ dll has been released, but I don't know how well it handles the rumble motor and leds.  Speaker support would be nice as well.  There's this game called Dragon gun where the guns had speakers on them and they talked to you!  It'd be nice if some helpful mame dev could add the option to pump that data through the output system so I could pump it into a wiimote. 

[Howard_Casto]

Ok, I added support for the "MameStart" "MameStop" and "StateChange" entries. 

They are actually quite handy, even for non-advanced use.  I have the ledwiz hooked up to my start buttons (and nothing else atm), for example.  I put commands in the MAMESTART to turn them white, so they light up even if the game doesn't have coin lights.  I don't want them burning all the time though, so I put in commands to turn them off in MAMESTOP.  Works really well.  I haven't tested statechange, but it should work well as well. 

I also went ahead and implemented some buffers for advanced useage. 

There are 10, text-based buffers you can access via script. 

You have:

sbf buffer# text

That allows you to initially set the buffer up with a template.  It can be of any length, but can't have commas or spaces.  I understood that spaces would be important though, so you can use underscores and they will be converted internally. 

Now that in of itself isn't particularly useful, but you also have:

ibf buffer# position character

This lets to replace a single character in your already setup buffer with something else.  This can include the current state using the "%s%" flag for the character entry. 

You can send buffer data to any other command, by using "%b1%" through "%b10%" in the scripts.  So if the advanced parallel port communication needs a buffer now you have one. 


Also if someone wants to add text-based lcd support, we now have a way to take all the individual states and put them into a text string, which could be sent to the device on state change. 

Again, pretty advanced stuff that most people aren't going to use, but it ensures some future-proofing of the application.

p.s.  wiimote support isn't looking good.  The current methods to interact don't have good error handling and I don't want to add code that'll crash the app if the wiimote isn't present.  So it'll wait for now.  I could add a function to press keys and then a user could use something like glovepie to bind those keys to rumble/leds on the wiimotes.  It's kind of hackish though so I'll have to think on it.

[Howard_Casto]

Ok I caved.....

id2string is gone.  I hadn't hooked it up yet (it just writes it atm, doesn't read it) and I haven't noticed any real speed issues, so there isn't any point in wasting time setting it up.  It'll make the ini files smaller too.

I think I will make the general options auto-generate though as they seem to be pretty handy.  (See above.) 


I'm still on schedule for a weekend test release. 

In the mean-time can anyone help me with the following:

I need a copy of m$'s force feedback effect tool.  I can't seem to find it on msdn anymore.

I would like some details on adding support for those text-based lcds that generally run on the parallel/serial port.  I used to code for them, but it's been a while.  I just need a solution that'll work in xp.

What about other devices?  I haven't heard anyone chime in to say "please support device x" yet.  As far as light controls go, I've only added support for the ledwiz.  I know there are others out there.

[youki]

What about other devices?  I haven't heard anyone chime in to say "please support device x" yet.  As far as light controls go, I've only added support for the ledwiz.  I know there are others out there.

Mala hardware?

[Howard_Casto]

Well yeah, that's one, but I don't know it's official name, nor do I have a dll or anything to interface with it. 

I know there was a parallel port based one that somebody did ages ago.  And there's the pinmame hardware interface, which could be used as well (I can probably find info on that one.)

[Buddabing]

For the parallel port interface keep in mind:

1) The parallel port under XP is protected and just writing to the port doesn't do anything. There's a special DLL that the Daphne devs wrote for a Dragon's Lair scoreboard that uses the the parallel port that "unlocks it".

2) You may need to send several values to the parallel port for each event.

[Howard_Casto]

For the parallel port interface keep in mind:

1) The parallel port under XP is protected and just writing to the port doesn't do anything. There's a special DLL that the Daphne devs wrote for a Dragon's Lair scoreboard that uses the the parallel port that "unlocks it".

2) You may need to send several values to the parallel port for each event.

I use inpout32.dll for the parallel port, which works in xp.  As I said above I've setup buffers which can be used to store data and then once the data has been built it can be sent to the parallel port.  Ragardless, the scripting system allows for multiple events to be fired upon each script change.


Come on now man, this is me we're talking about.  I don't make rookie mistakes like that. 

[Howard_Casto]

Looking back, that response might have came off as me being rude.  I didn't mean it that way, sorry Budda.


Didn't you make one of said "crazy parallel port interfaces"?  Parallel port communication is in place already, send me some specs and I can add dedicated functions for it. 

I did some testing on the buffers to make sure they are working properly.  So far so good. 

I'd really like to add support for text-based lcds though.  I'll see if I can look into that.  It's suprising how many games had segmented displays and how many aaron has implemented.  There might be a use for those ugly things afterall. 


I was thinking about serial communication and what might be useful (besides the obvious) and I thought perhaps sending files via the port might be a good idea.  Everybody wants to magically build a secondary display out of an old laptop and while that isn't possible, it is possible to setup a tiny app that you can send pictures to via serial com.  Marquees, ranks lights, ect could be controlled and sent through the port.  It seems like a lot of work though, so I don't see it happening before this weekend. 

[Buddabing]

Yes, I designed a board that uses a crazy parallel port interface. If it will work with this SDK that'll be one less thing I have to worry about.

And you weren't being rude, you were being Howard.

[headkaze]

I have written a dll called CommIO.dll that allows you to communicate to the com port. E-mail me if your interested  Howard. It should cover any com port communication necessary.

[Howard_Casto]

Yeah, I'll get in contact with you both later this weekend. 

In the meantime, I've noticed a few mame-related bugs I want to make note of publically incase I lose my notes. 

Prop Cycle (propcycl) has it's outputs hooked up backwards.  Led0 should be Fan0 and vice-versa

Atari basketball(bsktball) has something odd mangled in with the led0 output.  It appears both in the ledutil and in the sdk debug to be solid on upon bootup, but it's actually modulating on and off at an incredibly fast speed.  It ends up filling the window message buffer with calls and crashing any program trying to do anything more than read the state.  I know this to be an error because led0 is player 1 start light, so why would it be blinking if no coins are inserted?  And if it is supposed to be blinking why wasn't player 2 start blinking? Blocking off led0 makes player 2 start (led1) behave normally, so the problem is isolated to that output.

Those are it so far.  I think the reason they were never caught is because we are the first to actually do anything with the outputs. 

[Howard_Casto]

I exerimented with something a little out there today. 

I made a dual screen test app that'll let you put mame-style artwork files (that are controlled by the outputs of course) on a second screen.  It's real rough and basic, laid out almost exactly like mame's artwork system.  They'll be a function to load a DIS (display) file at a user specified position on the screen(s) and then a function to turn various images in the file on and off.  I can't see this being incredibly useful as most games with scoreboards are vertical (and thus have the lights in the cropped bezel) but hey you never know.  Also I'm told mame recently added support for games without displays.  Maybe this might be handy for that?

This won't make it into tomorrow's release, but I thought I would mention it. 

[loadman]

What about other devices?  I haven't heard anyone chime in to say "please support device x" yet.  As far as light controls go, I've only added support for the ledwiz.  I know there are others out there.

Mala hardware?

Posted by: Howard_Casto  Posted on: Yesterday at 07:59:04 
Insert Quote 
Well yeah, that's one, but I don't know it's official name, nor do I have a dll or anything to interface with it.   

That would be cool for me as I use that.

It is basically a IO-Warrior 40 with 32 Pins.

Other users have put this chip in a Led-Wiz which effectively makes it act the same as mala hardware

I have written code for it myself.. Pretty easy.

There is a SDK it contains the iowkit.dll and all files needed for access with C/C++, Delphi, Visual Basic 6 or Visual Basic .net.
The source for the DLL is provided as "Visual Studio 2005" project.

http://www.codemercs.com/Downloads/SDK.zip

[Howard_Casto]

You are going to have to find me more than that.  For a sdk, there is very little documentation. 

Granted there's a simple io example I can look at to figure out how to operate leds, but it doesn't tell me the possible values or anything. 

Also a compiled version of the dll would be nice.  I haven't re-installed 2k5 yet. 

[loadman]

You are going to have to find me more than that.  For a sdk, there is very little documentation. 

Granted there's a simple io example I can look at to figure out how to operate leds, but it doesn't tell me the possible values or anything. 

Also a compiled version of the dll would be nice.  I haven't re-installed 2k5 yet. 

No Worries...  I'll get on it

EDIT:

There is a compiled version of the dll pakaged with the SDK. I only mentioned that you could get the source for DLL in case you wanted to look at it. I will post a link to what you need

[headkaze]

Those are it so far.  I think the reason they were never caught is because we are the first to actually do anything with the outputs. 

It's nice pioneering into the unknown. I added basic MameInterop support to my LEDWiz plugin a little while ago (only led0 and led1 support so far). It will be interesting to see what else can be done with this. I'm looking forward to see what you've come up with Howard, although it will be in VB6 no doubt.

I've also talked to Randy about writing a global solution for controlling the LEDWiz (using a server type app along with Mike's ledwiz.dll). Basically like what has been done with MameInterop but for the LEDWiz. I'm not sure I'll find the time, but if I do I will do a sort of LEDWiz SDK for the scene. I guess it depends alot though since 3 FE's have added proprietry support for the LEDWiz, so I'm not sure if it's necessary. What do you think about using Windows Messaging for controlling a LEDWiz basically like how Mame's output system works? Do you think it will be fast enough for LEDWiz output? It would have been nice to come up with a global solution before all the FE's did their own thing.

Also a compiled version of the dll would be nice.  I haven't re-installed 2k5 yet. 

Time to install Vistual Studio Express 2005 methinks

[Howard_Casto]

Well I know nobody wants to hear what I think, but imho adding internalized support for the ledwiz in a fe is rather stupid and useless.  All it does is add more things to maintain when the same thing could be accomplished via command line calls.  Whenver randy updates the dll/ocx all the users are sitting on their hands until the fe dev gets around to updating the code. Also what exactly would you do with it fe-wise? Granted I know that most people  use their ledwizzes for nothing more than a way to light up their cp buttons with some blinky effects, but I can sell em 5 bucks worth of kit that'll do that and it wouldn't even have to be hooked up to a computer.

Where it's at is lighting up different color-coded layouts (like j5 and the other cp viewers) and messing with mame's outputs as then you are actually doing something useful with the ability to control multiple lights/motors/ect on the fly.

The only thing a fe can do really is use animations for when idle in the fe and various transition effects.  That's all well and good, but the can be done with a simple call to the command line utility.  Or better yet, a command line app that isn't dependant upon the ledwiz software.

Really the fe's with built in support need to take it out in leu of a more generic solution.  I'm not trying to tell anybody how to code, but when you do a big project like a fe, you want to use as few dlls as possible as it just bloats your code and just makes it more complicated to manage.  After 4 years the dk beta now has a whole two dlls and it's driving me crazy because I can't get rid of them.  I wonder about people that don't bat an eye at using 10 or 20. 

I'm throwing all these dlls, ect in this hooking app so that I don't have to elsewhere.  It's going to be a god-awful mess dll wize, but it'll be worth it because this app is nothing but dlls, so there's not really any code to bloat. 


But enough ranting..... 

I don't think windows messaging would be fast enough.  All mame does is pump out the values of data used in real life scenarios (like a flashing light) and it seems to lag a little sometimes.  I can only imagine if you actually had to do something and wait for it to finish. It would work, but only if you aren't doing manual animation.  I'm not sure a server app would be a good idea for anything other than sending animation files.  Where the ledwiz needs that delay for the usb chipset issue every millisecond counts.  At least if you are doing anything advanced with it.  For a fe it'd be fine though since, as I complained above, you would really only want to send different layout files in a fe. I say make it command-line based, but that's just me. 

[loadman]

You are going to have to find me more than that.  For a sdk, there is very little documentation. 

Granted there's a simple io example I can look at to figure out how to operate leds, but it doesn't tell me the possible values or anything. 

Also a compiled version of the dll would be nice.  I haven't re-installed 2k5 yet. 

When you have downloaded the SDK from the link in my earlier post:

A compiled version of the DLL can be found here:
SDK\Windows\library_1_5\source\Release

Good Simple examples can be found here:
SDK\Windows\Samples\Simple IO ( Turn a led on, turn a led off EASY :-)    )

Documentation
SDK\Documentation (EG AN1 is for a LED matrix but just switching one one is easier)

If you are serious I can lend you a MaLa Led Controller. (I have an extra one I use for testing) Just PM me an address to send it

Cheers

Load