What's new
By:
Filters

NAOMI 2/Chihiro/Triforce Card Reader Emulator (Initial D3/WMMT/Mario Kart/F-ZERO AX)

I can get through all the WMMT3 test menu card reader options successfully.

I have even successfully started a game with card data taken from my logs. I'm not sure I'm writing data correctly yet, because I saved down new data and it didn't like what I was sending back when I tried to start again.

This is also where things get annoying with the game. It just keeps asking for the card data rather than deciding its getting bad data and giving an error... then it just keeps asking for it once going to the test menu. It won't stop and get on with another command until it's satisfied or rebooted.
 
I am successfully saving and inserting card data for WMMT3 now.

I notice the game does not send out a blanket erase command. WMMT1-2 use the x7D command for this. WMMT3 uses the x78 command. I can't quite understand what this is doing other than that it's possible that it's selectively erasing and overwriting parts as it prints. I haven't seen enough to know if a x78 command is a full erase, but the logs show that no time is taken in responding to the command, so it's not like the physical printer had to go through and spend time erasing and giving updates to this command. It only gives a single response.

I'm going to take advantage of the imaging script's ability to NOT use a transparent background when it's pasting new images onto the existing one, so it will effectively wipe out what's below it. We'll see if that does it.
 
My impression of printing on WMMT3 is that it erases a line as it prints. So I decided to have the printing script behave like that. If it's printing for WMMT3, or any game that behaves this way, it will clear out the line prior to printing it. It remains to be seen if this is appropriate across the board for WMMT3, but I'm hoping it is.

At any rate, assuming nothing happens that's wildly different than what I'm doing now, I'm mostly finished with the script for WMMT3. I still need to do a little work on the handling of inserting and ejecting cards.
 
As was mentioned much earlier in this thread by @MetalliC, the magnetic cards have 3 tracks of data.

Up until now I had not run into a game that uses more than the first track. WMMT3 uses all 3.

Furthermore, WMMT3 does not always overwrite all 3 tracks. I had scripted for it assuming the game was always sending complete card data when it wrote to the card, but that is not the case. It will only overwrite a track if it needs to and will leave the others alone. I discovered it was doing this is when after a few story races I kept running into issues with my card data file no longer being accepted by the game. It turns out I was only receiving data for tracks 2 and 3.

A track consists of 69 bytes. A card write command can come in with just 1 track or up to 3. There is a parameter byte for indicating which tracks are being written. A payload with 1 track of data can go to any of the 3 tracks. A payload with 2 tracks of data can be sent to 1 and 2, 2 and 3, or 1 and 3. A payload with 3 tracks obviously writes to all 3 tracks. I am now accommodating for this in my WMMT3 script and will hopefully not run into any more data issues.
 
Those writes are they made in multiple swipes across the megnetic head? Meaning to write to track 1 and 3 does it pass across the magnetic head 2 times
 
rocket said:
Those writes are they made in multiple swipes across the megnetic head? Meaning to write to track 1 and 3 does it pass across the magnetic head 2 times
Click to expand...
I honestly don't know the specifics of this technology. I'm able to get what I need out of serial logs and the general Sanwa reader pdf (which has great info that seems to apply regardless of the model). In the end, what's actually happening with the physical reader and how it writes and retrieves data from the cards is magic to me! :D

Magnetic reading/writing? Thermal printing (and erasing on some models)? Magic!
 
right, it depends on this device's magnetic head design, which may read/write only single track, or 1-2-3 tracks at once in single pass.
but we don't know how it is in this reader.
 
a bit related to this topic - I've did RE of Atomiswave "AW-NET" system card readers.
long story short - AW RFID cards was identified as Maxell ME-Y2001 (1Kbyte "coil-on-chip"), which read via Maxell ME-M21 series or compatible reader, same device as located inside of Lindbergh InitialD's card reader/printer. at least it uses same command set as encapsulated in ID4 command D1 :)
however, there is only 2 "Net@Select" games directly connected to these readers - "Salaryman Kintaro" and "Horse Racing: Victory Furlong". which is not "cool games", heh..

while more interesting games - KOF Neowave, NeoGeo Battle Coliseum and GG Isuka, connected to special box, which splits video, inputs and cardRW interface for up to 4x cabs.
https://imgur.com/a/HfwIw9w
at cardRW comms part it is much simpler than Maxell's readers, there is quite simple command set.

I can provide additional information if anyone interested to create some emulator script for RPi, for use with real Atomiswave (or maybe it may work for Naomi2 too ? I'm not sure)

ngbc_c.png
 
winteriscoming said:
As was mentioned much earlier in this thread by @MetalliC, the magnetic cards have 3 tracks of data.

Up until now I had not run into a game that uses more than the first track. WMMT3 uses all 3.

Furthermore, WMMT3 does not always overwrite all 3 tracks. I had scripted for it assuming the game was always sending complete card data when it wrote to the card, but that is not the case. It will only overwrite a track if it needs to and will leave the others alone. I discovered it was doing this is when after a few story races I kept running into issues with my card data file no longer being accepted by the game. It turns out I was only receiving data for tracks 2 and 3.

A track consists of 69 bytes. A card write command can come in with just 1 track or up to 3. There is a parameter byte for indicating which tracks are being written. A payload with 1 track of data can go to any of the 3 tracks. A payload with 2 tracks of data can be sent to 1 and 2, 2 and 3, or 1 and 3. A payload with 3 tracks obviously writes to all 3 tracks. I am now accommodating for this in my WMMT3 script and will hopefully not run into any more data issues.
Click to expand...
From what I remember MT3 / 3DX / 3DX+ track 1 data will never change during the cards lifetime, I actually don't even think it changes after the card is renewed. So that probably holds the permanent data that doesn't change on a card like Card Name / Car Model / ID # (00-01 or whatever). I know that after every play no matter if you don't even race the only thing that changes is your card life goes down 1, both tracks 2 and 3 will change.
 
Just a bit of an update here. I have the card reader script working with 3DX+, but this game is apparently varying the way it prints on the card, so my WMMT3 printing method is not working out for 3DX+.
 
I just got my Naomi 2 to work with Initial D 3 and was wondering if there was any updates to the software? Thanks in advance!
 
I don't quite understand why, but I often get PMs about this project asking me directly for help/updates/summaries. Anything I have to share is shared here. Read up and ask questions here if you can't figure it out, so the next person with the same question has a reference. Chances are that someone else can answer besides me. I tend not to reply to these questions via PM because it comes across to me as someone asking me to give them a personalized summary, and I don't have time for that.

For the record: there are aspects of this overall project that I have not released publicly, like an ID4-8 script and the RPi frontend that currently supports WMMT1-3DX+. If/when I'm ready to do so, it will be done here. Please don't PM me asking for updates. My main reason for not jumping into larger public releases with the frontend at this point is because I have little time or patience to manage the support questions that will inevitably come up. I have worked in support roles professionally in the past and have no interest in doing so in my free time.

Sorry if I sound cranky. I am and it's unrelated to this wonderful community. However, this project is low on my personal concerns list at the moment. I appreciate others' enthusiasm and interest in it.
 
winteriscoming said:
I tend not to reply to these questions via PM because it comes across to me as someone asking me to give them a personalized summary, and I don't have time for that.
Click to expand...
I get this ALL THE TIME with other stuff. usually my answer is: don't PM me questions, ask in the forum where it can benefit everyone.
 
@winteriscoming I just wanted to ping you to say thanks for these! The WMMT1/2 one works great and I can finally enjoy the game instead of resetting every time. :)

I've rehosted the projects on GitHub as it was difficult to find these by simple searches online and this particular board is behind a login wall.

https://github.com/GXTX/arcade_card_emus

I know you were working on some other stuff including creating fake cards with images and writing on them, I'd love to see those public (maybe even on github so you/we can track changes) so maybe other people could help bring it further along.
 
Last edited:
Got bored and decided to take a look into WMMT in an attempt to avoid just using reply attacks.

Code: 
[SYNC][COMMAND LENGTH][COMMAND][30][30][30][unk (always 03)?][checksum8 xor without sync]

Sync: 0x02
Chihiro waiting/ACK: 0x05
Reader ACK: 0x06

The first 30 is I believe a marker for card status with 30 being no card, 31 being there's a card and 34 it's a clean card.
No clue about 2nd 30, maybe writer or hopper status?
The 3rd 30 is likely a reader status, 30 idle, 32 reading, 33 cleaning.

If winteriscoming could've notated when he inserted cards, and when the hopper is empty that would also help.
 
Good afternoon.
In the card emu for WMMT, it seemed to restart the script to replace the cards, so I changed it to replace the cards when the cards are ejected.
The way to use it is to input the file name when you receive the card ejection command.
If there is no name, as in the first case, a new file will be created
Also, I'm not sure if it's right, but I've included image printing and font registration.
I tested it with a serial emulator, but I don't know if it works on a real machine.

So it would be helpful if you could test this script.
View attachment WMMTEMU_card_change.zip

※2020/05/11
When ejecting a card, it looks like the card is being pulled out.
Fixed to make it look like there is no card in the card after ejecting it.
Corrected a checksum and a typo of 7B command.
View attachment WMMTEMU_card_change_fix3.zip
 
Last edited:
Interesting that people are jumping in to work on these scripts at this point. Thanks for sharing.

I do have a version that supports printing with a RPI web-based frontend. It has a much improved workflow, and manages card ejection and changes. I'm just not ready to release it publicly. Maybe others can put together something better before I get there.
 
sakiranorium said:
Good afternoon.
In the card emu for WMMT, it seemed to restart the script to replace the cards, so I changed it to replace the cards when the cards are ejected.
The way to use it is to input the file name when you receive the card ejection command.
If there is no name, as in the first case, a new file will be created
Also, I'm not sure if it's right, but I've included image printing and font registration.
I tested it with a serial emulator, but I don't know if it works on a real machine.

So it would be helpful if you could test this script.
View attachment WMMTEMU_card_change.zip

※2020/05/11
When ejecting a card, it looks like the card is being pulled out.
Fixed to make it look like there is no card in the card after ejecting it.
Corrected a checksum and a typo of 7B command.
View attachment WMMTEMU_card_change_fix3.zip
Click to expand...
Good evening.
I used the WMMTEMU_card_change_fix3 script here to check the operation.
Cabinet name: Rewritable stage
System board: System 246/256
Game: The iDOLM @ STER

Since this game uses two cards, the card change function was necessary.
As a result, I was able to confirm the operation from the new game to issuing the first card, issuing the second card, and finally exchanging the cards and saving the data on both cards.
I can't print it for now, but it seems to be okay to play the game.
In the future, I would like to make improvements so that it will be easier to save data including printing and switch card data.

A big thanks to everyone who is developing.
For reference, the log for one game play is attached.
 

Attachments

  • log20200511.txt
    201.5 KB · Views: 160
You must log in or register to reply here.
Back
Top