What is Mame's "generic output support system" capable of?

[headkaze]

I'm referring to this blog entry on Aaron Giles' blog...

http://aarongiles.com/?p=181

I’m hoping this new functionality will inspire some of the BYOAC folks to update their MAME hacks to use this new solution instead, and come up with some other new cool ideas. I’m also hoping it will inspire folks documenting the outputs better in MAME proper, which is something I’ve been wanting to see for quite some time.

What information can an external app extract from Mame using this? And what are some practical uses of this output system?

Does anyone have some example code in C++ that interfaces with Mame this way?

[Howard_Casto]

The output system is very convoluted to setup, but once you get it running it is nice and fast.  Basically it works like this, if a game had some sort of output (flashing light, siren, propeller, rumble motor, ect) and the mame driver has that output hooked up to an output port, you can use an external app to read the status of the output device.  Then of course you can have that external app do whatever you want with the data (control ledwiz, play a wav file, display a graphic on a secondary monitor, ect).

You already have an example actually.  In the mame source, the led controller has been made into an external app by aaron.  Look in the mame source and you'll find it.  Really simple stuff, but it's enougnh to understand how the interface works. 


Now the problem with it is that the driver has to support it.  Right now, 90% of the games that support output ports were added by aaron himself, and it's ususally just coin/rank lights.  However, there are still a ton of games that support it, it's just not the things you might be wanting to do (like terminator 2's recoil or afterburner's force feedback joystick, which are not supported yet).

[headkaze]

Thanks for the info HC.

I'm curious, what are led0, led1, and led2? I understand that ledutil.exe has been externalised to convert these outputs to the numlock, capslock etc. LED's on a keyboard. What is this functionality emulating from a real cab?

What other outputs are there and where can I find a list of them. I had a look at ListInfo.xml for anything relating to outputs but did not find anything. Is there a C file in the mame source listing all the outputs or are these all stored in individual drivers?

[Howard_Casto]

Well there in lies the problem.  When aaron added the output system, he basically generically converted all of the game that used to use the keyboard leds to "led0-led2" so they could represent anything, depending upon the game.  Usually it's the coin lights, but you can't always assume that.  Gorf, for example has 6 rank lights, that have been labeled led0-led5.

Output names are stored in individual drivers unfortuantely.  Also imho they are kind of useless because of the way it has been setup.  You see your app doesn't get data from "led0"  it gets data from a digit address, like 0001.  Once you get some data from a digit address, you can call mame asking it for the string name and it'll send it back.  This is all well and good, except that you don't know what outputs are in there until each one sends you data, and by then it's too late.  Couple that and the fact that you have to pretty much treat each game on a case by case basis and you might as well use the digit addresses as it saves you a step. 

I should also note that I couldn't get the string to return for me in vb6, but that is my issue.  In c languages it works fine.

So basically, to support a game properly you need to look in it's driver, get the addresses, and make a custom ini file that describes the outputs.  Now you could make a "discover mode" app that pretty much only reads for addresses and translates them to thier string names for a custom ini, but again, you aren't going to get the string name if some data doesn't get sent to the address, which could happen more often then you'd think. 

Imho, the easiet and best way to deal with these issues is to do a controls.dat deal, but maybe on a simpler scale.  People could go into a driver, get the data, and make an ini file that looks something like this:

[captions]
Coin Light 1=00010
Coin Light 2=00020
[settings]
00010=
00020=

And basically a developer could bind the caption to the address from the captions entries and then in the configuration part of thier app, use the real caption names, only save the real life dodad they want to control to the actual address number.  Then when you are actually running mame, it is super fast as it can ignore the captions read the addresses instantly without doing a translation.

I was the guy that bugged aaron to add output support, and I'm ashamed to say I've sat on it for a few months now.  I have thought about ways of doing it though, as you can see. 

[headkaze]

I'll look into this whole thing a bit more some time, perhaps we can come up with a better way of dealing with outputs. I do like your idea of creating some sort of ini file though.

aaron I’ve setup a test app of my own and all is doing well, except for the stuff i get back from wm_copydata. It comes back as gibberish.

I’m first dumping it into a copydatastruct, then using the info from that to fill a byte array, then converting the array to unicode.

Are you using this method...

http://www.mredkj.com/vbquicktakes/Subclassing.html

[Howard_Casto]

yeah, amoung others....  the problem is that he is using a variable type not supported in visual basic.  There isn't any way to convert it because the proper data never gets sent in the first place due to having to stick it in a different variable type. 

[headkaze]

What variable type are you referring to? Have you tried something like this...

Code: [Select]

Private Type COPYDATASTRUCT
    dwData As Long
    cbData As Long
    lpData As Long
End Type

Private Type copydata_id_string
    id As Long
    sString(0 To 255) As Byte
End Type

Sub handle_copydata(lParam As Long)
Dim sString  As String
Dim copydata As COPYDATASTRUCT
Dim data As copydata_id_string

Call CopyMemory(copydata, ByVal lParam, Len(copydata))
Call CopyMemory(data, ByVal copydata.lpData, copydata.cbData)

sString = StrConv(data.sString, vbUnicode)
sString = Left$(sString, InStr(0, sString, Chr$(0)) - 1)

frmReceive.lblString = sString
End Sub

[Howard_Casto]

I appreciate your help, but that won't work. 


It's gonna crash on this line:

Call CopyMemory(buf(0), ByVal data.sString(0), copydata.cbData-4) ' minus the 4 bytes for id


You see you are assuming that just because you setup the id string structure into two seperate variables that it'll actually split them up when it recieves the data.  It can't, because vb doesn't support the two variable types that are being sent. 

UINT32 cannot be converted to long, period, end of story.  At least not in a data structure it can't.  Aaron argued me this point as well at nauseum.  I agree with you both that on paper it should convert, but when you run it, vb craps all over itself, half of the time just disappearing... no error message no nothing. 

The only way I could get any kind of data without it crashing was to ditch the structure entirely and setup a big byte array.  Unfortunately all the data I got back, even if I trimmed 4 bytes off,1 was gibberish.

I'm up for ideas, I just don't know how to get it working and I can assure you that all of the usual techniques (read modified example code swiped from websites) don't work. 

[headkaze]

I must have just changed my last post while you did yours. I changed it a bit to simplify. Thats really strange that a UINT32 can't convert to a Long since they are both 4 bytes in length.

Perhaps you can try changing the struct to

Code: [Select]

Private Type copydata_id_string
    id(0 To 3) As Byte
    sString(0 To 255) As Byte
End Type
I have no idea! *shrugs*

[Howard_Casto]

That's how I have it setup in my app right now... it doesn't crash, but it doesn't work either. 

I get back a ampersand for the game name when i try to call it, and a q when led0 sends data. 

I'm beginning to wonder if the memory addresses copy memory is sending are compatable. 

[headkaze]

How about after this line

Code: [Select]

Call CopyMemory(data, ByVal copydata.lpData, copydata.cbData)
Loop through each byte of sString until you hit a null character outputting them as an ascii integer value followed by it's char equivilent. At least then we know it's not the conversion to unicode thats messing it up.

Eg. The output would be
65:A
66:B
67:C

[Howard_Casto]

well the data i get back is pretty much all nulls


I get a null, a single or sometimes double letter, followed by nulls (which is expected because we've created a 256 character array)

[headkaze]

Can you get copydata_id_string.id okay or is that garbage as well? In that case I would suggest it's a problem with some other part of your code. Maybe you don't have your listener window setup properly. VB6 is a bit funny with subclassing as well, from memory you can't even subclass within the IDE without it crashing.

You can check the memory addresses in COPYDATASTRUCT are received correctly by modifying ledutil to output the addresses when it receives them in Aaron's program.

Then output them the same in your test program and compare addresses. If they are in the same range it should mean the addresses are received okay. If they appear as garbage it should be clear that it's garbage and not being received properly.

I guess the only way to figure out where it's not working is to back track through the code and test each part as it happens by comparing expected output from the ledutil util. Attached is a VC++6 console version of ledutil with debug enabled, and I've added an extra output to show the addresses in the COPYDATASTRUCT so you can check them against the addresses your receiving.

[Howard_Casto]

That was useful, thanks....

hmm it seems vb is doing some auto format conversion... my guess is that is what is causing the screwups when it recycles the gotten data to read those chunks and break it down into the data we need. 

Note below how it's hex in ledutil and integer in my app (I'm not doing any conversions)

Code: [Select]

LedUtil Output:....

Using PS/2 method
mame_start (0D4F04C8)
copydata (0D4F04C8)
copydata.dwData (00000001) copydata.cbData (0000000E) copydata.lpData (0012FDB0)

  id 0 = 'digdug'

======================

My apps Output:....

copydata:   1309576
copydata.dwdata  1 copydata.cbdata  8 copydata.lpdata  1309600

Now the question is what to do about it. 

[headkaze]

I think I've found the error in the code. Although your outputs look wrong and they shouldn't be. I've been assuming that char string[1]; is actually 1 byte, but it's not, it's a pointer to a string of chars, meaning it's 4 bytes. Hence why the cbData is 0xE which is not what I expected. So I added some more debug output.

Code: [Select]

Using PS/2 method
mame_start (001A0878)
copydata (001A0878)
copydata.dwData (00000001) copydata.cbData (0000000E) copydata.lpData (0012FDB0)

sizeof(*data) (00000008) strlen(data->string) (00000006) sizeof(*data) + strlen(
data->string) (0000000E)
  id 0 = 'digdug'
mame_stop (001A0878)
And here it's finally clear what's going wrong. sizeof(*data) tells us that copydata_id_string is in fact 8 bytes long. Sorry, this was my mistake I should have realised the array of chars is a pointer. If it was defined as char string; then it would be 1 byte long, but char string[1]; means it's a pointer (4 bytes), same as char *string;. Okay now we have that out of the way, it's clear why your decoding the string fails because your decoding a pointer address! Hence why you get a few garbage characters 4 bytes long.

Try this new approach...

Code: [Select]

Private Type COPYDATASTRUCT
    dwData As Long
    cbData As Long
    lpData As Long
End Type

Private Type copydata_id_string
    id As Long
    lpString As Long
End Type

Sub handle_copydata(lParam As Long)
Dim sString  As String
Dim copydata As COPYDATASTRUCT
Dim data As copydata_id_string
Dim buf(0 To 255) As Byte

Call CopyMemory(copydata, ByVal lParam, Len(copydata))
Call CopyMemory(data, ByVal copydata.lpData, Len(data)))
Call CopyMemory(buf, ByVal data.lpString, copydata.cbData - Len(data))

sString = StrConv(buf, vbUnicode)
sString = Left$(sString, InStr(0, sString, Chr$(0)) - 1)

frmReceive.lblString = sString
End Sub
See if that works.

EDIT: It still dosn't explain why your getting copydata.cbdata  as 8 (0x8). It should be 14 (0xE) but that could be a problem somewhere else in your code. You may need to send me the source so I can check the rest out. I'm pretty sure the above code is correct now though.

[Howard_Casto]

That's one of the methods I've tried before.... doesn't work.

I want to make sure we are on the same page first though as you had a couple of errors in the code and I corrected them.


The new code looks like this:

Code: [Select]

Private Type COPYDATASTRUCT
    dwData As Long
    cbData As Long
    lpData As Long
End Type

Private Type copydata_id_string
    id As Long
    lpString As Long
End Type

Public Function handle_copydata(lParam As Long)
    Dim sString  As String
    Dim copydata As COPYDATASTRUCT
    Dim data As copydata_id_string
    Dim buf(0 To 255) As Byte

    Call CopyMemory(copydata, ByVal lParam, Len(copydata))
    Call CopyMemory(data, ByVal copydata.lpData, Len(data))
    Call CopyMemory(buf(0), ByVal data.lpString, copydata.cbData - Len(data))

    sString = StrConv(buf, vbUnicode)
    sString = Left$(sString, InStr(0, sString, Chr$(0)) - 1)

    'frmReceive.lblString = sString
    handle_copydata = sString
End Function
You had set buf as the destination, but you didn't use it afterwards, so I fixed that.  Also you'll note on the third call I changed "buf" to "buf(0)"  I actually think this is the issue with the variable conversion right there.  You see vb won't let you use arrays with api calls unless the api is specifically setup for one.  I don't know if vb has enough sense to start with 0 and fill up all 256 bytes or not. 

What I can tell you is that buff comes back a total null, letting me guess the latter is the case. 

Also the len function you are using is another issue.  No matter what mame sends out, the length of data always seems to be 8.  So 8-8=0, so it isn't getting anything.  That would also explain the null... I'm going to remove the offset and see what I get.

[headkaze]

You might also want to change this line

Code: [Select]

Public Function handle_copydata(lParam As Long) As String
Otherwise your returning sString as a Variant.

I noticed a few mistakes that I must have changed after you read the post. I don't actually have a full VB6 app setup to test the code, so it's all a bit on a whim at the moment. I did forget the buf(0) bit though, buf(0) must mean the pointer to buf in VB6. VB6 tries to hide pointers which makes low level stuff more difficult. As you know I'm not a big fan of VB6 anymore

I will be writing code to communicate with Mame in C#, so none of this is particuarly helpful to me but I do want to help get your code working so we can work on some ideas for a standard output ini format. If you can't get the name of the ROM then it will mean an extra step of complication. I mean you can always get the ROM name from Mame's titlebar, but there is no reason why we can't get this working the way it's supposed to.

Len(data) will always be 8, that is correct two Longs @ 4 bytes is 8 bytes. So there is nothing wrong there. data->lpString is a pointer to memory location in Mame that we use CopyMemory to copy the data across. Like I said copydata.cbData should be 14 (0xE), so there must be an issue somewhere else in your code.

So copydata.cbData - Len(data) should be 14 - 8, which is 6, the number of characters in the string "digdug".

[2600]

Sorry to interrupt your discussion, but adding to the topic.

I was debating on asking Aaron about the idea of a "Pause" message.  Currently, there is a risk that the user could press Pause while an output is triggered.  Since the client app would not know this, it would leave the output triggered which would bad.  Any thoughts? 

Looking at the source it I believe it to be trivial, but it still would probably be a hack if I submitted a patch for it.


headkaze, when are you going to write a library so other people can write .net client apps? 

[Howard_Casto]

Ok, it's definately the wrong address.  I monkeyed with the datasize (manually set it to 32), and I was able to get the string "KeyToken=384384" or something to that degree when calling the romname in digdug.  it crashes for anything else, but this is obviously due to the fact that the address is wrong and thus there isn't always data in that reigon to read.  The token definitions are related to the output system, so it's in the right ball park, just not exactly where it needs to go.  

Data.id doesn't come back right either, which again is probably a variable issue.  It should be coming back as 0 and it's like a 10 digit number.  I think it might be snarfing part of the string data.  Still doesn't explain why the length isn't being reported correctly though.

[Howard_Casto]

Sorry to interrupt your discussion, but adding to the topic.

I was debating on asking Aaron about the idea of a "Pause" message.  Currently, there is a risk that the user could press Pause while an output is triggered.  Since the client app would not know this, it would leave the output triggered which would bad.  Any thoughts? 

Looking at the source it I believe it to be trivial, but it still would probably be a hack if I submitted a patch for it.

This is definately an issue, but I think it can be better handled on the client end.  The easiet way is to have "time outs" for objects that can be damaged if left on.  So if the client app is routing a bit of data to a solenoid, and the solenoid is left on for more than, say, three seconds,  the app automatically sets the value back to 0 and turns it off.  Having lights say on wouldn't hurt, so the only issues you are going to run into involve force feedback and solenoids. 

Doing it in mame would be more complicated because the output function doesn't poll the values of outputs, rather the value to be set is passed to it.  So when you paused you could definately have the function set everything to 0, but I dunno how you could easily, and universally get all of the values back once you un-pause.

[2600]

This is definately an issue, but I think it can be better handled on the client end.  The easiet way is to have "time outs" for objects that can be damaged if left on.  So if the client app is routing a bit of data to a solenoid, and the solenoid is left on for more than, say, three seconds,  the app automatically sets the value back to 0 and turns it off.  Having lights say on wouldn't hurt, so the only issues you are going to run into involve force feedback and solenoids. 

Doing it in mame would be more complicated because the output function doesn't poll the values of outputs, rather the value to be set is passed to it.  So when you paused you could definately have the function set everything to 0, but I dunno how you could easily, and universally get all of the values back once you un-pause.

Yeah, that's definitely one way to do it.  Originally, I was thinking the client app could remember the state of the outputs and return them when unpaused.  I only wanted MAME to let the client know the system has paused.  Technically, if I were to implement a client I would implement the timeout even if MAME had a pause message as a dual fail safe.
Of course, I was also thinking that knowing when MAME is paused would could be quite useful.

[headkaze]

I have written a dll that deals with all the messaging, and I will be releasing it soon for developers.

[Howard_Casto]

Sit tight everyone.  Using the latest programming techniques, the best hardware available, and a box of crayons, I think hk has a working dll and we've worked out all the kinks with the example code.