What's new
By:

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

winteriscoming said:
I tell you what! You're the key to unlocking every mystery I come across in these card reader emulator projects!
Click to expand...
lol, it is because I've spent quite many time when RE'ing earlier Maxell's reader for VF4/Dino/Love&Berry, mostly in software way (no logs or card dumps), analyzing game code and set data in emulator, so I know this thing quite well.
reader in ID4 looks like natural evolution of previous one - 8byte SN# and password, 8x 16bit counters instead of 4x 8bit, etc but in general it is same thing, which works using same basic principle and commands.

so the key is - research for understanding how things works, but not just blindly supply games with some void/unk data bytes to make them happy ;)

winteriscoming said:
I'm curious though how you read the CMD variable and get the address from it? Like how does C0 translate to x30-x31, 30 translates to x32-x33, etc?
Click to expand...
in short, if you have command like 6D byte0 byte1 - write bytes in reversed order (byte1 byte0), then convert to binary form, position of pair of set bits will be "offset", ie
6D 00 C0 -> C0 00 -> 11000000 00000000 = counter # 0 (ie offset 30h)
6D 00 03 -> 03 00 -> 00000011 00000000 = counter # 3 (ie offset 36h)
6D 03 00 -> 00 03 -> 00000000 00000011 = counter # 7 (ie offset 3Eh)
Code: 
0 1 2 3  4 5 6 7
xxxxxxxx xxxxxxxx
 
I was able to successfully write to the header of my test card, but I have not been able to change it back to being seen as a blank, usable card. Unfortunately I do not have a log of what this card looked like before it was written in the test write, so not sure if I can put it back where it was.

The best I could do during my tests so far was change it to be seen as an unrecognized card, and then back to being recognized.
 
I think what is happening is that the game checks the counters in the header to make sure they have not been decrement and checks the location where "InitialD" is stored to tell that it's a new card.

I don't seem to be able to write to the counters and reset them. I would guess the counters are locked from normal writing and are intended to only be decremented with the 6D command.

Therefore at this time I do not believe I can alter a used card to reuse it.
 
Hello, I just got word of this project and wanted to rush over. I have been nursing my Initial D V3 card readers for about three years and pulling all my hair out.

Long story short, I was theorizing that you could use a credit card swiper instead of the magna card reader...

Any thoughts on possibly putting a Rasberry PI with a card reader and making it spoof the old magna readers?
 
LdrJagMan said:
Hello, I just got word of this project and wanted to rush over. I have been nursing my Initial D V3 card readers for about three years and pulling all my hair out.

Long story short, I was theorizing that you could use a credit card swiper instead of the magna card reader...

Any thoughts on possibly putting a Rasberry PI with a card reader and making it spoof the old magna readers?
Click to expand...
It's not one of my goals, but someone could probably do something with magnetic strip cards. The challenge in my mind is that a swipe is a temporary action, whereas the stock cards are drawn into the reader for the duration of gameplay and ejected to write again. The idea of having to swipe to play and swipe to stop does not seem intuitive.

Note that there is already a script for ID3 linked to in the first post. It just uses files instead of any physical media. Have at it and try to integrate other features if you want.
 
I have a idea to work in a integrity check by using lighted card readers and writers... Ill pick up the code and see what I can do with it. Wish me luck, because If I can get this to work we can completely replace the need for those old magna cards on the cabs... and not have to worry about the 50 plays issue.
 
you could replace mag-strip with smartcards pretty easy.
 
I received my order of US ID4 cards today and recorded a log in Export ID4 for reading a blank card in test mode and starting a new game with new card purchase.

So I should now have card data that will work with ID4 as previous attempts at using JP cards would not work.

My hope is to either get away with using the same header/authentication info for all simulated cards for a given game or perhaps be able to generate random auth codes. The game uses the code to generate a password to be able to read/write the card, so my script can simply allow access without knowing if the password was generated properly, and without me understanding how the passwords are generated.

I'm optimistic that I will be able to put together a card reader script for ID4/5. I want to make this one better than my previous attempts, so it will probably take longer to accomplish.
 
I have reconstructed card data from my logs from ID5 into a card file and can pass all tests in the test menu.

I also successfully booted the game with the card data file and it loaded up without error.

Something is happening in-game when trying to end and eject the card. I haven't gotten to look at why, but it looks like it goes through several cycles of writing the card and then gives an error. Inserting the newly saved card results in an error, so something about the way data is written in game is different than the test mode.
 
winteriscoming said:
I have reconstructed card data from my logs from ID5 into a card file and can pass all tests in the test menu.

I also successfully booted the game with the card data file and it loaded up without error.

Something is happening in-game when trying to end and eject the card. I haven't gotten to look at why, but it looks like it goes through several cycles of writing the card and then gives an error. Inserting the newly saved card results in an error, so something about the way data is written in game is different than the test mode.
Click to expand...
I can't remember exactly what is happening at the moment but prior to end of race, 'mileage' is updated on the card in ID6,7,8. Right before the 'please eject card' message, this is when the card reader is somewhat holding the card in the reader until the mileage is recorded. Basically tracks how many kilometers that specific vehicle has traveled in the last session. I'm wondering if the situation you are encountering is happening during this period of the card eject sequence.
 
freddiefiasco said:
winteriscoming said:
I have reconstructed card data from my logs from ID5 into a card file and can pass all tests in the test menu.

I also successfully booted the game with the card data file and it loaded up without error.

Something is happening in-game when trying to end and eject the card. I haven't gotten to look at why, but it looks like it goes through several cycles of writing the card and then gives an error. Inserting the newly saved card results in an error, so something about the way data is written in game is different than the test mode.
Click to expand...
I can't remember exactly what is happening at the moment but prior to end of race, 'mileage' is updated on the card in ID6,7,8. Right before the 'please eject card' message, this is when the card reader is somewhat holding the card in the reader until the mileage is recorded. Basically tracks how many kilometers that specific vehicle has traveled in the last session. I'm wondering if the situation you are encountering is happening during this period of the card eject sequence.
Click to expand...
No clue - in the commands I saw blazing by, I wasn't seeing any that were unfamiliar. At the moment I'm not decrementing any counters, but that doesn't look like the spot where it's getting hung up. Unfortunately the test was on ID5, so I don't know what it said was happening, nor the error. I'll probably get an ID4 card file together and see what happens there.
 
winteriscoming said:
At the moment I'm not decrementing any counters
Click to expand...
in theory this might cause problems.
at least in Sega games for Naomi and SP hardware games remember in NV memory RF tags IDs and counter values after decrement. so, games check these values during each run and will reject RF tag if will be noticed counter becomes bigger than it was before.
 
The issue doesn't appear to be related to counters, but I will have to do some analysis of logs to tell for sure. I have implemented counter decrement into my script.

My assumption at the moment is that there is a bug in the way I am saving data. I think the way I am sending data is OK because I can get the game to load a simulated card.

Unfortunately these games take forever to boot, so testing is slow... ||
 
So my understanding of the writing procedure is a little off.

I was assuming the 8D command set a specific position:
02 09 D1 00 00 00 8D 00 0C 03 5A

So I would set the current position to 0C (offset: 0x60). However, what actually seems to be happening is that the variable sent in this command is supposed to increment the current position by that amount. So if my current position is 5D, then the command is telling me to set the position to x5D + x0C = x69 - or offset: 0x348

So the reply would be dependent on current position (which I am tracking) plus the value from the command:
02 09 D1 63 30 30 8B 00 69 03 5A


It appears, based on my logs, that the position should be set back to 0 after any read command.

So definitely the way I am currently saving data is incorrect. No wonder the game freaks out when trying to save!
:P

I have a feeling that my write test in the test menu succeeded because it is only setting the address once and relying on the position to increment itself after every write command where it just writes line after line in sequence.

In game, it's setting the address a lot to just write the necessary data rather than rewriting the entire card.
 
Last edited:
Success!

I have successfully saved updated card info from ID4 and loaded it back up without error.

That was a major milestone.

A few more goals:
1. Test if ID code can be changed to generate new cards.
2. Get script to load blank card from hopper - game does not allow blank card entered into the front for new games.
3. See if game is tracking counters or if they can always stay full.
 
Last edited:
I put together a blank ID4 US card based on my logs. I edited the ID code to be FF FF FF FF and successfully simulated purchasing a new card with data written to my card file!

The game does not appear to care about the ID. It doesn't appear to be informing any kind of stored checksum or anything, so the good news is that a random ID should be possible in order to make unique cards. This will be needed if it turns out the game tracks cards based on ID. If it doesn't care about multiple cards with the same ID, then this won't matter.

At least for ID4 US a blank card appears to have specific data in the header, including counters, and then everything else is filled with FF. I haven't gotten into attempting something similar with ID5.
 
winteriscoming said:
I put together a blank ID4 US card based on my logs. I edited the ID code to be FF FF FF FF and successfully simulated purchasing a new card with data written to my card file!

The game does not appear to care about the ID. It doesn't appear to be informing any kind of stored checksum or anything, so the good news is that a random ID should be possible in order to make unique cards. This will be needed if it turns out the game tracks cards based on ID. If it doesn't care about multiple cards with the same ID, then this won't matter.

At least for ID4 US a blank card appears to have specific data in the header, including counters, and then everything else is filled with FF. I haven't gotten into attempting something similar with ID5.
Click to expand...
This might be a ways off (or I have asked already) but I'm curious if that ID code correlates to the card restore IDs in TEST. I know that when one of my cards was corrupted, I was able to restore it from one of the IDs that was in TEST. Huge leap in assuming that ID is probably only used for restoration purposes considering that the times/story status are loaded from the current card that is loaded and the saves are only written to the card before stage selection and after stage completion.
 
You must log in or register to reply here.
Back
Top