What's new
By:
Filters

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

good progress ) congrats.

make sure you understand correctly RESULT1 (sensors) bits. typical it's values is:
60 - door closed, dispenser full, no card inserted
A0 - door open, dispenser full, no card inserted
A1 - door open, dispenser full, card inserted in front of reader
B8 - door open, dispenser full, card fully pulled inside reader
78 - door closed, dispenser full, card inside reader

I'm afraid you wont be able that easy edit card save data, they are encrypted and checksum protected.
 
Is the encryption the reason why what the game sent to the card to store looks totally different than what had been read in prior to that?

I haven't gotten a chance to monitor what the card reader gives back compared to what was most recently written. I'm really hoping at least storing and returning card data is straight forward.

The main thing I would hope to change is the number of plays until servicing. I'm not sure what happens when a card reaches the point where it needs to be transferred to a new card. That would take a long time for me to get there to be able to monitor it.
 
I'm very happy to report that the saving is working the way I had hoped! What the game sends to the card is identical to what the reader sends back when reading the card.

There are slight differences in the initial command that is sent, but it will be very easy to cut out the necessary portion from what the NAOMI2 sends and translate it into something the card reader would send back.

What NAOMI2 sent out:
2016-02-26 10:30:14.588848: NAOMI2
02 D8 53 00 00 00 30 31 36
2E 5D 01 19 F8 68 8D 8D E7 8E 0D 0A 5B 72 C0 FE
87 B6 2E FA E7 D1 2A B5 25 59 4A E6 17 DF 79 37
7E 4C 8F D7 89 88 39 E6 61 33 C6 C6 AB 10 B4 88
13 BF 5D 10 20 7B A2 CA 6E F0 2C 7D E3 1E B9 5A
D3 68 8E 1C 56 3D 46 F9 AE C0 08 A3 97 66 D0 AC
46 DA 74 DC 3B DB 5C 89 9D 8C EF 76 56 40 87 30
8A 2B B5 C9 A8 A4 54 20 3B 94 11 57 D9 A1 D8 CE
8C DC 76 57 5B 1E 9E F7 A9 DB 06 B4 CB 14 19 AA
75 00 31 E8 7E 31 BF A8 94 E6 53 45 47 41 42 48
52 33 48 30 B2 62 EC 41 56 0B A4 39 2E C9 0D CC
9D ED 10 62 28 C2 05 FA C8 B4 B8 E2 70 0D DA F6
CF 29 A8 6E 72 D6 77 91 6E C1 4F 9F 89 9D C6 15
92 72 45 FC F2 3F 46 E6 27 BC C7 1F 74 D5 E9 03
90 05

What Reader gives back:
2016-03-06 09:08:06.801777: READER
02 D5 33 78 30 30
2E 5D 01 19 F8 68 8D 8D E7 8E 0D 0A 5B 72 C0 FE
87 B6 2E FA E7 D1 2A B5 25 59 4A E6 17 DF 79 37
7E 4C 8F D7 89 88 39 E6 61 33 C6 C6 AB 10 B4 88
13 BF 5D 10 20 7B A2 CA 6E F0 2C 7D E3 1E B9 5A
D3 68 8E 1C 56 3D 46 F9 AE C0 08 A3 97 66 D0 AC
46 DA 74 DC 3B DB 5C 89 9D 8C EF 76 56 40 87 30
8A 2B B5 C9 A8 A4 54 20 3B 94 11 57 D9 A1 D8 CE
8C DC 76 57 5B 1E 9E F7 A9 DB 06 B4 CB 14 19 AA
75 00 31 E8 7E 31 BF A8 94 E6 53 45 47 41 42 48
52 33 48 30 B2 62 EC 41 56 0B A4 39 2E C9 0D CC
9D ED 10 62 28 C2 05 FA C8 B4 B8 E2 70 0D DA F6
CF 29 A8 6E 72 D6 77 91 6E C1 4F 9F 89 9D C6 15
92 72 45 FC F2 3F 46 E6 27 BC C7 1F 74 D5 E9 03
B2

Saving out card data will be simple to do as plain text files.

During the portion where the game is prompting to enter a card would be the ideal time for the program to allow you to choose which card file to load.

I've still got a few steps to get through for a normal workflow after ending a game, but I'm pretty confident this emulator is going to work.

My only looming concern is how to deal with card servicing if I can't figure out a way to modify the saved data. It wouldn't be difficult simulating transferring data to a new card, it's just that I'm not even close to having a card that needs to be serviced so I can monitor the exchange. I'd basically have to start and complete a race 50 times with entering and ejecting my card each time. That sounds very tedious. 8|
 
I'm pretty happy about this. With my script I have successfully submitted card info and got all the way through a race, chose not to continue, read new data, ejected card and got the game back into Game Over mode.

The rest of what needs to be done shouldn't be too bad.

Here's some of what's left:
1. Monitor and duplicate process for purchasing new card.
2. Manage saving and recalling card data (should just be a matter of saving out and reading back in a text file).
3. Monitor and duplicate process for transferring data to new card at end of service period (or figure out how to edit saved data so that this count does not decrease).
 
Last edited:
This is awesome. Those cards are getting hard to come by and too expensive on ebay.
 
This has my interest as well...
System 246/256 uses two types of readers-
- one is connected directly to the EXCARD pcb- this model appears IDENTICAL to the slide in control panel readers found on many naomi games
- the other connects to the serial pins on the front of the unit, and is closer to the mechanized massive readers found on things like ID/VO4, etc.

I would NOT be surprised if in the end your work is usable there too.. as well on many other sega/namco platforms.
If you want to take a look, I can provide photos form my readers as well as spare cards to test with.
 
defor said:
This has my interest as well...
System 246/256 uses two types of readers-
- one is connected directly to the EXCARD pcb- this model appears IDENTICAL to the slide in control panel readers found on many naomi games
- the other connects to the serial pins on the front of the unit, and is closer to the mechanized massive readers found on things like ID/VO4, etc.

I would NOT be surprised if in the end your work is usable there too.. as well on many other sega/namco platforms.
If you want to take a look, I can provide photos form my readers as well as spare cards to test with.
Click to expand...
Do you have a reader for the Chihiro versions of WMMT or the Triforce Mario Karts? I think they use the same reader and I would love to figure something out for WMMT.
 
can't say i do- i've got a bunch of full setups for the simple reader in the control panel, but the more advanced one with the tractor feed and all, I've got a reader the schematics, and some cards for 246/256 games, I still need to wire it up to a pcb
 
Now that I'm experimenting with saving down card data and interpreting the card value from the write command that the game sends out, I'm struggling a lot with how Python handles byte data that it sends out over serial.

If I hard code a byte to contain the values I want, it works fine. But if I have those values in a string or an array and transfer them to a byte variable (using all kinds of various conversion methods I could find) for sending, the game rejects them...

For example, I can assign the following to a byte an have the game read in the card fine:
output =b"\x02\xD5\x33\x78\x30\x30\x0E\x16\x71\x3F\x7A\x07\x61\x12\x38\xF6\x8E\x6F\xB7\x51\xA7\x54\xAA\xA5\x30\x87\xA6\xCD\x1A\xB4\xEF\xBA\xCB\x63\x72\xCD\x0D\xF3\x3C\xD7\xA9\xF6\x7E\x51\x1C\x5A\x39\x47\xF6\xA0\x64\xC3\x19\xD7\x9B\x74\x3A\x9B\x28\x0C\x47\x56\x7B\x55\xA1\x13\xA8\x10\xDF\x7F\xEE\x4F\xEE\x0B\x46\x2F\xD7\x4D\x62\x39\x52\xA8\xCD\x6F\x9D\x16\x95\x71\x02\xDA\x01\x2C\x68\xF8\xD6\x6E\x1D\x52\xF3\xA4\xD4\xD0\x12\x76\xF3\x51\xC8\x28\xEE\x38\xE1\xD5\xE2\xFE\xF2\x09\x39\x95\xC2\x12\x28\x5E\xB6\x61\xB3\xE4\x16\x37\xE6\x89\x6C\x88\x69\xC3\x41\xF9\x30\xEE\x24\x42\x26\xEE\x32\xED\x53\x45\x47\x41\x42\x48\x52\x33\x2E\x34\x77\xF3\x15\x72\x45\x74\xA4\xED\xA1\x10\x68\xD0\x1C\x98\x9D\xA9\xBC\xA2\xC5\x35\x0D\xDD\x31\x35\xEB\xFA\x1D\xCB\x8B\x0D\x3E\xD6\xFA\xC1\x0E\xE5\xFE\x53\xB7\x4B\xBE\x5A\xF5\xC7\xAC\x6F\xED\x6D\x9A\x59\x98\x09\xCC\xFC\x9F\x6E\x3E\x16\x50\x03\xD6"

But if I have this in text, my issue is converting it to the same byte value.
ByteString = "02 D5 33 78 30 30 0E 16 71 3F 7A 07 61 12 38 F6 8E 6F B7 51 A7 54 AA A5 30 87 A6 CD 1A B4 EF BA CB 63 72 CD 0D F3 3C D7 A9 F6 7E 51 1C 5A 39 47 F6 A0 64 C3 19 D7 9B 74 3A 9B 28 0C 47 56 7B 55 A1 13 A8 10 DF 7F EE 4F EE 0B 46 2F D7 4D 62 39 52 A8 CD 6F 9D 16 95 71 02 DA 01 2C 68 F8 D6 6E 1D 52 F3 A4 D4 D0 12 76 F3 51 C8 28 EE 38 E1 D5 E2 FE F2 09 39 95 C2 12 28 5E B6 61 B3 E4 16 37 E6 89 6C 88 69 C3 41 F9 30 EE 24 42 26 EE 32 ED 53 45 47 41 42 48 52 33 2E 34 77 F3 15 72 45 74 A4 ED A1 10 68 D0 1C 98 9D A9 BC A2 C5 35 0D DD 31 35 EB FA 1D CB 8B 0D 3E D6 FA C1 0E E5 FE 53 B7 4B BE 5A F5 C7 AC 6F ED 6D 9A 59 98 09 CC FC 9F 6E 3E 16 50 03 D6"

I've interpreted each value has hex and assigned to an integer array and converted that to a byte array. I've tried going value by value in a loop and just translate each value to a byte and send that one at a time. I've tried reformatting the string to have "\x" instead of spaces and convert that to a byte.

I'm in Python 3, and not that familiar with Python in general. Data conversion wasn't supposed to be a stumbling block, though... :P Anyone have any ideas?
 
I'm definitely interpreting the hex values as integers correctly (can display them as hex, dec, etc), so I think I'm good to go on that front.

I'll look more into appending the values together. I don't know why I wouldn't be able to go through an array value by value and write those out, though.
 
I'll have to play around with it. The serial script I started with is reading everything in as hex characters in a string, like the logs I've shared. So I was trying to keep with that format.
 
Last edited:
I'm definitely not that great of a programmer. Most of what I've done so far is actually kind of "dumb". It does not interpret what the game is asking for, but just looks for specific strings in the request and replies back with exact answers I found in the logs.

I just experimented with saving down binary and reading it back in to a byte variable. That's just as easy as working with text files as far as storing the data goes.

If I read in the data as binary directly from serial, I'll still have to figure out a way to parse out and append what I need. That may still ultimately be easier than converting binary read in from serial to string (script was already doing that), interpreting values from string (figured that out already), appending what I need (figured that out), calculating checksum (figured that out), convert everything back to bytes that can be correctly sent back over serial (stumbling there).
 
I really like where this is going. I'll try to see if I can find other socketed Eproms and help filling those gaps.
 
Darksoft said:
I really like where this is going. I'll try to see if I can find other socketed Eproms and help filling those gaps.
Click to expand...
If you're able to find an eprom for WMMT or Mario Kart and they're compatible with my reader, I've got a rom burner and could swap that in for testing/monitoring. I don't have Triforce, though, so could only test with WMMT.

I guess the question is whether or not they use the same hardware as the reader I have for ID. PDFs manuals of the Namco readers make me think they're similar hardware, but may ultimately be incompatible.
 
I got it working!

I'm really not sure if my original struggle was with converting to binary data or if I had messed up the way I was responding when sending the card data back in (didn't append 06 like I had been with every other response)... I messed with both today, so it could have been both.

I can successfully write out card data and read it back in.

I currently have it read in and save out to a specific binary file. It's successfully saving new versions of the card data because the number of plays until servicing is decreasing each time I load up.

Still need to:
1. Monitor and duplicate process for purchasing new card.
2. Monitor and duplicate process for transferring data to new card at
end of service period (or figure out how to edit saved data so that this
count does not decrease).
3. Allow card selection at the point where the game asks for you to insert card - or specify card at beginning of script (easier, but makes you stick with one card until you restart it).
4. Clean up code before sharing with anyone. It's a mess! :S
5. Port code to RPi and test that it works there. I'm really hoping this ends up being pretty easy since I think I'm sticking with portable Python code. My initial plan would be to use the same USB serial adapter with the RPi rather than GPIO pins. I think the adapter manages signal voltage difference (if there are any?) and I don't want to mess with that in a custom GPIO adapter. Adapters are $10 and work, so no reason to invest time in figuring out another solution. Anyone else can feel free to do so, though.
 
Also, I want to give a big shout out to MetalliC.

He has done an awesome job interpreting what a lot of the commands and responses are, which helped me understand a little better how to skip over some of the status checks and give an acceptable final answer.

I don't think I would have ever figured out the CRC (simple XOR - and super simple to calculate in Python) without his brilliance either!
 
I'd be interested in seeing your code once you're ready to share. i don't have a ID3 setup but I do have a NAOMI 2 with pi-force so I could definitely test it out/play around with it a bit.
 
twistedsymphony said:
i don't have a ID3 setup
Click to expand...
Maybe boot it up in your VO cab and try to drive with the sticks if they map up? :P


Darksoft said:
I really like where this is going.
Click to expand...
Off topic, but I'm excited about your work on Atomiswave2Naomi. I see the couple of driving games are listed as works in progress due to analogue controls. When/if you get to it, if you need testers in a OR2SP cab (identical to ID3 for wiring/controls), I'm willing to test.
 
You must log in or register to reply here.
Back
Top