Swipe card reader to credit mame...

[cyapps]

Hello,
I am not sure where to look for help with my problem but figured some of you might be able to point me in the right direction.

I bought a swipe card reader and have some swipe cards that contain unique numbers. The card reader plugs in via usb and is recognized by windows as the device it is. When I swipe a card it simply sends the data read in plain text format as if it was entered by a keyboard. I am planning on using these cards on a mame system for crediting the game upon a valid user swipe. I want to have the program watch the certain device for input and grab the text before it gets to mame, parse it and if it is in a valid list have it send a certain key press to mame. The extent of my programming skills is in php (self taught). I am just not sure where to start with this issue. Any information at all is greatly appreciated and welcomed.

Thanks,
John

[protokatie]

From what I understand, MAME grabs text from the keyboard very directly. I do not know if it would be possible to have a program kludge itself in between MAME and the keyboard IO... If you had 2 computers (one hooked to the swipe card reader) and had the two computers linked creativly (IE using a ledwiz on the swipe compy to send signals via an Ipaq to the other compy) it might work....

[Ginsu Victim]

however, if the cards are all different, you couldn't really map the coin switch to a particular key. Plus, depending on what all numbers or letters are on the card, you could really freak MAME out! If it outputs a whole string, that's like hitting those keys in sucession. (assuming you get it to read the card as key presses)

[HairyDVD]

The process you are describing is similar to how a barcode reader works.  The problem you are faced with is that mame will have the 'focus'.  If another screen had the 'focus' then you may be able to do some work with the string.

Good luck...

[nullb0y]

Hmm, you need a second machine or a device to just read the code,
I dont think this is going to work
"EASY" anyways

[ahofle]

It can be done.  You have to consume the key events before MAME with windows hooks (that's how I got cabvol to work anyway).  Injecting the credit back into MAME is another matter (not nearly as easy in recent versions of MAME).  You will need to read up on raw input for that part.  I doubt you will get much help though as mamedev tend to frown on anything that appears to assist in using MAME in a commercial environment (can't say I blame them).  A while back I started working on a hook that would capture the credit key in MAME, play a sampled coin drop sound effect, and THEN pass the credit to MAME to simulate the delay between a quarter drop and the credit sound in game.  I got everything to work except for sending the credit key back to MAME.  I didn't get much help over at the mame forums either, presumably due to the nature of this 'hack'.  One of these days when I have more time, I will try to finish this little project.

[ahofle]

Oh, and you will need to start the swipe cards' code with some character that is not used by MAME like # or ^ or something so that you know when to start consuming the swipe card characters.  Otherwise, you would cause all sorts of input delays in MAME.

[Ginsu Victim]

Sounds to me like he can only read the cards with codes already on them. Correct me if I'm wrong.

[Ummon]

A little off topic perhaps - I just don't see a similarity in using a card to using coins. Maybe because a coin is 'gone' after you enter it, so you have to use more. I don't do the coin thing, either, but I understand it. Why would you want to replicate using a card?

[cyapps]

The swipe cards that I will be using are just old coupon cards from dave and busters.

Oh, and you will need to start the swipe cards' code with some character that is not used by MAME like # or ^ or something so that you know when to start consuming the swipe card characters.  Otherwise, you would cause all sorts of input delays in MAME.

Valid swipe I get: %S3UNIQUE ALPHA NUMERIC CODE?;ID NUMBER OF CARD?;E?
And for a bad swipe I get: ;E?;E?
From what I see the string will always start with a ; or % no matter what card is swiped and the ; is used to separate the tracks on the strip (I am using a 2 track reader). I can figure out how to work with what is entered and the rest of the stuff, I just need to grab the initial string and return the credit key when the data has been worked with.

A little off topic perhaps - I just don't see a similarity in using a card to using coins. Maybe because a coin is 'gone' after you enter it, so you have to use more. I don't do the coin thing, either, but I understand it. Why would you want to replicate using a card?

I just thought it would be interesting to create something similar to a dave and busters thing so I can have set limits on the cards and unique things for certain users. There is also a coin door if they should so choose . This is just meant to be a fun hardware/software project on top of just making a mame machine, trying to learn what I can. I will also be messing with rfid in the near future but that will use similar software.

It can be done.  You have to consume the key events before MAME with windows hooks (that's how I got cabvol to work anyway).  Injecting the credit back into MAME is another matter (not nearly as easy in recent versions of MAME).  You will need to read up on raw input for that part.  I doubt you will get much help though as mamedev tend to frown on anything that appears to assist in using MAME in a commercial environment (can't say I blame them).  A while back I started working on a hook that would capture the credit key in MAME, play a sampled coin drop sound effect, and THEN pass the credit to MAME to simulate the delay between a quarter drop and the credit sound in game.  I got everything to work except for sending the credit key back to MAME.  I didn't get much help over at the mame forums either, presumably due to the nature of this 'hack'.  One of these days when I have more time, I will try to finish this little project.

Is there any source or information on your project? It sounds like it would be a good place to start.

[cyapps]

I forgot to mention that the reader is a usb device that is seen as a human interface device in windows. This might give me another way to get the data grabbed and parsed before it sends it through.

[Ginsu Victim]

I doubt you'll be able to do any credit system like D&B's. You might be able to swipe the card and have it give credit in-game, but tracking the credits.....I don't know....

[Space Fractal]

It would been nice if somebody could create a souce code hack to the keyboard coder, so it can deserve input from example clipfolder...
 

[cyapps]

I doubt you'll be able to do any credit system like D&B's. You might be able to swipe the card and have it give credit in-game, but tracking the credits.....I don't know....

All I need is a way to intercept the text that is entered if it begins with a % or ; and then process it on the back end and send back the pre determined credit key. The whole issue is with actually intercepting the key and sending another key not what goes on in between.

I just wish this device had it's own driver and isn't installed as a hid / keyboard.

From what I understand, MAME grabs text from the keyboard very directly. I do not know if it would be possible to have a program kludge itself in between MAME and the keyboard IO... If you had 2 computers (one hooked to the swipe card reader) and had the two computers linked creativly (IE using a ledwiz on the swipe compy to send signals via an Ipaq to the other compy) it might work....

Yea, using a second system and a led wiz type device has crossed my mind but there has to be a way to work in between the keyboard and mame.

[headkaze]

I've written code to inject keys into Mames raw input system, but I don't think it's necessary. All you need to do is a global key hook that blocks keys until you swipe your card it will read the card then allow the keys to pass through the hook. I don't see a need to actually send keys to Mame directly which is the tricky part.

[cyapps]

I've written code to inject keys into Mames raw input system, but I don't think it's necessary. All you need to do is a global key hook that blocks keys until you swipe your card it will read the card then allow the keys to pass through the hook. I don't see a need to actually send keys to Mame directly which is the tricky part.

I would prefer to be able to input stuff and move around in the system/mame and not block the entire input until a card is swiped (that might be useful with the rfid keys later on).  I will also be able to credit the game with a coin if I don't have a card.

Here is a more detailed explanation of what I want to do.
I want to basically have a file that contains a set of card "numbers" and when someone swipes a card ( which string always starts with a % or ; and ends with a ?) it gets grabbed by a program then the string is parsed to find the card number. At this point the program will check a db / file for a list of card numbers and their credit values and if there are enough stored credits for that card number then it will remove a credit from that cards db / file entry, then send the credit key to mame, if not then it will do nothing and ignore the key swipe.

It would be perfect if I could watch the input of the exact usb hid driver that the swipe card is using to get the string into the system, then only grab and work with the data from that device and let everything else work as normal.

[Ginsu Victim]

One thing's for sure...

Don't expect help from any MAME devs on THAT request.

[cyapps]

One thing's for sure...

Don't expect help from any MAME devs on THAT request.

I completely understand that, I wouldn't want to bother them with this anyways, as this is mostly a learning experience on my behalf.

And besides this isn't really just to be used with mame, it is more about having a program that can work with the swipe card and other similar inputs, I just figured I could use it with mame as well as a way to track when I and others have played and store virtual credits on the backend. In reality I am likely to be the only one playing the system I am putting together so this is pointless if I was just going to be using it for my arcade machine. I just was asking for any information anyone could provide. I am thankful for the input I have already received and welcome whatever input anyone else has.

[protokatie]

Here is a rather dummy approach to it: After the program you have sitting in the back does all of its DB lookup work, have it output a signal that goes out to a project board that has a solinoid wired to it. Just have a second keyboard inside the cab, and positition the solinoid over the 5 or 6 button. So basically, you would have "robot fingers" hitting the coin keys on a physical keyboard hidden in the cab.

Computer "project boards" (cant remember exactly what they are called right now) arent expensive, and many will plug directly into a parallel port, or even USB.

If you cant find a good project board, just get an extra old soundcard and have the program hit left/right audio output to high to power the solinoid...

Just some odd hack ways I thought of, I hope you dont have to go to this level of hack tho

[cyapps]

Here is a rather dummy approach to it: After the program you have sitting in the back does all of its DB lookup work, have it output a signal that goes out to a project board that has a solinoid wired to it. Just have a second keyboard inside the cab, and positition the solinoid over the 5 or 6 button. So basically, you would have "robot fingers" hitting the coin keys on a physical keyboard hidden in the cab.

Computer "project boards" (cant remember exactly what they are called right now) arent expensive, and many will plug directly into a parallel port, or even USB.

If you cant find a good project board, just get an extra old soundcard and have the program hit left/right audio output to high to power the solinoid...

Just some odd hack ways I thought of, I hope you dont have to go to this level of hack tho

That would be a interesting way of doing it . If I have to go the hardware route I was just going to use a relay and a Ultimarc Pac-Drive or LED-Wiz, etc. to control it. Would be more reliable and better priced since I am already getting one of those devices soon. Definite thumbs up for thinking outside the box though!

On that note, anyone know where and what relay would work with the above scenario? It would have to be controlled by a similar voltage as an led and work with making the connection for a button press. I am sure someone has used this method for other purposes and should be able to point me to the best suited/priced options.

Thanks

[ahofle]

Does anyone else find it funny that it's seemingly easier to create a robot/hardware solution to press a 5 key than it is to wade through Microshaft's raw input API?   

[Thenasty]

how about... a lappy running the Card Swipe DB program then if its legit and has still value in, triggers the LPT/COM port and at the end of cable of the LPT/COm, triggers an optoisolator connected to the credit (key 5 or 6) on the encoder connected to a different PC. 

[cyapps]

how about... a lappy running the Card Swipe DB program then if its legit and has still value in, triggers the LPT/COM port and at the end of cable of the LPT/COm, triggers an optoisolator connected to the credit (key 5 or 6) on the encoder connected to a different PC. 

Using a second system for the swipe/db/authorization stuff is probably my final option...


ahofle,
You know if I can actually watch/work with a certain generic human interface devices? Would using the hooks be able to just grab the input from that driver before it gets outputed? That way I won't even have to mess with the input from my control panel but only what was entered via the swipe devices driver.

[headkaze]

Does anyone else find it funny that it's seemingly easier to create a robot/hardware solution to press a 5 key than it is to wade through Microshaft's raw input API?   

It won't tell you how to fake raw key input anyway, so yeah definately a waste of time

cyapps: You can read HID devices directly (look at the PacDrive SDK and you will see an example in the PacDrive.dll source code I wrote). But the problem is if it's emulating a keyboard there will probably be a problem preventing the data being processed by the installed keyboard driver.

The best way to trap input from the keyboard is to use a global keyboard hook (search Google for WH_KEYBOARD_LL). With that you can stop all input reaching other apps by "eating the keystroke" which just means not letting it pass through your hooks WinProc function.

Now as for injecting keys into Mame's Raw Input system the way to do it is by writing a dll to:

1. Use SetWindowsHookEx to attach to the Mame process space
2. When you attach to the Mame process API Hook "GetProcAddress"
3. Then in your GetProcAddress hook, hook into RegisterRawInputDevices, GetRawInputDeviceList, GetRawInputDeviceInfo, GetRawInputData.
4. To inject a key send Mame a fake WM_INPUT message which will trigger a "GetRawInputData" call in Mame
6. Inside your GetRawInputData hook you need to inject the actual key

Also you will need to create an appropriate 32 or 64 bit dll depending on the compiled version of Mame because some of the API functions you need to hook into differ between them. Yes this does work because it's how I've done it.

Yes your probably better off using a keyboard hack or something to inject keys into Mame but IMHO the easiest way to go about this whole thing is to prevent the 5 or 6 keys from passing to Mame in the first place using a global key hook. When you recieve an accepted code when someone swipes their card then allow the 5 and 6 keys to pass onto Mame.

[cyapps]

cyapps: You can read HID devices directly (look at the PacDrive SDK and you will see an example in the PacDrive.dll source code I wrote). But the problem is if it's emulating a keyboard there will probably be a problem preventing the data being processed by the installed keyboard driver.

Will check it out when I get up.

The best way to trap input from the keyboard is to use a global keyboard hook (search Google for WH_KEYBOARD_LL). With that you can stop all input reaching other apps by "eating the keystroke" which just means not letting it pass through your hooks WinProc function.

Now as for injecting keys into Mame's Raw Input system the way to do it is by writing a dll to:

1. Use SetWindowsHookEx to attach to the Mame process space
2. When you attach to the Mame process API Hook "GetProcAddress"
3. Then in your GetProcAddress hook, hook into RegisterRawInputDevices, GetRawInputDeviceList, GetRawInputDeviceInfo, GetRawInputData.
4. To inject a key send Mame a fake WM_INPUT message which will trigger a "GetRawInputData" call in Mame
6. Inside your GetRawInputData hook you need to inject the actual key

Also you will need to create an appropriate 32 or 64 bit dll depending on the compiled version of Mame because some of the API functions you need to hook into differ between them. Yes this does work because it's how I've done it.

Thanks so much for the information!
I have been reading about windows key hooks for a bit (need to have time to focus on this), I guess it is time for me to learn a new programming language... As far as I go is php website stuff. I was hoping to find some example code to get me started, because I learn a lot better seeing some examples/results.

Yes your probably better off using a keyboard hack or something to inject keys into Mame but IMHO the easiest way to go about this whole thing is to prevent the 5 or 6 keys from passing to Mame in the first place using a global key hook. When you recieve an accepted code when someone swipes their card then allow the 5 and 6 keys to pass onto Mame.

You mean basically having the credit keys disabled until the person is verified then enabling them so they can get credit? I guess in that case it could also watch how many times they press the credit button and disable it again when they run out, etc... But that will come later Like I said previously this is more about the learning than the practicality of it...

[ahofle]

Yes your probably better off using a keyboard hack or something to inject keys into Mame but IMHO the easiest way to go about this whole thing is to prevent the 5 or 6 keys from passing to Mame in the first place using a global key hook. When you recieve an accepted code when someone swipes their card then allow the 5 and 6 keys to pass onto Mame.

Actually, thinking about it more this is definitely the way to go.  Your program could keep a count of the number of swipes and store the 'credits' internally.  You could even create a database to limit the number of available swipes by card number and check/decrement that each time a swipe occurs (play a buzzer wave file or something if the swipe is over the limit).  Then whenever you receive a '5' key, decrement the counter and let the key pass to MAME.  Once the counter is 0, consume the '5' keys so they don't pass to MAME.

[Qesmann]

Does anyone else find it funny that it's seemingly easier to create a robot/hardware solution to press a 5 key than it is to wade through Microshaft's raw input API?   

It won't tell you how to fake raw key input anyway, so yeah definately a waste of time

The function that fakes raw key input is SendInput:
http://msdn.microsoft.com/en-us/library/ms646310.aspx

I don't know if that solves the problem, but that's the function.

[ahofle]

That's from an older API and doesn't work with raw input applications (ie MAME). 

[headkaze]

That's from an older API and doesn't work with raw input applications (ie MAME). 

Yep your right which is why programs like AutoIt and AutoHotKey don't work with Mame anymore. keybd_event, SendInput and a DirectInput hook all work with the older versions of Mame. Mame 118 and higher uses the Raw Input System and the way I describe a few posts above is the only method to work now AFAIK.