Main > Software Forum
What is Mame's "generic output support system" capable of?
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: ---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
--- End code ---
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: ---Public Function handle_copydata(lParam As Long) As String
--- End code ---
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:
--- Quote from: 2600 on January 31, 2007, 03:12:50 pm ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version