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

[Howard_Casto]

Don't sweat it man, I'll just send the app to you and you can test it. 

I forgot to write the docs so the release will be either late tonight or early tomorrow, depending upon how long I can manage to keep interested today.  A source-code release will soon follow.

[Howard_Casto]

Ok Guys, here you go.  Give it a spin and let me know if anything isn't working. 

And I can't stress this enough, please READ the readme.txt before even launching it.  You'll need to setup your ini file for your particular hardware.  My example default.ini has the qbert knocker and the 4 player start/coin leds already setup with some possible scripts to give you an idea of what you can do.  Questions and comments would be appreciated as scripts tend to confuse the hell out of people.

http://www.oscarcontrols.com/lazarus/files/mamehooker1.0.zip

[headkaze]

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.

I don't think the dll will need to be updated anymore. All the code necessary to communicate with the LEDWiz is already in there. What updates are necessary? The only update to ledwiz.dll needed was made recently by MikeQ to change the SBA levels to go up to 49 instead of 48 since some devices didn't work with the PWM signal, and 49 is the only level that dosn't have a PWM signal. What needs to be updated? Nothing.

I don't get how you think adding internal support for LEDWiz in a FE is a bad idea. It's like saying adding internal LEDWiz support to J5 is "stupid and useless" [sic]. A command-line app is okay for lighting up buttons when you, say, want to view the game's CP. But what about realtime lighting while scrolling through a list for example? A command line app is not good enough for something like this.

How do you know what people want from their ledwizzes? People want to do as many things as they can, like "speak each button action while lighting it up", cool things like that were only available in PowerMame, now you can do it from the FE. In my opinion (and maybe noone wants to hear what I think either), it's better to have LEDWiz support in the FE than in a custom build of Mame. As anyone who knows will tell you maintaining a custom build is alot of work.

I don't see why it's better to have the LEDWiz support inside the CP Viewer. All that does is limit what you can do with the LEDWiz to lighting up your buttons when you view your CP. Unless you have J5 running resident and allow external programs to send commands to it, it's rather limited in what it can do. Some people like the buttons lit up while they play a game, some don't, and also attract modes are a must have feature for a LEDWiz too (IMHO), you can't do that in a CP Viewer app. I really don't understand your logic behind thinking that.

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.

Lighting up different color-coded layouts is one aspect, but a LEDWiz plugin for a FE can do that, there is also attract mode and responding to Mame's outputs and plugins can do that too. Are you starting to see why I think it's better to have LEDWiz support in the FE rather than in the CP Viewer? BTW A plugin remains resident the entire time your running Mame and is constantly given calls from the FE telling it what event has taken place (keypress/game selected in list/mame started/mame finished/game launch/game stop/attract start/attract stop etc.) You can use all these events to control the LEDWiz in different ways. There is no two way communication between a FE and an external CP Viewer, all you can do is send it the ROM name in a command line parameter and have an ini file with your LED's setup the way you want. How do you tell J5 to run an attract mode sequence for example?

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.

Animations is not all it can do, it can do that and everything else a CP Viewer can do and a LOT more. I really don't get your reasoning behind what your saying. I'm racking my brain and I can't figure it out. I'm not trying to sound arrogant when I say this, but take a look at my LEDWiz plugin and tell me what features are missing that J5 has. Take a look at the Mala LEDWiz plugin, or the LEDWiz support in Atomic. They all do more with the LEDWiz than a CP Viewer ever could and the reason is because they are either plugins or built into the FE.

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. 

You really must have no idea about Windows Programming then. The whole Windows API is based around dll's and shared librarys. It's the same idea behind OOP. You sound like your avoiding using dll's for the sake of it. Your just going to send out the false impression that dll's are evil or something. Does having only two dll's in DK make you a good coder? No. There is nothing wrong with having dll's if they are written well.

VB6 is your main language so you should be using more dll's not less, and writing them in C++. What if you want a thread for example? VB6 will crash if you try to use threading. MameInterop is a point in case, the message loop for the Window that captures messages is infact in a thread. Try doing that in vB6 alone.

But enough ranting.....

You have a right to rant about anything you like and there is nothing wrong with disagreeing. For example I disagree with the main arguments in your post.

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. 

The way I was going to write is was to have commands where you can load lwa's into the server by pointing it to a bunch of lwa files and it will load them in memory so you can just send another command to execute them. I don't believe there is the delay issue with the ledwiz.dll only the ocx AFAIK, and I would recommend you use that instead of the ocx anyway.

Again, I disagree with the commandline option. Swindus has already written one called LEDWizLighter anyway so it's not like it's not an option. LEDWizLighter uses output from my LEDWizGen application which generates the lighting profiles for all games in controls.ini. Right now that can be used with FE's like MameWah that don't have support for LEDWiz built in. But it really does limit what you can do with the LEDWiz to just lighting the buttons for a game, which in my opinion dosn't really take advantage of all the other cool stuff you can do with it.

[Howard_Casto]

Sorry man but you couldn't be more wrong. 

J5 can do attract mode sequences, for example.  It just does them a different way.  You set up the default state for all the lights, which cna be multiple states in sequence.  J5 IS a resident app, it's just optional because it uses some memory and some people don't like that.

ledwiz does have a delay.  There's even a checkbox to turn if off (or down) in powermame.  It has nothng to do with the connection method, from what I understand it's some sort of usb chipset issue.  Yes the ocx is significantly slower than the dll, but the dll stil can't instantly light something.

Your point about windows apis vs external dlls is invalid.  When m$ makes a dll update, they make sure it is backwards compatable, third-party dlls, not so much. You don't have to worry about dlls that you are calling via the api because they are installed by default with windows.  The only non-windows api calls I ever make are to directX, because, well if you are running mame without directx then god help you.  The whole reason the api layer was invented was so that developers don't have to package their stuff up with dozens or dlls and manage their registration, thus bloating and complicating the project.  And I did do multi-threading in vb6 remember?  I already had a working hooking app before you helped me with the variable issues, it just didn't get the name properly.  But to answer your question, when I find something that vb6 can't do, I don't do it.  Of course over the past 10 years or so there's only been maybe 2 or 3 things that I've needed to do in vb but couldn't. There's a flaw in your thinking there about the dlls.  If I was constantly writing C++ dlls to get things done then I just code the whole thing in C. 

You are confusing the issue of can with should.  Can you make a fe infinately more complex by doing all the coding requried to properly light all the buttons and properly assign all the labels?  Of course.  Should you?  Well if your fe is perfect and you never want to add another new feature then you probably have the time as a developer to do that, otherwise you'll be spending all of your time getting this feature integrated.  As of now only two applications assign labels and lights properly... j5 and powermame.  (And to be honest I'm not sure about powermame and labels, but I'm giving it the benefit of the doubt.)  It was easier in powermame because you don't have to recall data, it's in there already.  J5, on the other hand has a hard time doing it.  Getting all the data required to do this accurately and properly takes at least one call to mame and the parsing of up to 5 very large xml files as well as the controls.xml/controls.ini.  Some of the other stuff can be stream-lined by a more telented programmer I'm sure, but the mame call can't be avoided.  You can either do it per-game, which makes quick changes impractical, or all at startup, which would make your boot-time significantly longer.  I'm not the best programer in the world so I'm sure some speed improvement can be made, but not enough to make it practical to, lets say have the layout change on the fly while you are scrolling through the list to reflect the current game selected.  It can be done AFTER you stop of course, but at that point speed isn't a issue and you can just set it externally.  And before you start mentioning this fe and this app that does it quicker, yes I'm aware of many of them, but unfortuantely they do it wrong.  They output a rough reflection of what the layout should be, their accuracy is generally around 60% because they don't read the cfg, ctrlr, driver and device settings like I do.  And I understand that for a lot of people that this rough estimation is enough, but I said right in my first sentence in that post in the last post that this is what I thought.  I don't think you should do something if you aren't going to do it right.

And I want to make something prefectly clear, I'm not being arrogant about this, this is just the truth.  The reason j5 is so accurate is because I abandoned all of my other projects indefinately as I built the complex backend for it.  And guess what?  About the time I got it done, they up and changed mame's file system structure and I had to do it all over again!  Dk hasn't been updated in almost 2 YEARS.  That should tell you what a full time job it is to keep the stupid thing maintained.  It isn't the most accurate and feature driven because I'm god's gift to programming, it's that way because I spend way more time on it than any normal person would.  So that goes back to what I was saying earlier, while you can do it in the fe, it'd be a full-time job to implement. 

Yeah your right, I suppose you couldn't have your buttons "talk" to you ro anything crazy like that if you did it externally.  Maybe I'm having a lapse in logic or something, but why would you want to do that inside a fe in the first place?  At least some of the buttons on your layout are used for actual navigation in the fe, so it's impossible to press them all without launching a game or scrolling through the list inadvertantly.  Aside from that, this seems like a feature that would only be useful while playing a game.  Again, I might be missing something. 

Yes you are absolutely right, you can't have a dynamically-generated "scrolling sequence" via command line.  Again though, unless my logic fails me you can't have that even if it's integrated.  I don't know what the scroll speed is on the average fe is these days, but in my fe the time between transition from one game to another is less than 10 ms.  Yeah you could have em blink as you scroll or something but it'd be so fast that it'd give you a seizure or something.    Now if you are referring to loading a different animation while scrolling that isn't keyed to the scroll speed, then you can do taht via external calls.  Send the scroll animation layout file when starting a scroll, and set it back again when idle.

And I'm not being sarcastic at all but your going to have to explain that last line.  Given what I've said about how a lot of the things you suggested are impractical to do what cool things are left that you can only do via integration? 

You seem to be upset or something and I don't get that.  You asked my opinion about the app and in order to give it, I had to explain why integration is a bad idea.  You can't exactly get upset because I gave you my opinion when you asked me for it.  If you wanted me to lie then you should have said so.

I think you aren't getting what I was saying about the windows messaging being slow though.  There is some delay (not much, but time is taken) when you send or recieve a message.  It isnt huge at all but it causes issues because windows message threads are cached and there isn't any practical way to do a "frameskip" to ignore incoming message processing while you are setting the lights. 

You know that bug in basketball I mentioned the other day?  That's the perfect example.  See it's flashing so fast that I "miss" some commands while I set the lights.  The problem is they aren't "missed" they are waiting in the window's built-in message que building up as they are waiting to be processed.  Eventually the load is just too great.  If I manage to exit out of basketball before the build-up crashes the app it continues to blink on and off even after mame has exited for up to a full minute.  This isn't something I've coded that is making that cache, it's the way windows works so there is no getting around it.  The only way to solve this issue is to have two-way communication, but that kills your speed advantage right there.   For just setting layouts, yes messaging would work great.  For on the fly animation, it could be dangerious.

You are missing a much easier way to get things done though if you just really want to use messages.  We made the sdk right?  I'm writing this app that can do all kinds of things besides just ledwiz via the sdk right?  They use messaging right?  Ok, time's up, pencils down.  Instead of making a new message protocol and going to the trouble of writing an app that only handles the ledwiz, why not just write a dll everyone can use that "fakes" mame's output system?  Mame doesn't do anything special, it just sends it's hwnd and sends a set of custom messages, so an app doesn't have to be mame to take advantage of a sdk app.  Then a developer has access to anything coded via the sdk.  Heck if there's some feature missing from the little app I'm coding just add them and then you have an app that does everything you wanted plus it has all kinds of other crazy interfaces supported.

We are very fortunate with mame because inputs aren't changed quickly for the most part.  The few that are changed quickly are thankfully force-feedback-style effects and m$'s force feedback interface is so quick that time is measured not in milliseconds, but in microseconds.  So hopefully we aren't going to run into the issue there. 


Ok man take a breath, it's all going to be alright. 

[headkaze]

When I was talking about making a LEDWiz SDK like the MameInterop SDK using Windows Messaging that's exactly what I had in mind (to do it like Mame does). There is only one way to use Windows Messaging and that is to have your own custom messages and send them via SendMessage or PostMessage and read them in the WinProc function. I've already written applications that do this so there is no problem with the method. It's when your sending lots of messages very fast that I'm not sure if it's the best method. I guess I need to do some testing. On slower machines this could be a problem, and we don't want to lag the calling program. Your issue with the bug in basketball hilights that very problem. There is the alternative method of using a localhost loopback with ports but I havn't done much winsock stuff.

Okay J5 is memory resident, it can do attract mode sequences, I STILL think FE's are a better place to handle the LEDWiz device. Or to use some sort of global solution. But for FE's that don't currently have LEDWiz support, J5 will be the perfect solution for those people.

I don't believe there is the usb chipset issue anymore. There has never been a FastCom mode for the ledwiz.dll so I assume it's all handled automatically.

The VB6 application you wrote was a common method of hooking a Window so you can read it's messages. Something I've done before in VB6 myself. But this has nothing to do with threading, so I'm not sure what your talking about there. VB6 can't to threading, simple as that.

Why not code in C then? I'm guessing the reason your not coding in C is because you don't know the language well enough. VC6 is not as easy to create windows forms in using pure API, and MFC has it's own annoying issues. So I would imagine many people would write apps in VB6 because it's easier to create the forms and have any of the lower level stuff stored in a C++ dll. It's all about using the right tool for the job. I only code C++ using VS6 so it's probably alot easier to write form based apps in C++ in one of the newer Visual Studio's.

Your saying that adding LEDWiz support to a FE is a bad idea because it takes alot of time to write. Well I'm not the author of GameEx, but I'm writing the LEDWiz support. That is the whole point of having plugins (which in reality are just dll's).

If I have to parse ListInfo.xml every time the plugin runs, the way I would do it would be this way:

1. Having the full path to the mame exe, I launch Mame with the command-line option to generate the ListInfo.xml to a file.
2. Parse ListInfo.xml writing only the outputs necessary for the plugin to an ini file in a compact format.

Eg. ROM Name|Parent|NumButtons|etc.

3. Next time you run the plugin it compares the Mame.exe version or creation date with the last time it was run, if it's newer then goto 1.
4. If it's not newer and the compact ini file is available parse that instead.

That will get parsing ListInfo.xml to under a second. Parsing the entire ListInfo.xml takes about 5 seconds on my machine but it will only need to do that everytime you update Mame. I store all the info I need from ListInfo in RAM, so it's instantly available at any time - so realtime lighting during list scrolling is possible.

Also your point about list scrolling, the way it works in GameEx anyway, is that while you hold down your joystick to scroll down the list the GameSelect() event isn't triggered every time. If you let go of scrolling for a second then the event is triggered and the LED's light up for the game.

Right now I'm not that worried about people who map their keys in strange ways. For a while now I thought parsing controls.ini was enough but I will deal with that eventually. It can't be that difficult, I mean even parsing a bunch of files and referencing them, it can't be that hard. I never knew that you needed to read cfg, ctrlr, driver and device settings to get perfectly accurate LED lighting, I might have to E-Mail you for a more detailed rundown on how I should go about that if you don't mind. I like to do things the right way too, so your help would be appreciated on that.

I'm definately not upset so I'm sorry if I come across like that, try to take me with a grain of salt, I mean no offence even if I'm being blunt. I tend to be very dry when I'm talking about technical issues and I do try my best to avoid sounding emotional about it. I appreciate your opinion even when I disagree with some things you say. Though the majority of the stuff you say makes sense and I agree with.

[Howard_Casto]

I'm not going to argue, BUT  one thing you said is laughable. 

You said you weren't worried about "people who map their controls in strange ways".  There's nothing strange about how my controls are mapped and there is a LOT of remapping.  And this isn't just because I like it that way, it's to make the games playable.  Mk is a hugely popular series, it is totally unplayable with the default mame mappings.  So there's 4 games (or one driver) right there.  All the street fighter games are upside-down, so those, while not required probably should be remapped.  Any neogeo game with 4 buttons (which are all fighters) have to be remapped to be playable as a standard layout would put button 4 above button 1 and almost all the kof combos use combinations of a/b and c/d and it'd be really hard to hit c/d at the same time like that.   And those are just the games that I personally like, there are probably hundreds of games in mame that need re-mapping to be playable.  So basically like I said, if you don't go to all the trouble that I mentioned, your accuracy is 60% or less on ANYBODY's layout.  I'm not that much of a glutton for punishment.  Wouldn't have done it unless it was necessary. 

And your right it isn't complicated at all, it's just that there is a lot to parse and there is a lot of "cause/effect" branching going on depending upon what you parsed at certain steps. And the device and -joystick/-mouse/-lightgun calls are a nightmare.  You get it parsed perfectly and then how those settings are set totally changes it.  That bit isn't crucial but if you've already ran 49 yards you might as well go for the touchdown.  I'm more than willing to help anyone who needs it, but so far whenever somebody asked me about it and I explained roughly how to do it they got scared and were never heard from again. 

The fastcom stuff is handled internally in the ocx (thus the lag) and via code in the dll.  Afaik the issue still exists.  Even if it didn't a HID class device is "slow" by nature.  I don't want randy jumping all over me so let me explain that.  HID devices, all hid devices have a speed limitation.  We are talking milliseconds here, it's not a big deal, but there is a delay even on the quickest of hid devices.  In normal use it's never going to be an issue, but with that whole backed up buffer deal it could be. 

Oh and winsock is scary.  I've done some winsock apps, (one for the daphne team, but I never got around to sending it. ) and they are quicker, but they are a mess to code because you have to have so much error handling.  If you set it up to have app 1 wait until app 2 sends a "recieved" message back and something happens to app 2 you program is essentially frozen.  Also, much like a serial connection the two apps pretty much have to know they are going to talk to each other and if one misses the startup then you are screwed.  There are ways around that but they aren't pretty.  Makes for more complicated programming.  That was actually why Aaron did messages instead.  (Yes as frightning as it sounds we managed to have a short discussion about it without killing each other back then.)

(p.s. Don't think that I was angry either, that's just how I am.  All the smilies on the last post were intetional so you wouldn't think  I was "yelling" at you.)

[loadman]

(p.s. Don't think that I was angry either, that's just how I am.  All the smilies on the last post were intetional so you wouldn't think  I was "yelling" at you.)

You are getting soft in your old age 

PS I agree with HeadKaze on how a Led-Controller should be set-up (in most part) as far as it's use goes (In a FE ect.....)

But really there is no right or wrong...  like a cab design it's just a matter of personal taste.

I'm sure you would hate my light fittings in my house 

[Howard_Casto]

PS I agree with HeadKaze on how a Led-Controller should be set-up (in most part) as far as it's use goes (In a FE ect.....)

No you don't man, you just think you do.  Aren't you the same guy months ago who pmed me frustrated that mala doesn't support the ledwiz? Well if the iowarrior stuff had been externalized then it would because somebody would have taken the stand-alone exe and replaced it to work with the wiz. 

See there are two types of fe programmers out there, the type that says "Ok I know what people want so I'll only add support for the good devices and that's that." and the type that says "I think, I know what people want, but I'm not superman and I can't do it all so I'll build the structure so that bits of my app can be replaced or interfaced with."  Sometimes it's unintentional though, but regardless the funny thing is it takes the same amount of time to do things the right way (modular) vs doing them the not so right way (internalized)  and the end result functions exactly the same.  The only difference is with my method the user doesn't have to buy new hardware when they switch fes.  I could accomplish 99.9% of what people have been doing with the led hardware in fes by simply having a user-configurable command-line call at various keys points in a fe's code and using some of the great stand-alone utilites that alredy exist for the led wiz.  It works the same and yet the user isn't limited to what I thought would be useful or what hardware I personally have. 

When I wrote above "it makes the code more complicated and more bloated" I thought you guys knew I said that because if you add support for "device a" then out of fairness you have to add support for every single similar device available to the community.  On the other hand if you set it up so that you control "device a" externally then you don't have to support every single device under the sun because you have left a window open for users to add any additional support they may need.

Now you can add built-in support AND support external calls, but why would you when you can keep your code cleaner and achieve the same functionality by using the external interface you just setup?

[loadman]

... Yeah you make good points but that is not really what I meant.

This is what I don't agree with personally:

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.

Really? I'll take two for $5

What I like a Led Controller to do is:
* Lights the appropriate controlls as you scroll through the list
* Play sexy attract modes
 - When Idle
 - When launching games
 - When switching lists/ emus
- Leave the appropriate Controlls lit after launching a game.
I'm not to worried about colours of buttons etc

But that is just me.....

anyway back on track

Don't sweat it man, I'll just send the app to you and you can test it. 

Is there anything I can do to help?

[headkaze]

You said you weren't worried about "people who map their controls in strange ways". 

If your gonna quote me, at least quote me properly

I said "Right now I'm not that worried about people who map their keys in strange ways", meaning that eventually I do want to add the code to get the lighting as accurate as possible for people who do map their keys differently. Just right now I'm sort of in the middle of redoing my CP with RGB buttons and two LEDWiz controllers. At least then I can see the results of my plugin so I can debug it more easily. I'll worry about all the extra file parsing a bit later down the road.

And I agree with loadman in that it's a matter of personal taste. I think having choice is what makes this scene so great. So I don't think we need to argue the finer points of where the LEDWiz support should go.

I'm more than willing to help anyone who needs it, but so far whenever somebody asked me about it and I explained roughly how to do it they got scared and were never heard from again.

Lol! Yeah I can imagine it's probably a number of steps, but I have code to parse Mame's output, so I just need to add those extra steps. It's not the code to do it that confuses me, it's what process needs to be taken to find out which button assignment associates to which button on the control panel. But thanks for the offer I will e-mail you about it.

I have the CommIO.dll here, but I havn't written up a VB6 demo to use it yet, it's pretty easy to use, but there will probably need to be some UNICODE conversion on the VB6 side for this one. I'll send it along to you soon.

A remember reading that a few people were upset about the Mame's output system being a Windows only solution, whereas a localhost loopback method would have been portable. For the LEDWiz server/client type app in .NET is probably easy to write like most things in .NET. But I would want to write it in pure C++ so there are no dependancies and so anyone can use it. But it's still got to be better than using the clipboard method

About making things modular so you can add support for other hardware. Right now my plugin supports BetaBrite, BPP-440, CrystalFontz, PJRC, ProLite using COM port output and LEDWiz hardware using MikeQ's ledwiz.dll. Adding Parellel Port output is easy but I havn't got around to that. In the future I probably will add support for defining your own custom protocol if you happen to have a device that is not supported internally. And even though my plugin is not currently written to support things like force feedback, I don't doubt that would be a simple matter of sending outputs to DirectInput in Background/Non-Exclusive mode kinda like how my Exit plugin works now. So really what I am doing is not far off from being modular in design, the problem is I code in C# these days, and writing this as a global solution like a resident toolbar icon app means a whole bunch of extra work so users outside of GameEx can do the same thing. Unfortunately I've done too much bloody work on it to decide that I want to release it for everyone, and since I'm a GameEx user it suits me and other GameEx users well enough.

MameInterop on the other hand is designed so authors can easily add Mame outputs to their own apps. I didn't really invision it as a global solution like where you are taking it. I have nothing against the work your doing, it's just not the direction I'm heading with the GameEx plugin. I will help you as much as I can though with your app, infact I have offered the CommIO.dll to you so you can add COM port output to it. But I must warn you Com output will be much more complex to add than Parallel output. It requires a fair bit of protocol reading - or you can make the users look it up and put the data into an ini file or something I guess.

While I'm on the subject of parallel port output, I notice you have a value assigned to a ledx output to send to the parallel output. Since it is paraellel, shouldn't it just be defined as a pin number, then you take that pin number and OR it with other pin's in case you have two led's lit up at once. Currently from what I see if you send the output for an led while one is already supposed to be lit up it will turn the other one off.

Me and loadman have helped each other out while working on our plugins so we can both get more features added into them using what's available in our own FE's plugin arcitecture. So when you say about loadman complaining about not having LEDWiz support in Mala, your actually talking to one of the guys who has helped code the the plugin to support it. He is also working on the LCD/LED plugin that outputs to the same devices mine does. While you may see it as all this work on our own solutions, you have to realise the plugin method is what works best for the FE's we use. And we both code in different languages (he codes in Delphi, I code in C#). So it's impossible for us to work together on a global solution. If you look at what Youki did to support LEDWiz, it sort of led the way (pardon the pun) to others adding internal support. You and me were the only ones talking about making some sort of global solution back then (which is why LEDWizLighter and LEDWizGen were made). But things ended up chaging and everyone went about doing their own thing. It's kinda too late to turn back now IMHO.

[youki]

It seems it is the moment to start an real open source Front End project.  It should solve all your issues...   

[headkaze]

It seems it is the moment to start an real open source Front End project.  It should solve all your issues...   

I don't know if this is really necessary, I don't see the point in starting from scratch on a FE when there are perfectly good ones closed source. A plugin system means you can develop for it without needing the source code so I'm happy with that sort of thing.

[youki]

It would be a good occasion to get all the best of each front end in only one!

[Howard_Casto]

Is there anything I can do to help?

We there's something you all can do actually.  Download that proggie I made and try it with any of the hardware you have available to you.  A lot of the code I couldn't test because I don't have the hardware.   I could test ledwiz and force feedback only.  Because I ditched all my hard-wired keyboards I don't even have the hardware to test the keyboard leds!  Also if anybody has some of the more high-end force feedback controllers (flight sticks and wheels) I need to know if the ff works for you. 

The configuration isn't exactly user-friendly atm, but I can walk anyone through it that wants to try it out. 

hk

About the parallel port thing.  What you don't see is internally I have a buffer keeping track of all the other pins states and when a state changes I update the buffer (a series of 0's and 1's) translate that into the integer number and send it.  I'm aware of the fact that you have to send the entire data state each time, but I made that function so users didn't have to do that themselves. 

And the serial port thing.....  I just wanted to put that in as a just in case thing.  I don't see anyone making a serial interface anytime soon.  I'll probably just setup raw commands so all the init, connection ect can be written by the user via the scripts.

Youki, when and if vista ever gets to the point of which we are all forced to upgrade I'll probably start an open-source front end in one of the .net languages.  Although I doubt it'd end up working I would be willing to give it a shot.  Other front-ends seem to be defficent in skin features, but on the other hand people like you are really good at adding animation script functionality.  I'm really good at list managment but I totally suck at making setup programs.  It could happen.

Something I'd like to see is a frontend that converts all the artwork (snaps/flyers ect) into native texture files when it generates gamelists.  It'd really eat up disk space to have a second set of artwork files lying around, but think about the speed boost!  Literally the only thing holding back what we can do graphically is the amount of external images we have to load up and convert.  Even as large as some of them are, if they were native before we loaded them up even the puniest of cards could handle the most complex of skins. 

[Howard_Casto]

Hk me and you have some more coding to do.  Looks like santa got my wish list.

From 112u2 what's new:

"
Added pause support to the output system: [Bob Seidel]
 - added "pause" message through the Output system to let clients
    know when MAME is paused
 - the state of an item is now sent when the item is first created
 - updated ledutil to use the pause state
"

This will be great for init, it solves a lot of the problems I ran into and had to make work-arounds.  Basically on your end the sdk dlls need support for the new pause message.  For the examples we can basically just send the pause message to the debug window and be done with it.

[loadman]

 - added "pause" message through the Output system to let clients
    know when MAME is paused.

That is so cool.   

A Led Attract mode could be triggered
You could update display on your LCD or whatever to say MAME PAUSED

Nice

[Howard_Casto]

A remember reading that a few people were upset about the Mame's output system being a Windows only solution, whereas a localhost loopback method would have been portable. For the LEDWiz server/client type app in .NET is probably easy to write like most things in .NET. But I would want to write it in pure C++ so there are no dependancies and so anyone can use it. But it's still got to be better than using the clipboard method

Yeah, that was intentional.  He figured no matter which solution he used there was still going to have to be platform specific code due to how different oses acess a tcp/com style interface.  So since they all need different functions anyway he might as well optimize the windows version.  The code is setup in such a way that others could add loopback support for linux/macos ect if they wanted to.  You gotta remember that at the time the only output device readily available was the ledwiz and I think it lacks linux support.

[Howard_Casto]

- added "pause" message through the Output system to let clients
    know when MAME is paused.

That is so cool.   

A Led Attract mode could be triggered
You could update display on your LCD or whatever to say MAME PAUSED

Nice

Well more importantly now we have protection.  Solenoids can't be left on.  I was worried about how I'd universally add solenoid protection code when in theory you can hookup a solenoid through any device.  Now I don't have to.

Also this solves the J5 ahk script issue.  Instead of syncing with the "p" key, I can listen for a pause message instead!  Pretty sure ahk supports message handling, but if not I'd be willing to write the dang code just to get rid of that error.

[Red 5]

I'm guessing this would work as a simple turnkey solution?



8 relay outputs, kit form $34.95

Click here for more details


Jon

[Howard_Casto]

Yes it would.  A tad pricey (could be built for a fraction of that).  But that essentially uses the 8 data pins on the parallel port to trip 8 relays.  It'd be a nice solution for solenoids or high amperage lights. 

[headkaze]

Hk me and you have some more coding to do.  Looks like santa got my wish list.

From 112u2 what's new:

"
Added pause support to the output system: [Bob Seidel]
 - added "pause" message through the Output system to let clients
    know when MAME is paused
 - the state of an item is now sent when the item is first created
 - updated ledutil to use the pause state
"

This will be great for init, it solves a lot of the problems I ran into and had to make work-arounds.  Basically on your end the sdk dlls need support for the new pause message.  For the examples we can basically just send the pause message to the debug window and be done with it.

This is great! Okay, I'll download the 112u2 source and update for pause.

EDIT: I'm not sure if an update is necessary, since the current version of MameInterop works with pause.

The outputs look like this:

Code: [Select]

update_state: id=12345 (pause)  state=1 <-- paused
update_state: id=12345 (pause)  state=0 <-- unpaused
Do you think we should add another callback just for pause? Eg. mame_pause(int state) ? Or just leave it as is and let the user deal with it? I don't mind either way really.

P.S Just sent you my CommIO.dll with a VB6 example

[Howard_Casto]

Well that's an odd way to do it, but I guess whatever works.  Your right, no need to monkey with the dll. 

We might want to update the examples though to do something special with pause (like clear the text box or something.  But I dunno, it's probably ok as-is. 

I've been busy with house wiring today (ugh!) I'll take the comIO and the stuff loadman sent me and update my app shortly.  Then barring some testing I'll go ahead and make an official release announcment and release the source.

p.s.  I'm glad I didn't do the is2string thing now.  You know that "barring a major re-write" comment I made?  Well all the led1's will be a different number now, so it would have thrown everything off.

[Howard_Casto]

Ok, I added a universal pause code, so that's done. 

Things to add next:

wat milliseconds     A function to wait between commands, useful for animation.

iowarrior/mala functions.....

generic serial functions courtesy of headkaze

[loadman]

 

[Howard_Casto]

Ok wait is added and the com port functions are added.

I also added the ability to load long/complex script sequences via an external file.  It should make for trading scripts easier and it should help to keep ini files neater. 

That's all I'm doing toinght... mala stuff will have to wait till sometime tomorrow.


Things left to do:

mala/iowarrior

Modify the rgb function so that if you set the start position higher than 30, it'll automatically pick up the remaining outputs on the next ledwiz.

wiimote support??

[headkaze]

Nice work Howard 

I have a question for you too, do you know why the Mame developers havn't added force feedback support into Mame? Why is it only implemented in the output system?

[Howard_Casto]

Well, the main reason is they don't want to I guess.  I've brought it up a few times and while nobody said, "hell no we won't add it" or anything like that nobody seemed thrilled about gving it a shot, mainly because converting "real" force feedback (like afterburner) into directx force feedback is going to take a lot of work, probably a good weeks worth of actuator mapping to create the proper feel per game.  And then once it's done you try it on another controller and it doesn't feel right.  FF is very device dependant.  Like I'm using a xbox controller, cause they are cheap, so it's going to make it really hard for me to make effects for games like outrun.

[Howard_Casto]

Ok I need to squash some bugs first, but things coming down the pipe:

Added function to launch command line applications (useful for j5 and the like)

Added %rom% and %comma% tags, for obvious reasons.

IO Warrior functions are in place, but they are as of yet untested.

[headkaze]

Using the method I described in a post earlier I can process ListInfo.xml in under a second.

Here are my test results...

Here I run my test application for the first time, it has to create ListInfo.xml, parse it, write a compact version to ListInfo.ini then output the values for 1942.

Code: [Select]

24/02/2007 9:48:17 PM : Start
24/02/2007 9:48:18 PM : Mame Version: 0.100
24/02/2007 9:48:18 PM : Detected New Mame Version
24/02/2007 9:48:18 PM : Creating ListInfo.xml
24/02/2007 9:48:23 PM : Reading ListInfo.xml
24/02/2007 9:48:25 PM : Writing ListInfo.ini
24/02/2007 9:48:25 PM : 1942 ParentROM:
24/02/2007 9:48:25 PM : 1942 NumPlayers: 2
24/02/2007 9:48:25 PM : 1942 NumButtons: 2
24/02/2007 9:48:25 PM : End
7 Seconds.
This takes 7 seconds here, which is expected for all the processing going on. But now that the compact version of ListInfo.xml now called ListInfo.ini has been created, so next time it should only process that file.

Code: [Select]

24/02/2007 9:48:30 PM : Start
24/02/2007 9:48:30 PM : Mame Version: 0.100
24/02/2007 9:48:30 PM : Reading ListInfo.ini
24/02/2007 9:48:30 PM : 1942 ParentROM:
24/02/2007 9:48:30 PM : 1942 NumPlayers: 2
24/02/2007 9:48:30 PM : 1942 NumButtons: 2
24/02/2007 9:48:30 PM : End
0 Seconds.
This time it takes less than a second to get the info we want from ListInfo.ini. But what if you update Mame? This program reads the Mame version and will process ListInfo.xml again if it detects a new version.

Code: [Select]

24/02/2007 9:48:54 PM : Start
24/02/2007 9:48:54 PM : Mame Version: 0.112
24/02/2007 9:48:54 PM : Detected New Mame Version
24/02/2007 9:48:54 PM : Creating ListInfo.xml
24/02/2007 9:49:04 PM : Reading ListInfo.xml
24/02/2007 9:49:07 PM : Writing ListInfo.ini
24/02/2007 9:49:07 PM : 1942 ParentROM:
24/02/2007 9:49:07 PM : 1942 NumPlayers: 2
24/02/2007 9:49:07 PM : 1942 NumButtons: 2
24/02/2007 9:49:07 PM : End
12 Seconds.
So this way of doing things it only takes time when you upgrade to a new version of Mame or run it for the first time, otherwise it takes less than a second to process.

[headkaze]

Do you think the Mame developers would be cool with adding "coindrop", "gamestart" and "gameover" events like they have with pause?

These would be cool for doing special effects when these events happen. Like user defined LEDWiz attract sequences or for LCD's you could have the message "GAMEOVER" written on them etc.

PowerMame for example had LEDWiz attract sequences during these events.

[Howard_Casto]

They might actually... aaron specifically updated the counter objects to avoid output use for coin dropping.

[headkaze]

Oh yeah never thought of that, that would open for abuse using coin counting. And we all know the drama that CoinDrop caused.

Hmm maybe just gamestart and gameover events then? Or perhaps only send the coindrop event the first time a coin is dropped in a game.

[Howard_Casto]

If you can figure out how to do it... I honestly have no clue how powermame pulled that off.  I mean, mame just emulates the hardware and "plays" the rom.  I dunno how you detect when you are out of attract mode. 

[headkaze]

PowerMame just used a timer for attract mode..

When a game starts up, attract mode will continue to execute until a button is pressed. There is also a timeout value that can be set. When the game has run for "timeout" seconds without controls being touched, it will start attract mode again until a button is pressed.

For the gamestart and coindrop events they could just be sent when those buttons are pressed. I guess there would be no way to detect a gameover sequence though.

[Howard_Casto]

Well you can't detect mamestart game start either without some serious hacking about in the memory.  See some games have cmos coinage so you can start a game without inserting coins (assuming there are some coins in the cache).  You'd have to read the current coinage, and I don't know how difficult that is.

[Howard_Casto]

just a quick update:

Loadman and I have finally sorted out the mala commands for the most part so a release will happen sometime this week.  I've been messing with the newly implemented read from script command to see what useful things I can do with it. 

Probably the most useful is to make a mamestart script and bind it to the mamestart output.  Inside I can do various cool things like light my start buttons up (seeing as how some mame games don't use coin lights) and do a little startup animation.  But the most practical thing you can do is use it in conjunction with the new shell function to launch an external app to light up your button lights for said game (like johnny 5 with the "-justlight" flag).  Since I've coded the app NOT to clear all the lights for ledwizzes and iowarrior based stuff, you can get your panel lighted this way and then still use extra outputs with the hooker to control coin lights and what-not.  It makes for a much smarter solution then to clutter the hooker app with all kinds of code to light your panel.

Also it means that your fe doesn't need support for these functions.

[loadman]

Loadman and I have finally sorted out the mala commands for the most part so a release will happen sometime this week. 

Great work dude...

With your test ap the numbering differs from what is labled on the MaLa Boards and the  Modded Led-Wiz that use the same io-warrior40 chip

So we need to settle on how to deal with that

Here are four variations of io-warrior40 use as a LED controller that I am familiar with:




Here is table of what LED goes on when clicking on the appropriate button (labled 1-32) on your test ap:

The 1st column is Your Ap Button number
The 2nd column is how the Led is labled on the Mala Hardware board
The 3rd column is how the Led is labled on the Modded Led-Wiz

1  - 32 - 8
2 -  31 - 7
3 -  30 - 6
4 -  29 - 5
5 -  28 - 4
6 -  27 - 3
7 -  26 - 2
8 -  25 - 1
9  - 24 - 16
10 - 23 - 15
11 - 22 - 14
12 - 21 - 13
13 - 20 - 12
14 - 19 - 11
15 - 18 - 10
16 - 17 - 9
17 - 16 - 24
18 - 15 - 23
19 - 14 - 22
20 - 13 - 21
21 - 12 - 20
22 - 11 - 19
23 - 10 - 18
24 - 9  - 17
25 - 8  - 32
26 - 7  - 31
27 - 6  - 30
28 - 5  - 29
29 - 4  - 28
30 - 3  - 27
31 - 2  - 26
32 - 1  - 25

NOTE: Both the units above (2 and 4) that also drive a LCD display of course could only respond to 16 buttons (17-32) on your test ap as the other 16 are obviously used for the LCD.

[Howard_Casto]

Yeah the pattern is pretty apparent now....

For mala stuff I just need to reverse the pin order completely, this is simple enough to do, I can just step my function with a -1 when I "build" the binary array.

Now the ledwiz stuff uses the same bank order, but the pins in the bank are reversed.  This is a little odd, but still doable.  Makes me wonder why the pin order on "official" io warrior stuff is so different though.  I mean I can see it on the ledwiz hack, but not the mala stuff. 


Now here in lies the problem with me monkeying with the pins.  You see, all of these devices are going to show up as the same thing when I enumerate the hardware.  I have no way to determine which order to use, so the user will have to figure that out for themselves. 

[loadman]

Yeah the pattern is pretty apparent now....

For mala stuff I just need to reverse the pin order completely, this is simple enough to do, I can just step my function with a -1 when I "build" the binary array.

Now the ledwiz stuff uses the same bank order, but the pins in the bank are reversed.  This is a little odd, but still doable.  Makes me wonder why the pin order on "official" io warrior stuff is so different though.  I mean I can see it on the ledwiz hack, but not the mala stuff. 


Now here in lies the problem with me monkeying with the pins.  You see, all of these devices are going to show up as the same thing when I enumerate the hardware.  I have no way to determine which order to use, so the user will have to figure that out for themselves. 

I think that it's just a labeling thing on the board. The chip behaves the same no matter what.

For the MaLa hardware I assume the numbering was deliberately reversed to simplify things. How you ask? Well if you use it as a 32 Led controller Pin 1 could drive Led 1. But if you use it as a LCD / LED controller Pins 1-16 are used  for that display so your first led would be 17. So to simplify things (Invisible to the user) it was reversed so no matter if you used a LCD or not Leds 1-16 would always be the same so you did not have to change your wiring or set-up.  My best guess anyway.  Swindus could confirm that I guess.

 In the case of the Wiz Mod the numbering on the board and the boards layout is for a different chip who's banks would by diffrent. I mean an easier fix is to just relabel the board with a pen to match MaLa H/W. (the reverse of your ap)   :-)

So even if you do nothing else it will be OK just as long as uses are aware.

Thanks again for supporting it

[Howard_Casto]

Well I've went ahead and took my function from the test app I sent you and intergrated it into the mame hooker app.  I then went ahead and made three seperate sets of functions, for the iowarrior, the mala board and a hacked ledwiz.  They re-number all the pins internally via a simple re-organization function. 

Now the tricky part is going to be reading the values (at least in my head). 

Let me explain...

See I figure for lighting panels at least, the ledwiz and iowarrior hardware are basically your only two chocies as they are the only popular devices with enough outputs.  Because we don't want to do compliacted things like light up the current game layout in the hooker app (see my post on it above) so what I do is leave the layout alone after the mamestart function is ran so that the layotu can be set via an external app and yet extra outputs on the device can still be used for mame-controlled outputs.  With the ledwiz this is simple, as you can set one led at a time (which is what I do) on the iowarrior stuff, however I have to basically set them all at once by maintaing a buffer. 

So I'll have to clear the iowarrior devices upon gamestart and then after the mamestart function is ran, I need to read all the states and update the buffers, so they don't all get turned off once I mame output flashes. 

I've gotta wrap my head around it, but it shoudn't be terribly hard. 

[Howard_Casto]

Took a break from the mess that is the iowarrior stuff (although it's almost complete).  I went ahead and added that graphical display stuff I talked about. 

Right now it only supports images, but eventually I'll support text as well. 

Aside from that, I'm rather suprised at how well it works.  There don't seem to be any focus issues, and even vb's crappy gdi rendering seems more than fast enough to keep up with the flashing lights of, say digdug.  It doesn't seem to be much of a memory hog either.  Of course I'm sure really hi-res/complicated displays would eat up the memory.

[headkaze]

Hey Howard, nice to hear things are progressing. I've got a couple of MameInterop functions working in my plugin, basically led0 and led1 flashing start1/start2 buttons and pause flashing. You can check out some videos on the bottom of my LEDWiz makeover page.

It would be nice if the Mame developers added more events to do things with. Wasn't it you (Howard) that got the pause event added from your request? Can we get more added or let me know where I can request things regarding this.

Are the Mame developers aware of MameInterop? If they knew that people were actually making use of the outputs they might consider adding more support for it.

Do you think it would be useful for Mame to output info about the current game, like orientation and resolution? Perhaps we should figure out what other outputs would be useful before making a request.

[Howard_Casto]

Nah I hadn't formally requested it.  I'm sure I complained about it at some point though. 

Aaron is probably your goto guy.  Links to his email and such are on his homepage. 


Aaron was aware of the fact that I was going to start an app the used the outputs sometime this winter.  As to if he knows how far we've gotten, I dunno.

I'm not sure about adding a lot of extra junk through the output system.  Mind you it'd be convenient, but there are other ways.  We have the rom name, so we can call another instance of mame to print out listinfo for that rom and get any data we need.  Considering there is the slightest bit of lag when you ask for strings from mame, it might actually end up quicker to just call the listinfo.

It'd sure be nice to get the parent/rom/driver relationship though. 

Looks good btw..... I'm not a big fan of all the buttons, but still...

[Howard_Casto]

My question is do any of you guys know the daphne devs and can we get support added for daphne?


We've got several outputs in daphne, scoreboards in thayer's dl and space ace, a "shoot" lamp in badlands, rank lights in space ace and a high/low gear indicator in gp world.  Most of the outputs are alredy hooked up either by parallel port or keyboard leds.  It would be a fairly simple matter to add a function.... of course it'd be windows only, I don't know how well they'd like that.

Mame, daphne and pinmame are pretty much the only emulators I know of that deal with games that have actual outputs.  I think once we get those we are done.

[edge]

howard / hk,
On my trackball cab, I have RGB LEDs in my trackball with a LEDWiz.  By far, the most popular game on there is World Class Bowling.  In WCB, is there any output to track player changes?  It would be amazing if I could change the color of my trackball to match the color of the player's bowling ball on the screen (ie, P1 = blue, P2=red, etc).

very nice job, thus far, guys.

[Howard_Casto]

Nope... much like the gameover, gamestart flags hk is trying to implement, this is quite impossible if you wish to do it accurately.  Think of mame like a dvd player... it has no clue what is on the dvd (or in this case rom) it just plays it.  So there's no real way to know when the current player changes. 

Besides that, the goal here is to be able to hookup real outputs, not fake ones.  Now some of the ones implemented aren't real (like pause) but they serve a functional purpose and thus must be included.  There isn't any way the mame devs are gonna approve of a bunch of odd-ball hacks to do extra stuff though. 

[Howard_Casto]

Looking at the iowarrior mess, I've determined that there isn't any easy way to read the current states of the lights automatically.  Instead, I'll be adding "read status" functions for all three types. 

This may be a pain to users, but it is the only accurate way I can get the current light state, which is useful if you launch an external app to light your layout.

In light of this I'll also be adding a "shell and wait" function to go with the shell function I've already added.  There's no point in reading the state while it's being set. 

[Howard_Casto]

Hk:

Would it be possible for you to add the ability to get mame's hwnd into your dll?  I know that mame sends it to you and it might be useful for something I'm working on....  (integrated external control viewer support).  Of course I can search for the hwnd myself, but seeing as how the dll already has it....

[Howard_Casto]

I went ahead and added a bit of code in the mamehooker to list all compatable devices hooked to ones system.  It gives the id# as well, which should help users to understand which device to call when writing scripts. 

[headkaze]

Hk:

Would it be possible for you to add the ability to get mame's hwnd into your dll?  I know that mame sends it to you and it might be useful for something I'm working on....  (integrated external control viewer support).  Of course I can search for the hwnd myself, but seeing as how the dll already has it....

I could send the hwnd but I would either have to enumerate all the window captions looking for "MAME:" in the titlebar, or use FindWindow with MAME as the class. The reason is the dll never actually gets the hwnd of Mame sent over, it only gets the hwnd of the "Mame Output" window used in the communication which is not even a child Window of Mame (so I couldn't even use FindWindowEx API function to look for it as a parent window).

I did just do a test using enumeration and I can add that into the dll if you really want. I just don't think it's very elegant and something the end user can do just as well using the above methods when they get a mame_start() callback.

[Howard_Casto]

Eh, I'd rather just get it myself then.

[Howard_Casto]

added a shellandwait function along with a restorewindow function....

Using these in sequence, along with the "pause" event allows the user to launch a cp viewer on mame pause and have mame restored once they exit the viewer....

Essentially it replaces the ahk scripts I've used to do this with johnny5. 

[headkaze]

added a shellandwait function along with a restorewindow function....

Using these in sequence, along with the "pause" event allows the user to launch a cp viewer on mame pause and have mame restored once they exit the viewer....

Essentially it replaces the ahk scripts I've used to do this with johnny5. 

Pause is a handy event for things like this. Also saves having to tell your CP viewer what key you have assigned to pause if it's not "p". The only thing is, when you press p again to go back to Mame does it register the key while not in focus and unpause and send the pause event again? Or do you have to unpause mame by sending a key to it?

[Howard_Casto]

Well the plan was to also add a "send key" function... This would also add wiimote support as the two major wiimote interfaces basically allow you to bind parts of the device (like the leds and rumble) to keys.  The problem I've been having is I can't find a simulated keypress api call that actually works for mame....

I've tried good old sendkeys, setkeyboard state, keypress, ect.... nothing will penetrate it's directinput nuget center. 

As of now it returns you to mame, still paused.  It doesn't have syncing issues though as we actually know the pause state now. 

[headkaze]

Well the plan was to also add a "send key" function... This would also add wiimote support as the two major wiimote interfaces basically allow you to bind parts of the device (like the leds and rumble) to keys.  The problem I've been having is I can't find a simulated keypress api call that actually works for mame....

I've tried good old sendkeys, setkeyboard state, keypress, ect.... nothing will penetrate it's directinput nuget center. 

As of now it returns you to mame, still paused.  It doesn't have syncing issues though as we actually know the pause state now. 

Well I've cracked that issue when I wrote CoinDrop using a DirectInput wrapper dll that sits between DirectInput and Mame allowing you to inject input into it. I'll see if I can knock up some sort of dll if you want.

[Howard_Casto]

Well I've already got directinput code in the app for force-feedback anyway.

If you can show me how you did it then I can just add a function and save you the trouble.

[headkaze]

Well I've already got directinput code in the app for force-feedback anyway.

If you can show me how you did it then I can just add a function and save you the trouble.

It's alot more involved than just running DirectInput in background mode. It actually hooks into the DirectInput API and sits between the two allowing injecting keys. You have to use a dll to do this method.

[csa3d]

mamehooker

 

[Howard_Casto]

That sounds like a lot of work man for one feature.  Mind you it'd be useful, but I can do it other ways (like compiling a ahk script, which somehow magically does it.)

Sorry about the lack of a release guys... I've had some real-world resposibilities lately.  I'll throw a version over to laodman so we can double-check the iowarrior functionality and then hopefully we can get it out the beginning of next week. 

I think the source is about ready for a release too.  I've cleaned up most of my bad code. 

[loadman]

I'll throw a version over to loadman so we can double-check the iowarrior functionality

Ready When you are..

I've pulled out the MaLa hardware  (based on Iowarrior 40's) from my Cab and have the Led-Wiz ready to Mod  with the Iowarrior 40 chip. They are all on my Desk/TestBench ready to test.

 

[Howard_Casto]

Glad your ready lm, but It's probably gonna be a day or so, I've barely felt like testing the new code today (still need to double-check things). 

Btw hk about the key-press thing..... I found a much simplier solution......  I just compiled a very simple ahk script into a exe that takes a keyname passed to it and presses it.  It wouldn't work for everything (might be slow if pressed often), but it works great in this instance. 

I'm also looking into adding partial daphne support... the only problem is I haven't been able to figure out what method they are using to press the keyboard lights.  There are quite a few ya know.

[Howard_Casto]

Ok things are starting to slow down here, hopefully I can finally get a beta out to lm and we can get started again.  (Grandma was in the hospital, but don't worry, she's fine and will be released today probably.)

Here are some random thoughts....

I looked at different inter-communication methods besides the windows messages mame uses and my favorite thus-far has been dde communication.  I know that this method is going the way-side, but it's really the best.  I've added dde support to j5 just to see how I like it and it works really well.  Basically the next version of J5 will be able to pass commands to itself if you run it multiple times......  (So you can load the mk layout on the first launch and then type "johnny5.exe mk2" while it's still running and it'll load the mk2 layout... true non-hacky residency)

I will post the server and topic names in the doc, so developers can communicate via direct dde if they so choose. 

My question is, do you think this would be useful for the mame hooker app?  I thought perhaps for misc stuff (lesser known emulators, front-ends ect) It might make more sense for them to simply use the dde than windows messages as, quite frankly windows messages are overkill for some simple stuff (like loading a layout).  Also I could set it up like I did j5, where you could simply launch the hooker with a command line and it would pass it to the resident app.  I don't know how you could possibly make communication easier than that....

[rockin_rick]

Well, the main reason is they don't want to I guess.  I've brought it up a few times and while nobody said, "hell no we won't add it" or anything like that nobody seemed thrilled about gving it a shot, mainly because converting "real" force feedback (like afterburner) into directx force feedback is going to take a lot of work, probably a good weeks worth of actuator mapping to create the proper feel per game.  And then once it's done you try it on another controller and it doesn't feel right.  FF is very device dependant.  Like I'm using a xbox controller, cause they are cheap, so it's going to make it really hard for me to make effects for games like outrun.

I don't know what's all been done with force feedback, and perhaps this has already been suggested or considered, but how about dealing with converting the FF actuator mapping using transfer functions?  Have mame output a value of FF, then run it through a transfer function to map it to the controller used.  The function would allow for different maximum force per device, and different ramp rates.  You could have different transfer functions for different devices, and different functions for different games.  This would allow end users (?) to tweak their FF to their liking.  Someone/anyone could generate transfer functions for different devices outside of mame. 

(Perhaps this has no merit to the problem, as I don't have a full understanding of the issue/sitaution...)

Rick

[Howard_Casto]

Mamehooker supports ff now, so what exactly would be the point?

[headkaze]

It's been reported to me by Arzoo that mame.dll is no longer working. After inspecting the latest MAME (0173) source I have noticed the following missing source files:

src\osd\windows\output.cpp
src\osd\windows\output.h
src\osd\windows\ledutil.cpp

I can only conclude that the MAME Output System has been removed. If so this impacts a variety of software such as LEDBlinky, Mamehooker, CPWizard and the LED Plugin for GameEx.

Please post back here any information regarding this issue.

Haze: If you read this can you please let us know what's going on and how we can communicate with MAME going forward.

[Howard_Casto]

Someone had complained to me that with 173 mame games (arcade stuff) did fine but console games crashed mamehooker.  I hadn't looked into it yet assuming they just added a new flag that the dll was having issues with.  Let me give it a look. 

*update*

The calls to the output functions are still within the drivers, but unless I'm overlooking it the output stuff itself is missing.  Is this an oversight?

[arzoo]

I tried posting a new thread on the official mame forum to see if I could get any info on the missing output functionality but after 24 hours the thread has still not been reviewed/posted. There's only two threads on the forum so I'm not even sure if it's active? Any thoughts on who to contact about this issue?

[Howard_Casto]

I'm not sure.  Normally Haze would be the goto guy around here but apparently he's retired according to his blog. 

Maybe mametesters?

[arzoo]

Looks like they fixed the outputs for ledutil... http://mametesters.org/view.php?id=6134

[heyyouguys]

Looks like they fixed the outputs for ledutil... http://mametesters.org/view.php?id=6134

So >= .171 is working fine for led'sand ledblinky?

[arzoo]

Looks like they fixed the outputs for ledutil... http://mametesters.org/view.php?id=6134

So >= .171 is working fine for led'sand ledblinky?

Unfortunately not. Maybe they just fixed ledutil.

[arzoo]

I've posted on two mame forums asking for a clarification on the missing Output functionality. No reply yet.
http://forum.mamedev.org/viewtopic.php?f=14&t=68&sid=2e69194327855101c0b2ecd6f9c16ce9
http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=354122&page=0&view=expanded&sb=5&o=&fpart=1&vc=1

[headkaze]

So MAME's new output system creates a TCP server on 0.0.0.0 port 8000 for outputs.

I'll look into updating the MameInterop dll's to support communication this way so we can maintain backward compatibility.

[arzoo]

So MAME's new output system creates a TCP server on 0.0.0.0 port 8000 for outputs.

I'll look into updating the MameInterop dll's to support communication this way so we can maintain backward compatibility.

Thanks hk - really appreciate your help with this!

[Howard_Casto]

Hmmm.....  TCP server on paper should be easier.  Damn that means having to deal with windows and your anti-viruses draconian strangle hold of all things internetz though.  We are going to get a lot of complaints about stuff not working when in reality windows firewall just has the app blocked. 

Could you tell me where I can find the specs on the new system? 

Btw unlike previous changes to mame we should be able to support both.  New Mame just won't send any window messages so the interop stuff would remain idle.... in theory at least. 

[headkaze]

The areas to check out are osd\modules\output and the server specific code is in osd\modules\ipc.

I'll probably just use MAME's own server code in the dll's like I did with the old output system. I'll make it so you can still use the same callbacks as before so it shouldn't be any different to how you use MameInterop now (ie. drop in replacement). The only difference is I will probably make a 64-bit version of the dll also.

The one annoying thing that appears to be missing is the ability to send commands back to MAME like pause/unpause. It would be nice to get those added back in somehow.

[Howard_Casto]

Yeah did they include an example app this time?  Sorry I've been out of the mame game so long I don't know where anything is anymore.  I looked at the source.... there wasn't much in the output/ipc folders, so I'm guessing the actual possible commands are elsewhere?  Again, I'm a bit lost. 

The actual TCP connection is fairly easy... two lines of code and I'm good to go.  I just need a bit of guidance on the specifics. 

Yeah I'm a bit confused as to why the pause/unpause commands were removed as well.  One of the main things TCP connections have going for them is easy two-way communication and mame certainly has that ability now that lan connections are an option.  If anything we need MORE two way communication.... like the ability to send limit switches or outright inputs for E.M. sims. 

[arzoo]

Here's a response from MAMEWorld;

you'll want to take a look at src/osd/modules/output. The "network" provider is preferred, although I don't know how well any of this stuff has been tested. In theory it'll now also be possible to have an output provider that just lights up the GPIO pins on some of the beefier ARM dev boards like the ODROID-C2.

Also, the new "network" provider works the same on Windows, Linux, and Mac, which the old output stuff definitely did not.


http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=354131&page=0&view=expanded&sb=5&o=&fpart=1&vc=1

[headkaze]

I'm going to have a look at all this today.

[Howard_Casto]

I managed to make a connection, but it didn't do anything.  I'm guessing some sort of handshake is required.  Anything I tried to send threw up an error, so I'm probably missing a key step. 

btw, I know you mentioned this in another thread, but the lua scripts have the pause/unpause commands.  Mind you that still doesn't help us because you have to load a script and thus they can't be called externally.  I think whoever converted it over didn't understand the nuts and bolts of how we use the output system and why we need things a certain way.  It's an honest mistake, but it could have been rectified if they had gotten into contact with any of the 3 or 4 people that write software for the thing.  I'm just sayin'   

[headkaze]

I've got communication working. If you want to see it working before you attempt to implement it in code do the following:

1. Edit your mame.ini file with the following line:

Code: [Select]

#
# OSD OUTPUT OPTIONS
#
output                    network2. Go to Programs and Features->Turn Windows features on or off and enable the Telnet Client.
3. Run "mame64.exe -verbose digdug" from the command line and it should prompt you to open the port in Windows Firewall
4. From another command line run "telnet 127.0.0.1 8000" and you should get the following output:

Code: [Select]

led1led05. When you exit Mame the command line should show something to the effect of:

Code: [Select]

tcp_server pointer was not allocated by the usernew TCP connection:[TCP, local:0.0.0.0 :8000, remote:127.0.0.1 :58377, status:open]
Average speed: 100.01% (18 seconds)
closing 1 active connectionsTCP connection closed:[TCP, local:0.0.0.0 :8000, remote:127.0.0.1 :58377, status:closed]
I have the Mame dll's working now but I have to add the ability to reconnect when games change. I'm also not sure if there is a start / end message when you launch and end a game. Also there doesn't appear to be an id for each message. Anyway now that you can get communication working we should hopefully be able to figure out exactly what is and isn't implemented in the new system.

[Howard_Casto]

Ah ok, it was the ini entry that I was lacking.  That was driving me crazy.... tcp is so easy even an idiot like me can do it. 

Yeah I played with it a few and it seems like they killed a lot of features.  Start/stop is crucial imho. 

I'm not making much sense of the data it's feeding us either. IDs aren't crucial imho, but without them I might have to either rewrite portions of mamehooker's code or do what I do with other emulators and supply my own.  Let me play with it some more.......

[Howard_Casto]

Yeah unless I'm missing something (which is completely possible) this new system is broken.  Try a game with 7-segment displays and it just keeps sending the name of the digit that is changed, it doesn't send the value.  Are we supposed to poll mame for the value?  If so why not just send the value along with the name since plain text it being sent?

[Howard_Casto]

So I tried console mode for outputs and it is showing the values as expected.  Is the tcp system delimiting things with a null character?  Because if it is, there's your problem.   

[headkaze]

I'm receiving the data via Winsock's recv function which will return a precise length of the data received. I manually add a NULL character to the end of the buffer to pass it through the callback.

Eg. I will receive a packet of "6c 65 64 30" and then "6c 65 64 31" which translates to "led0" and "led1" in ASCII respectively. Also it's worth noting that I will occationally receive two sets of data in one packet (Eg. "led0led1").

What game are you using to test the segment display? Can you give an example of what the output is for console mode so I can compare my results?

Sometimes I will receive "Orientation(\\.\DISPLAY1)" when launching a game but again no start/stop messages. Also when MAME closes I need to re-establish a connection so even if there was a start message sent I might miss it. Right now I will poll for data every second so I can process the message pump incase the thread needs to quit. I can lower this value and it should improve reconnection and perhaps the combined data issue will be reduced too.

EDIT: I see what you're saying when you change the output to "console". I get:

Code: [Select]

led0 = 0
led0 = 1This data makes more sense. So it appears the "network" output system is broken. So the next step I guess is to report the bug or patch to Mamedev.

[Howard_Casto]

Yeah I apologize for my ignorance because c style overrides never made much sense to me, but unless I'm interpreting the source wrong there are two output functions, one (overridden) for the console and another for network.  The console one sends along "%s% = %d%/n" but the network one sends( I think) the name as a char string (they forget to null terminate) followed by the value as int32.  The problem with that is custom data types can't be passed with winsock and most of the easier connection methods.  I would like you to confirm this for me since, as you know, C programming isn't my area of expertise.  Personally I would rather get the data like the console prints it.... we can split a " = " fairly easy in any language.  Orientation could be used as a mamestart since it doesn't update, but those functions really need added back in. 


Any of the neogeo games would work as they have a 2 digit display for the credits.

I'll let you do a report fi that how you want to do it as I think some of those guys don't like me. 

I think we could fix it fairly easily, but man, I haven't setup a mame compile environment in a good 5 years. 

[headkaze]

the network one sends( I think) the name as a char string (they forget to null terminate) followed by the value as int32.

What particular line of code are you referring to?

As far as I can tell the data being sent is exactly as I described it in my previous post. ie. 4 bytes (eg. "led0" and "led1"). I do not receive any 32-bit integer following this data. The winsock recv function tells you how many bytes are received and it does not account for any NULL since it's a network stream of bytes. This is why you can receive two messages in one.

I think we could fix it fairly easily, but man, I haven't setup a mame compile environment in a good 5 years. 

You can always use Mame Compiler 64 Anyway we don't necessarily need to come up with a patch we just need to verify the data is not being sent and report it.

EDIT: Just to be sure it isn't something I'm doing wrong I used PuTTy with logging enabled and I can confirm that I'm only receiving the output name and not the value.

[Howard_Casto]

Sorry man, I was reading it backwards. 

What I'm talking about is here in network.cpp:

Code: [Select]

virtual void notify(const char *outname, INT32 value) override { m_server->send_to_all((const uint8_t*)outname, strlen(outname)); }

So let me re-phrase that.  The original function is given the name and value, but the override just sends the value. 

Now if you look at console.cpp the notify function is like this:

Code: [Select]

virtual void notify(const char *outname, INT32 value) override { osd_printf_info("%s = %d\n", ((outname==nullptr) ? "none" : outname), value); }

So in this one the name and value are formatted and sent along to the console output as a string.

Yeah I'm using winsock as well btw... it's just easier, but I'm unsure if bytes received can be influenced by the variable type and the data. 

I thought originally that we had to poll mame to get the value, but afaict there aren't any functions to receive data. 

[Howard_Casto]

So in addition to fixing that line, some sort of init and close signal needs to be sent on... well... the init and close functions.  I'm not sure the best way to implement that as the rom name would have to be pulled from somewhere... machine_init?  I think the rest of it is still there.

[headkaze]

So in this one the name and value are formatted and sent along to the console output as a string.

So it needs to be changed to something like this:

Code: [Select]

virtual void notify(const char *outname, INT32 value) override
{
static char buf[256];
sprintf(buf, "%s = %d\n", ((outname==nullptr) ? "none" : outname), value);
m_server->send_to_all((const uint8_t*)buf, strlen(buf));
}

Yeah I'm using winsock as well btw... it's just easier, but I'm unsure if bytes received can be influenced by the variable type and the data.

No, it's just a stream of bytes.

I thought originally that we had to poll mame to get the value, but afaict there aren't any functions to receive data.

As far as I can tell the communication for the netwrok system is one way. I don't see why they would require us to read the name then send back a request for the value. It would just be extra work for something that works fine one way.

[headkaze]

So in addition to fixing that line, some sort of init and close signal needs to be sent on... well... the init and close functions.  I'm not sure the best way to implement that as the rom name would have to be pulled from somewhere... machine_init?  I think the rest of it is still there.

The original output system sent machine.system().name.

[Howard_Casto]

Yeah but I was thinking that there was something goofy about getting the name.  It only works after certain stages of the init are completed or something.  I honestly don't know though.  Mame has changed so much since I used to submit any meaningful code. 

I think your solution is ideal and honestly I'm not sure why there is a console and network mode.  The console output could always be on and wouldn't hurt a thing and if nothing tries to connect to the server port the network happily sits there as well.  A simple "-outputs / -nooutputs" makes more sense to me.

Most of the other stuff is still in there.  I've gotten pause/unpause events and orientation.  That thing about sending multiple outputs at the same time needs fixed though.  Perhaps a null character at the end of each output as a delimiter.  I would say send them separately, but with some of the gambling games the lag introduced might make the outputs constantly behind. 

[headkaze]

I think your solution is ideal and honestly I'm not sure why there is a console and network mode.  The console output could always be on and wouldn't hurt a thing and if nothing tries to connect to the server port the network happily sits there as well.  A simple "-outputs / -nooutputs" makes more sense to me.

We could in theory read stdout for outputs but that would require the client software to launch MAME and redirect its output. I wouldn't want the console output on by default though as in my experience it can effect performance. I think the server method is the way to go but we do need to get the formatting fixed.

Most of the other stuff is still in there.  I've gotten pause/unpause events and orientation.

I did notice the "pause" event although again the network message does not send the actual state so you can't tell between a pause or unpause.

So I guess the next step is we need to report this to Mamedev.

[Howard_Casto]

Have you reported this yet?  Thinking on it more maybe we should fix the error ourselves so it'll be in the proper format.  You might have to school me on your compiler. 

[Arbee]

HeadKaze's patch in reply #129 looks like it does what you need as far as the message formatting.  If it tests out OK, please submit it.

[headkaze]

Have you reported this yet?  Thinking on it more maybe we should fix the error ourselves so it'll be in the proper format.  You might have to school me on your compiler. 

There is really nothing to "school" you on Mame Compiler it's pretty straight forward. Today I added support for creating diff patches so it should make it even easier for us to submit changes going forward.

I have created a "mame0173_network.diff" patch and will submit it today. According to the Submission Guidelines all I have to do is e-mail it to them with an explaination.

[Howard_Casto]

Well that should help tremendously.  Don't be tempting me into adding source code again man.  Don't do it. 

[Howard_Casto]

I hate to keep spamming this thread, but I've got a question.

Could we set it up to where mame tries to connect to a port (with a reasonable timeout of course) and it doesn't start sending data until it finds a connection?  As-is, if the output app connects too early then it doesn't make a connection with mame and if it connects too late it might miss vital stuff like the rom name, ect.  We could do the old looking for windows stuff, but if mame is trying to get away from that the client app should as well. I could just be doing it wrong.

[headkaze]

As-is, if the output app connects too early then it doesn't make a connection with mame and if it connects too late it might miss vital stuff like the rom name, ect.

I've submitted the patch so let's see what feedback we get. If and when they update MAME I'll see if I can get the Mame Interop dll's to connect and re-connect reliably. Right now though I don't appear to be receiving any ROM name via the network connection method. Are you receiving this data?

[Howard_Casto]

No, it's not being sent.  I assumed you had added start/stop messages with your patch. 

Actually now that I tested it again... let's say I try to listen on port 8000..... mame crashes with an unspecified error. 

[SteveBR]

Hi headkaze, I didn't know where else to post this. I downloaded your coindrop1.3 program from many years ago and was trying to get it to work for personal use.  Is it possible to run it on Win 8/10?  If not is the source code available for the user to update the code? Thanks.

[Howard_Casto]

I apologize for cluttering the thread.  I've been busy and I was just wondering what the progress has been.  Is it in mame yet?  I've got everything on hold prior to a new release.

[headkaze]

I apologize for cluttering the thread.  I've been busy and I was just wondering what the progress has been.  Is it in mame yet?  I've got everything on hold prior to a new release.

I submitted a patch but Mamedev never got back to me.

[Howard_Casto]

Well that's not good. 

[headkaze]

Just had a look at MAME 0176 source and it looks like they've applied my patch. Not sure what version they implemented it?

Anyway I will post an updated SDK soon.

[Howard_Casto]

Cool.  We need to do one more patch most likely to add in stuff like the rom name and orientation back in.

[arzoo]

Just had a look at MAME 0176 source and it looks like they've applied my patch. Not sure what version they implemented it?

Anyway I will post an updated SDK soon.

That's great news - thanks!

[headkaze]

I've updated the first post with MameInterop SDK v1.2 but we're not quite there yet. The reason I've released the update is so we can experiment with a working system and so we can get the next series of patches ready to send to Mamedev.

Howard: I've included an updated VB6 version of Mame.dll. I'm not sure if you're developing a separate system for Mame Hooker but my code should help with the re-connection issue you were having. Either way I'd appreciate it if you'd stick by and help us get this SDK working. If you'd like to help create an actual patch I recommend you get the latest version of Mame Compiler 64 which helps automate the process.

[Howard_Casto]

Yeah, no problem.  They've got me on a new thyroid medicine that's giving me trouble with vision/balance so I'm not much help in the coding dept. atm.  It's quite frustrating as I've got some new ideas lined up. 

I'm thinking we just about need some form of two-way communication via another port.  The old system was great in that you could jump in at any time and receive data.  Perhaps on the mame end the startup values (rom, orientation,ect) could be sent again whenever a valid connection is first established. 

[headkaze]

Upon further investigation I've discovered that the original output system is still available in MAME.

Just set the following in mame.ini:

Code: [Select]

#
# OSD OUTPUT OPTIONS
#
output                    windows
I might still see if I can improve the network output system at some stage but for now this should get things working the way they were before.

[Howard_Casto]

That is a new feature I think.  I remember looking up the options when we first ran across this and windows wasn't one of them.  I could have just missed it though.

I think the network communication has potential anyway.  It allows the app to be on another pc... potentially a phone or tablet. 

[headkaze]

MAMEInterop SDK v1.3 Released for Developers
- Finalized network output support / added support for inputs (pause)

Also for Howard I have included VB6 compatible dll's in dlls_vb6 folder (untested).

Thanks to R Belmont for his work on the network output system.

NOTE: I have created a patch to add the ability to send data to MAME. At the moment this only supports pausing / unpausing MAME. If you would like something added please let me know. I do not know when the changes will be publicly available but I will post here when it is. Either way these dll's are backwards compatible with current / older versions of MAME.

NOTE2: I have not had time to update all the examples. Use the C# example as a guide.

[Howard_Casto]

Nice man.  I'll plug it into mamehooker this weekend and see how it goes. 

One of the things I was running into when trying to add force-feedback to some games was the fact that I couldn't (easily) set the limit switches, so that might be something worth looking into. 

[headkaze]

Nice man.  I'll plug it into mamehooker this weekend and see how it goes. 

One of the things I was running into when trying to add force-feedback to some games was the fact that I couldn't (easily) set the limit switches, so that might be something worth looking into.

Cool let me know how you go.

I don't really know much about "limit switches" and force-feedback. I want to be careful not to encroach on plugin system territory. If there is a way in MAME that can set these values, and it doesn't make sense to use the plugin system to do it, let me know. I've only just sent the diff to Arbee to check out but if you want to get something added the sooner the better.

The input system is pretty basic right now. All you have is an "id" and "value". Right now the only id is IM_MAME_PAUSE but I can easily add more. All it does is:

Code: [Select]

// received a message
else if (message == im_mame_message)
{
switch(wparam)
{
case IM_MAME_PAUSE:
if (lparam == 1 && !output.machine().paused())
output.machine().pause();
else if (lparam == 0 && output.machine().paused())
output.machine().resume();
break;
}

return 0;
}

[Howard_Casto]

Well I mean they are just regular old inputs in terms of how they behave, but on many games they aren't even hooked up due to the fact that they mess up the bootup sequence of some games.  I'm not really sure how to approach them since they aren't standardized like regular inputs are. 

Pause would definitely be the most useful.  Save states and other UI functions might be useful as well but I suppose it's one of those add it as the situation requires deals.... no need to add useless stuff. 

[headkaze]

I updated the MAME patch slightly to output orientation for the network output system and also added save state load/save inputs.

[Howard_Casto]

Cool deal man.  Believe it or not I forgot that this weekend was Easter.  I will do some testing soon but It's probably going to have to wait until next week.  It's probably not necessary though as all of your stuff is generally top-notch. 

[headkaze]

Looks like MAMEDev have applied the patch! 

[Jakobud]

Super old thread but this is cool stuff. What could this be used for?

[headkaze]

Super old thread but this is cool stuff. What could this be used for?

It's used in a number of applications such as MAMEHooker, CPWizard, LEDBlinky and others.

So any application that needs to know the game being launched. Also it can now pause and unpause MAME which is handy for applications like CPWizard which upon a keypress will pause MAME and display a menu with information about the current game.

[Boomslang]

Hey

I wanted to look into reading outputs on mame for adding to FFB Arcade Plugin but we use c++ and the latest source code c++ example does not build correctly

is there any plans to correct the sample?

Thanks