What's new
By:
Filters

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

Here's an updated print test:
updated capture.PNG


I have figured out a way to make the large font narrower through scaling rather than direct font editing. This means even the Japanese characters that I have not been touching should still work and get scaled as needed.

The attached example also shows where the USED text would get printed on a WMMT2 card in the event that data was transferred to a new card. I also added an extra T to the end of the name to max out name characters to make sure it's printing with sufficient space between the name and USED.

I think I'm back to having pretty good alignment with the new method.

After reviewing an actual print of a discarded card, I realized that even though the print payload increases the font before it issues 13 spaces in front of "USED", it only counts them as normal (small) font spaces. I had been printing them as large font spaces and the USED text ended up outside of the white space. My rough solution to the issue is to just replace double spaces with a single space and go ahead and print them as large spaces, but I may rework it at some point. I'm not sure how much this will come into play for other cards.

I also fixed a bug where printing on top of already printed data was not working as intended. Blank spaces were actually wiping out existing underlying text. Now it will behave like an actual printer, where it's unaware of what's already on the card and will happily print over it. Short of an erase command, everything is additive.
 
I have started some logging for WMMT3 (original version) and the main difference this game has with the card reader from 1 and 2 is the baud rate. WMMT3 uses a baudrate of 38400, while WMMT1/2 use a baud rate of 9600bps.

At first glance, the protocol seems identical.

My printing script is actually handling the printed data packets pretty well:
WMMT3 first print Capture.PNG

The exception is the range section that is currently showing 22km. The actual print manipulates the font in a way my script isn't handling. The protocol is the same, but I just haven't run into a print that stretches the width of a font, but leaves the height the same. My experience prior to this was that fonts were just increasing both parameters 2x, so at the moment the script just looks for an increase command and if x or y are increased, it doubles the font size. I will have to take care to accommodate the nuance here, but I think it won't be an issue since I'm already scaling the text. I should be able to just scale one dimension when the command calls for it.
 
I recall playing with dip switches on the ID3 reader to change serial settings. I wonder if the WMMT1/2 printer has dip switch settings for baudrate and if it supports 38400bps. If it could, I think the hardware would be compatible with WMMT3. I assume WMMT3 reader can be configured for a lower baudrate to be compatible with earlier games. I have read that there are settings to make it so, but I'm not sure if they are documented anywhere readily available.

There are many dip switches on the WMMT1/2 reader, so it would likely be difficult guessing at baud rate changes.

Failing a setting to make the WMMT1/2 reader compatible, I would think a baudrate converter sitting in between the WMMT1/2 reader and WMMT3 game would work.

Anyway, that's not likely to be something I work on. I don't care much to have the card reader hardware running beyond initial analysis, though I do kind of like collecting them to sit on my shelf as artifacts of my accomplishments in this project. :D Unfortunately, I'm only borrowing the WMMT3 reader, so that one doesn't get to join the 3 others I have. :P
 
Yeah - wouldn’t need the reader as you are going to emulate that... :)

But the actual hardware board - I think it was a Namco specific board.

Matt
 
On another note. It doesn't appear that WMMT3 does anything fancy with regards to printing, other than the stretched width font for range mentioned earlier. I've got a solution in place for that. The script is now obeying font width changes more in line with how the printer would.

WMMT3 fixed Capture.PNG

*Note that I hard-coded the numbers into the distance to fill them out. My actual data file would have printed with spaces and then 22km.

I have a feeling that there's not going to be much more do for WMMT3 printing.

The more fun challenge will be Mario Kart, I think. It appears to make use of a lot of fun icons, like trophy icons. They could have made the WMMT cards more interesting with custom icons, but I guess they wanted to go more basic with simple information rather than flashy icons.

In WMMT 3Dx and 3Dx+ it looks like they print the game name up in the top right corner on the card. They didn't even do that in an interesting way. Its just simple text. They could have had the logo made up of a few icons and printed that...
 
So far it's not proving as easy as I had hoped to simply use the WMMT2 script. WMMT3 is pretty quickly not liking replies.
 
Last edited:
mathewbeall said:
I would love to get a WMMT3 board... :)
Click to expand...
They're highly unreliable, be careful what you wish for. I've had lots of issues with the four N2s I own.

Any chance that this WMMT3 card emulator knowledge could be used for editing real cards?
 
I am having no luck at all with a card reader script for WMMT3. I am pretty sure I'm putting together the same replies as the physical reader, but the N2 isn't accepting it.

I even went so far as to sniff the communications between the RPi and the N2, and I don't see any breakdown there.

It's possible it's a timing issue where the N2 expects a reply back much quicker than the script is generating, but I'm not sure.
 
which type/model WMMT3 reader is ?

these readers does ping-pong like:
Game Reader
>>> 02 followed by command etc data
<<< 06 (command received OK)
>>> 05 (request reply)
<<< 02 followed by reply data

I'd imagine it may be not happy if you send reply as single transfer - 06 02 data.
add: nwm, I see you handle this in script already, then yes, it might be some timing issue.
 
Last edited:
Yeah, as far as I see, I'm obeying the expected exchange.

The baudrate is higher, but the ID4-8 reader uses the same, and I got a script working for those, so I know my serial adapters are capable of running at 38400bps.

However, I likely do have something unexpected happening. I put together a test to drive the reader by sending it a command and got no reply.

WMMT3 first sends out a status command x20, and I reply with x06, and it sends x05 several times and does not accept the x20 replies I'm sending that to match what the real hardware sends and it never proceeds to send an initialize command.

The terrible thing about WMMT3 is that it refuses to recover from an error. If it starts out sending a x20 command, the only thing it will continue to send is a x05 command to get a status update, and this persists through switching between test menu and game mode. Even actual hardware will not sync if it's powered down and back up during the same session. It doesn't know what it's replying to, and a full reboot on the game is required. It's poorly implemented in my opinion, because an op would not be able to quickly reset the reader without a full reboot. It may behave differently in later versions of WMMT3.
 
winteriscoming said:
WMMT3 first sends out a status command x20, and I reply with x06, and it sends x05 several times and does not accept the x20 replies I'm sending that to match what the real hardware sends and it never proceeds to send an initialize command.
Click to expand...
do you really handle reader statuses ? I don't know format of this reader, but assuming it is similar to ID4-8 reply can be:
(card dispenser empty)
02 06 20 80 30 30 03 crc (shutter open, no card) or
02 06 20 40 30 30 03 crc (shutter closed, co card) or
02 06 20 83 30 30 03 crc (shutter open, card inserted) or
02 06 20 43 30 30 03 crc (shutter closed, card inserted).
(if card dispenser have some cards - 1st status byte should be |= 0x20)

perhaps game code goes crazy if you send single hardcoded reply for this command ?
 
The status bytes a more similar to the WMMT1-2 reader. There's no shutter. A normal state with no card inserted is 30 30 30.

In logs, the game sends a 20 command, reader sends 06, game sends 05, and reader sends 20 reply with 30 30 30. Then the game moves on to init (10) commands. So far I can't satisfy the first command. It uses the same XOR CRC byte at the end, and I'm calculating those correctly, but beyond that, I can't even succeed by sending the same hard-coded reply (i.e. I'm calculating nothing) the reader sends.
 
weird then. perhaps it uses some additional lines as GPIO ready/busy/etc status ? I recall in ClubCart game I've seen code which read CTS line state for this.
 
  • Like
Reactions: rtw
Not on this one. It is only wired for RX, TX, and GND. That's stock wiring. It doesn't even require loopback on CTS/RTS on the reader unit like the WMMT1-2 reader does.
 
I made a little progress. I put together a script to drive the reader and had some success sending commands and getting replies from the reader. I had not been successful doing that when I tried before.

A few things changed:
-I resoldered some loose wiring at a db-9 connector.
-I experimented with changing up baudrate and parity. I still believe the correct baudrate is 38400bps, but my main issue with my script may have been parity. I can't recall on the sniffing script if I had parity at NONE or EVEN, so I may have had that wrong on my script I was trying to interface with the N2. I'll go back and try that.
-I did these tests on my Windows PC instead of my underpowered Linux netboot or the RPi.

The remaining issue with regards to driving the reader itself, which is being done entirely to determine if my serial settings are correct, is that often the reader doesn't understand the command and gives a x15 reply. If I keep re-trying the same command, it will eventually give an 06 reply. With a lot of retries built in, I can get the reader to initialize with a script.
 
It turns out in my tests at driving the physical reader with the script, I was simply sending commands too quickly. After adding in some delays, I can get reliable communications going.

I believe based on these tests that I can more confidently confirm that the serial settings are: 38400pbs, byte size 8, parity even, stop bits 1
 
Guess who got through initialization in the game!

I'll have to test more later.

I think it was a combination of flaky wiring and incorrect settings working against me on my first attempts to interface with the game.
 
winteriscoming said:
Guess who got through initialization in the game!

I'll have to test more later.

I think it was a combination of flaky wiring and incorrect settings working against me on my first attempts to interface with the game.
Click to expand...
Great job - always good to get past a hurdle that doesn't make sense to exist.. :)
 
You must log in or register to reply here.
Back
Top