What's new
i know, i was just thinking that if you can emulate a serial reader with a pc, you could emulate one better with a cheap rfid module and an arm or arduino type board.

parts probably would cost less than 20 for the rf unit,mcu board and 5-10 cards or fobs.
 
207 bytes. these games uses magnetic cards, not IC or RFID.
i was just looking at how cheap RF-transponder keyfobs & reader/writers are from china ;)
It would not be worth the effort trying to retrofit a different card technology. The main attraction to the magnetic cards, in my opinion, is the thermal printing on the face that shows your info and progress. You aren't going to get that with generic IC or RFID cards, so why bother when your card data can just be stored in a file on hard drive or an SD card?

The ultimate emulated solution that has been suggested in this thread is to have some digital facsimile of the card face that gets updated per the printing commands coming from the game. That could be implemented a number of ways, including a touch-screen mounted to the game or some kind of smart phone integration.

It's something I'd like to see, but probably don't have the motivation to pursue on my end.
 
I still like my original idea of using an NFC module on the Pi and then writing a SmartPhone app. you then store virtual cards on your phone, see a visual representation of the card on your phone, and then simply wave it near the "reader" to read/write a new card.
 
last time i looked at that, it was very expensive tech
 
NFC Module for the Pi is $40 on adafruit: https://learn.adafruit.com/adafruit-nfc-rfid-on-raspberry-pi/overview

There's also this Arduino/Pi compatible board for $24: https://www.amazon.com/dp/B00HFX9OHA/?tag=aurobius-20

so you have that, and the Pi, and whatever serial converter you need for the given arcade game... all together you'd be under $100, The rest is just software. That isn't bad considering the price of card hardware and the cards themselves.

the nice thing is you could technically use the NFC setup an a legit arcade environment. put a sticker with a QR code for the app next to the reader. and anyone can have and maintain their own cards.

Now I'm interested in working on this... though realistically I'm 2+ months out on other projects before I could even think about starting.
 
I still like my original idea of using an NFC module on the Pi and then writing a SmartPhone app. you then store virtual cards on your phone, see a visual representation of the card on your phone, and then simply wave it near the "reader" to read/write a new card.
Can the NFC module write to tags more than once?
I have written to NTAG215 cards using NFC but was only able to do this once. Once these tags are written they become read-only.
 
I don't understand how that applies to this situation ?(

I'm suggesting communication between a smartphone and a Pi.
 
The same concept might be possible over WiFi, too.

Seems like the RPi could just host something that you can interface with using a web-browser on your phone... and have the option to save down or upload a card file.

Various scenarios needed with NFC or other means:
1: Purchasing a new card - probably no NFC interaction for this - RPi host would handle this in a dummy file until card is ejected.
2: Inserting an existing card - I guess you bring up the app and choose your card before NFC connection is made. Something on the RPi side would need to know to be ready to accept card data when the phone is paired. Maybe this is the default state.
3. Ejecting a card - the game senses when a card needs to be taken out, so you could leave it in this state with appropriate ACKs until the NFC communication is done and the card data is uploaded to the phone. Need to put in some kind of timeout so that the RPi gives up and ejects if no phone is paired.

The more difficult part that hasn't been implemented to date is deciphering the print commands and using those commands to generate images. That could potentially get a little tricky for ID1-3 since it doesn't rewrite the entire face every time, but selectively updates specific spots. I suppose, assuming the print commands are figured out, the data could be stored in an image file that needs to be stored on the phone and transfered to the RPi, where it gets updated with print commands during that session, and transfered back to the phone when ejecting.
 
The same concept might be possible over WiFi, too.
you could make it work with Wi-Fi but it really doesn't make a lot of sense. A web connection is driven by the client and the "server" (in this case the pi) can't initiate a data transfer. This works for things like the Pi-Force-Tools because everything is driven by the client and there's no real feedback from the server. The only way to make it work properly would be with something like websockets where there's a constant connection open between the client and server so that the server can send you back status information in real time. Even still you'd have to set it up so that if someone was connected it locks out other connections, otherwise you'd run into situations where multiple clients would be using the same card data even accidentally, but then if you're locking it out you could run into situations where someone forgets to log out and then someone else ends up using their race data. it's kind of messy because it's not really the most appropriate technology for it.


Various scenarios needed with NFC or other means:
With NFC at least I could envision a "waiting to eject" LED where the card reader has "ejected" the card into the Pi's memory and the Pi is waiting to transfer it out to a smart phone. then all you'd have to do is tap your phone to the antenna and the card would transfer off to your phone.

You could also set it up so that it sits in this state and whenever the reader is ready to accept an insert it uses the card that's in memory. so that it would automatically handle the insert and eject events for as long as you want it to until you're ready to "eject" the card from the Pi.


The more difficult part that hasn't been implemented to date is deciphering the print commands and using those commands to generate images. That could potentially get a little tricky for ID1-3 since it doesn't rewrite the entire face every time, but selectively updates specific spots.
the best thing to do to figure this out is record the command and then take scans of the actual printed out put... with enough data we could potentially begin to decipher the data. unfortunately this would require "burning" a lot of cards, unless there is some way to get it to pint on cheap paper somehow.
 
I don't understand how that applies to this situation ?(

I'm suggesting communication between a smartphone and a Pi.
I probably didn't provide enough information.

I'm just saying that I have been successful in communicating with a Pi and an Android Device. I have only been able to do this with 1KB of data to an NFC sticker to write information.

As far as this goes I was only able to save data one day but never modified or changed data.

So if someone decides to successfully communicate between a Pi and Smartphone, it's possible.
With one of the suggestions given, a physical card that shows a visual representation of the license card was better than a USB drive that just has information on it.

Conceptually, I was able to get the Pi to save data as a BIN file on the sd card.
I set the Android Device to point to the sd card location via SMB and set the Android Device with the NFC Writer set to 'waiting'. Once I tapped the blank sticker onto the Android, the I was able to write the BIN file onto the sticker.
 
Last edited:
gotcha... I don't have any experience with NFC personally, I've only briefly looked at the tech for a project I did at work but we ended up going in a different direction. I do like to test out new tech like that though when a good opportunity arises. :)
 
gotcha... I don't have any experience with NFC personally, I've only briefly looked at the tech for a project I did at work but we ended up going in a different direction. I do like to test out new tech like that though when a good opportunity arises. :)
I have a rev g chameleon laying around if you want to borrow it when the time comes. I rarely use it. It's a programmable nfc device with serial console and multiple card slots (can be used to clone and also sniff contactless cards). When you're not at console you can leave buttons programmed on it to switch between the card slots, generate random card IDs, and some other stuff.
 
nfc coil&chip come in everything from tags, cards, stickers, keyfobs - even nails.
they are nvra.

be carefull, there are 2 common types.
one uses Khz frequency's the other uses something like 13Mhz - and is the better one.

btw, you get much better prices at banggood.com
a decent rfid board is about 7$ and cards/fobs are about 1$
https://www.banggood.com/PN532-NFC-...kout-Board-For-Arduino-Android-p-1017796.html
 
gotcha... I don't have any experience with NFC personally, I've only briefly looked at the tech for a project I did at work but we ended up going in a different direction. I do like to test out new tech like that though when a good opportunity arises. :)
I'm in the same boat! So the main reason why I brought up the stickers at all was because I had to do some projects with these things to hold registration info and it was more of a shortcut to read data that I needed for Asset Management. NFC was something new to me so I figured, hey why not, someone wanted to look into this so I thought it was cool. I was tinkering around with binary files to just save data on a previous (ongoing project) and one thing lead to another and a light bulb turned on to relate @winteriscomings card reader with your NFC reading idea.

I'm probably not one to suggest anything new but if someone were to continue with this testing I hope someone is more intrigued than I am to get this to happen.

I will post some add'l data once I find the notes I have stashed somewhere.

If you have a Lego Dimensions toypad, this can be used to communicate with Linux to read NFC data. (NOTE: READ ONLY)
This link will provide some sample code: http://www.ev3dev.org/docs/tutorials/using-lego-dimensions-toy-pad/
The link mentions using Mindstorm EV3 but this is optional (don't bother, they're over $300 at the time I last checked)

The other method is to load NFC data from a shared location (what I tried) then write to NFC destination, whether it be a tag, module, other device to hold that data.

Forgive my gibberish if the above does not make sense, I am typing this from memory (minus the link above, had to google for it) before I shut down for the evening.
 
I may end up with a WMMT pair soon, and if I do, I may be motivated to decipher the printing commands (not that I actually have time to do it...) and come up with some kind of visual card emulation solution for it. Probably nothing as elaborate as phone-based integration, but maybe each machine will get a dedicated touch screen or something.

@saturnnights made some great discoveries about the ID3 printing here and some of the concepts may be transferrable to WMMT.
NAOMI 2/Chihiro/Triforce Card Reader Emulator (Initial D3/WMMT/Mario Kart/F-ZERO AX)

@saturnnights, any progress to report on your project?
 
@saturnnights, any progress to report on your project?
i haven't put much time into the print subsystem as of late. i've been doing work on reverse-engineering the MIDI force feedback protocol [can currently initialize, move wheel to left lock and right lock, and poll force feedback position data]. also, remediating a DDR cabinet that's now in my game room [almost done, just some minor pad repairs. swapped display chassis, then the whole display, system 573 trace repair, small reharnessing, amplifier board repair...]. ...also bootstrapping a sega ringedge to see what i can reverse-engineer of ALL.net for potential simulation of that network [think programmed sun/programmed world for konami/bemani, if you're in the know].

i'd expect WMMT to also use Shift-JIS as its character set [i played WMMT 3DX in yokohama, japan, and registered a card there. japanese card face, same card material]. if someone could send me the debug output of what the game sends to the reader on boot, along with registering a new card on WMMT [along with the racer name, car selection, current horsepower, etc], i can probably pick the data out of the debug output and post up what i find.

i have several IDAS card reader/writer mechanisms, but none for WMMT, so, i can't directly test a real reader. i do have a sega chihiro [along with WMMT 2] that i need to repair and get in working condition. once that's going, i could at least test out the emulation side and see what i can capture.
 
Back
Top