- Thread starter winteriscoming
- Start date
-
- Tags
- card reader id3 initial d3 naomi 2
https://github.com/GXTX/YACardEmu
Now supports the BR model used for F-Zero, Mario Kart, and the Initial D series (1-3). As well as a "new" API backend.
Now supports the BR model used for F-Zero, Mario Kart, and the Initial D series (1-3). As well as a "new" API backend.
sdargiewicz
Beginner
I really enjoyed reading through this thread. I'm new here (hello) and am a software engineer but really like exploring the hardware side of arcade machines too.
I'm interested in how the Initial D3 magnetic stripe cards get written to on a raw byte level. Ultimately, my project goal is to take my blank ID3 memory card and write valid data to it with magstripe reader/writer (MSR605X) so I can take it to the arcade (an hour drive away). There's just one piece of the puzzle I seem to be missing!
I've read and understand that the payload data is 69 bytes per track. Using the Demul emulator, i've got a freshly registered card. Here is the hex data for example:
Does anyone have raw byte data from an already initialized ID3 card? I believe you could use any normal 3 track magstripe reader to get the data. My cards are unregistered and don't even register on my stripe reader (the stripe must be all 0 bits)... If I could see what data is on there besides the payload bytes, maybe I could figure it out.
An alternative would be if there was some manual that says what the start/end bytes are written as, but I was unsuccessful at finding this information.
I'm interested in how the Initial D3 magnetic stripe cards get written to on a raw byte level. Ultimately, my project goal is to take my blank ID3 memory card and write valid data to it with magstripe reader/writer (MSR605X) so I can take it to the arcade (an hour drive away). There's just one piece of the puzzle I seem to be missing!
I've read and understand that the payload data is 69 bytes per track. Using the Demul emulator, i've got a freshly registered card. Here is the hex data for example:
At first I thought I could just write this data, but Track 2 and Track 3 have data that starts with a 0 bit - that 0 bit gets cutoff when being read back after writing. I think there is a start byte/end byte that also gets written to the card by a real machine, but I don't know what it is!
Does anyone have raw byte data from an already initialized ID3 card? I believe you could use any normal 3 track magstripe reader to get the data. My cards are unregistered and don't even register on my stripe reader (the stripe must be all 0 bits)... If I could see what data is on there besides the payload bytes, maybe I could figure it out.
An alternative would be if there was some manual that says what the start/end bytes are written as, but I was unsuccessful at finding this information.
That's interesting, the card data payload is exactly 207 bytes (write packet is 215 including serial packet data, save command and checksum) so takes up all 3 tracks on the card with no room for anything else unless the physical tracks themselves allow for an extra byte? the game certainly doesn't send any extra bytes besides that, could it be something to do with how your reader is behaving? could you post your card data here?
sdargiewicz
Beginner
I imagine the start/end sentinels is something the ID3 reader machine handles without needing instructions from a higher up software layer. But it appears that all standard magstripe formats begin with a byte where the first bit is 1 so that the reader can register a voltage change at the proper time. Here is my card data being written (taken from demul emulator .card file and turned into hex):
Here is the data that is read back:
Track 2 is shifted by 2 bits, and track 3 is shifted by 1 bit.
I can successfully write and read 72 bytes to each track (more than 69) - enough for a start char, an end char, and an LRC if it uses one.
Here is the data that is read back:
Track 2 is shifted by 2 bits, and track 3 is shifted by 1 bit.
I can successfully write and read 72 bytes to each track (more than 69) - enough for a start char, an end char, and an LRC if it uses one.
I don't understand, if you have 3 69 byte tracks and you write them to a card using mag card software then the data you read back isn't what you wrote isn't that an issue with your software? I'd expect it to be handled automatically
sdargiewicz
Beginner
https://jacobo.tarrio.org/2014/how-magnetic-stripe-cards-work.html
Here is a nice and detailed explanation of how magstipes can be read. A relevant paragraph is
Here is track 2 of my card data in binary form
I don't think it's possible to precisely count the 0s and distinguish when my actual payload bytes starts, because those leading 0s are not standard or reliable until the reader has understood how fast the card is being swiped.
This is why the reader reports the data as I have shown. It only knows data has started when it reaches the first 1 bit.
(Disclaimer: All of this is my amateur explanation based on my experience and can certainly be challenged!)
Here is a nice and detailed explanation of how magstipes can be read. A relevant paragraph is
Standards exist like the ISO format to make the data readable "automatically". Initial D doesn't use ISO format i'm guessing - but it must use something. The emulator card data doesn't include this critical formatting (it doesn't need it). That's what i'm trying to find out.
Here is track 2 of my card data in binary form
Physically though, the mag card will pulse like this:
I don't think it's possible to precisely count the 0s and distinguish when my actual payload bytes starts, because those leading 0s are not standard or reliable until the reader has understood how fast the card is being swiped.
This is why the reader reports the data as I have shown. It only knows data has started when it reaches the first 1 bit.
(Disclaimer: All of this is my amateur explanation based on my experience and can certainly be challenged!)
Given you can read the data back it seems the sentinel characters are being written and handled, your data start, end and the separation of tracks is happening so I think the leading zeroes might be a red herring, do you have a regular plastic mag card to test a write and read back? guess it could be something to do with the card physically, ISO vs JIS-2 or whatever standard the card uses
Edit: just looked it up and JIS-2 only supports 1 track and as of 1998 JIS-1 (3-track) is ISO compliant, guess it could be using pre-1998 JIS X 6302 standards?
Last edited:
sdargiewicz
Beginner
This would be excellent if it also applies to ID3. Then I could just write 01 hex before my payload data and the reader would left shift the bits by one, and everything would be accurate.
I tried to look on ebay for a used card shipping from the US and didn't find one. I messaged some sellers to see if they had any used ones lying around that they'd be willing to sell me.
sdargiewicz
Beginner
After asking a lot of people, I was able to source a used ID3 card 
Once that arrives and I've had time to analyze the data, i'll report back my findings
Once that arrives and I've had time to analyze the data, i'll report back my findings
sdargiewicz
Beginner
I got my used card and was able to solve the data format completely!! Here are my findings...
First, the cards are written right-to-left, which is typically backwards from normal US readers and my MSR605X device. So you have to scan the card backwards or you will get incorrect data (because of the start bit must be 1 rule I talked about before). I had a lot of trouble scanning the used card because the position of the magnetic tracks were off a little bit - I don't know if all cards are like this or if the machine that wrote mine was misaligned. I had to bend the tip of the card and read the tracks individually.
Next, each track is 72 bytes. There is a start character of FF, the payload data, an end character of FF, and an inverted Block Check Character (BCC) at the very end. Every byte of the payload has the bits reversed. So you must reverse every 8 bits to get the correct payload data.
To verify my findings, I took the 3 tracks, extracted the payload data, reversed the bits as necessary, and put my card data into the Demul emulator. Success! This matches what was printed on the person's card.
So that proves this works. Therefore, to write emulator data to a real card, just do the steps in reverse:
First, the cards are written right-to-left, which is typically backwards from normal US readers and my MSR605X device. So you have to scan the card backwards or you will get incorrect data (because of the start bit must be 1 rule I talked about before). I had a lot of trouble scanning the used card because the position of the magnetic tracks were off a little bit - I don't know if all cards are like this or if the machine that wrote mine was misaligned. I had to bend the tip of the card and read the tracks individually.
Next, each track is 72 bytes. There is a start character of FF, the payload data, an end character of FF, and an inverted Block Check Character (BCC) at the very end. Every byte of the payload has the bits reversed. So you must reverse every 8 bits to get the correct payload data.
To verify my findings, I took the 3 tracks, extracted the payload data, reversed the bits as necessary, and put my card data into the Demul emulator. Success! This matches what was printed on the person's card.
So that proves this works. Therefore, to write emulator data to a real card, just do the steps in reverse:
Can't wait to try this out at the real arcade. If it doesn't work, it's probably because my card writer doesn't write the tracks with the expected distance and margins that the sanwa one does. If that's the case, I don't know if there's anything I can do to fix that. Fingers crossed i guess haha.
This thread always affirms what this site is all about.
Here is a write up of the work done on F-Zero AX card encoding, the document includes links to a spreadsheet I put together to calculate card data for editing name, counter, pilot and ship parts plus a rewrite of crediar's decrypting/encrypting tool that will also calculate the new card data CRC. It's a bit too long and involved to post separately and with this link I can keep the document updated with the latest information.
https://docs.google.com/document/d/...ouid=115197120515540717389&rtpof=true&sd=true
Confirmed working on THE iDOLM@STER and Virtual-On Force 
Hikaru's a weird system.
https://github.com/GXTX/YACardEmu
https://twitter.com/X1LeP/status/1636690052762992641
Hikaru's a weird system.
https://github.com/GXTX/YACardEmu
https://twitter.com/X1LeP/status/1636690052762992641
Last edited:
apeezyfosheezy
New User
Hi there,I got my used card and was able to solve the data format completely!! Here are my findings...
First, the cards are written right-to-left, which is typically backwards from normal US readers and my MSR605X device. So you have to scan the card backwards or you will get incorrect data (because of the start bit must be 1 rule I talked about before). I had a lot of trouble scanning the used card because the position of the magnetic tracks were off a little bit - I don't know if all cards are like this or if the machine that wrote mine was misaligned. I had to bend the tip of the card and read the tracks individually.
Next, each track is 72 bytes. There is a start character of FF, the payload data, an end character of FF, and an inverted Block Check Character (BCC) at the very end. Every byte of the payload has the bits reversed. So you must reverse every 8 bits to get the correct payload data.
To verify my findings, I took the 3 tracks, extracted the payload data, reversed the bits as necessary, and put my card data into the Demul emulator. Success! This matches what was printed on the person's card.
So that proves this works. Therefore, to write emulator data to a real card, just do the steps in reverse:
Can't wait to try this out at the real arcade. If it doesn't work, it's probably because my card writer doesn't write the tracks with the expected distance and margins that the sanwa one does. If that's the case, I don't know if there's anything I can do to fix that. Fingers crossed i guess haha.
I’m trying to replicate what you did here, putting printed card data onto the demul emulator but for derby owners club. I tried to follow what you did but have been unable to get it working. Would you be able to go a bit more in depth on the steps for how you were able to transfer real card data to demul and have it open?
The trouble I am having is I am not sure exactly which 3 bytes need to be chopped off per track and I am unsure if I am reversing the bits correctly.
By any chance could you also post the raw 3 tracks data (the 72 bytes per track) of the card you used for ID3 so I can also try to replicate your process along with the 69 byte edited version you then had that opened in demul. With that I should be able to figure out what is going wrong since ID3 and DOC cards are encoded essentially the same.
Thanks so much!
Lots of amazing work in this thread!
It looks like there used to be online leaderboards for WMMT3 where you could participate by typing in the mileage or time attack password that gets printed on your player card. (Site's here but now defunct.)
Has someone figured out how the mileage / time attack score is encoded in the printed password? I haven't been able to find anything about it. I don't have the hardware or the skills to lift the data from the cards, but if the password format has been cracked, I could make an online WMMT3 leaderboard for our local arcade.
It looks like there used to be online leaderboards for WMMT3 where you could participate by typing in the mileage or time attack password that gets printed on your player card. (Site's here but now defunct.)
Has someone figured out how the mileage / time attack score is encoded in the printed password? I haven't been able to find anything about it. I don't have the hardware or the skills to lift the data from the cards, but if the password format has been cracked, I could make an online WMMT3 leaderboard for our local arcade.
sdargiewicz
Beginner
The raw byte data from the scanned card is this:
Track 1:
FF1452DB7C339EBE9E044F87B31C0FDF3343B8E335DB28219306B111833A9D73FF9F1E370F1C330506133AD2CB5F4B400436D57C0308FC66A13B11CC28E674934F4BE7AD82A5FF8D
Track 2:
FFAEA4CC2B5230062A72F7F1C77C0A3724EB2743DA9B2E1DDF8F5B0B70C9D2E86AF7D28D83852DA1590ED1236F21BF76DBD809BF649730BD2185A66F7209CAB79CF45884A443FF6D
Track 3:
FFCAA2E28242124ACC3CDBF266D5D956A5D2993320A64C66ABF511CBD617FF3B5B515498CA410EF1B99530506F58268079A3343F4FD4307115A7FCE66FE7E642EF26D2A25715FFE3
Chop off the first "FF" in each track and then the last 4 characters (last 2 bytes).
I wrote a c# program to reverse the bytes (attached). After running the program, it outputs these three tracks:
Track1:
284ADB3ECC797D7920F2E1CD38F0FBCCC21DC7ACDB1484C9608D88C15CB9CEFFF978ECF038CCA060C85C4BD3FAD202206CAB3EC0103F6685DC883314672EC9F2D2E7B541A5
Track2:
752533D44A0C60544EEF8FE33E50EC24D7E4C25BD974B8FBF1DAD00E934B1756EF4BB1C1A1B4859A708BC4F684FD6EDB1B90FD26E90CBD84A165F64E9053ED392F1A2125C2
Track3:
53454741424852333CDB4F66AB9B6AA54B99CC04653266D5AF88D36BE8FFDCDA8A2A195382708F9DA90C0AF61A64019EC52CFCF22B0C8EA8E53F67F6E76742F7644B45EAA8
Then I go here https://www.binaryhexconverter.com/hex-to-ascii-text-converter
and paste each track into here. If you combine the output of these 3 tracks and put them into the .card file Demul reads, it will work. Here is my demul .card file after using the hex-ascii converter:
Hi,
Currently using RS232 to USB (PL2303 based cable).
I tried to connect into my Laptop (Windows, macOS(Ventura)) it's works so well. but when i tried to connected to RPI, it showing wrong value. Its not working on RPI.
What should i do fix this??
Currently using RS232 to USB (PL2303 based cable).
I tried to connect into my Laptop (Windows, macOS(Ventura)) it's works so well. but when i tried to connected to RPI, it showing wrong value. Its not working on RPI.
What should i do fix this??
Figure I'll ask in public.
Would you be willing to share your HW210 work? I know how it's used on some systems is more complex using JVS buttons to signal a card being present, etc. But I'd love to add support for it in my card emulator.
There's still a lot of stuff that's private being floated around (such as ID4-8 scripts, although you could probably steal Teknoparrots work at this point?), and I'd love to see the scene move away from all the secrecy.
