What's new
Part 2:
2016-04-22 16:50:58.236059: READER
02 06 7D 31 30 33 03 4A
2016-04-22 16:50:59.267293: Chihiro
05
2016-04-22 16:51:00.298563: Chihiro
05
2016-04-22 16:51:01.329815: Chihiro
05
2016-04-22 16:51:02.376692: Chihiro
05
2016-04-22 16:51:03.407944: Chihiro
05
2016-04-22 16:51:04.454822: Chihiro
05
2016-04-22 16:51:05.470430: Chihiro
05
2016-04-22 16:51:06.486056: Chihiro
05
2016-04-22 16:51:07.517328: Chihiro
05
2016-04-22 16:51:08.564204: Chihiro
05
2016-04-22 16:51:08.564204: READER
02 06 7D 02 06 7D 31 30 30 03 49
2016-04-22 16:51:10.001707: READER
06
2016-04-22 16:51:10.032957: Chihiro
02 08 7D 00 00 00 01 17 03 60 05
2016-04-22 16:51:10.236064: Chihiro
05
2016-04-22 16:51:11.486085: Chihiro
05
2016-04-22 16:51:11.501692: READER
02 06 7D 31 30 33 03 4A 02 06 7D 31 30 33 03 4A
2016-04-22 16:51:12.501693: Chihiro
05
2016-04-22 16:51:12.517319: READER
02 06 7D 31 30 33 03 4A
2016-04-22 16:51:13.532964: Chihiro
05
2016-04-22 16:51:14.564216: Chihiro
05
2016-04-22 16:51:15.611075: Chihiro
05
2016-04-22 16:51:16.642326: Chihiro
05
2016-04-22 16:51:17.689222: Chihiro
05
2016-04-22 16:51:18.704830: Chihiro
05
2016-04-22 16:51:19.720476: Chihiro
05
2016-04-22 16:51:20.767353: Chihiro
05
2016-04-22 16:51:21.798586: Chihiro
05
2016-04-22 16:51:22.829857: Chihiro
05
2016-04-22 16:51:22.876714: READER
02 06 7D 31 30 30 03 49
2016-04-22 16:52:53.314404: READER
06
2016-04-22 16:52:53.455033: READER
06 02 06 53 31 30 33 03 64
2016-04-22 16:52:53.580035: Chihiro
02
4E 53 00 00 00 30 31 30 51 76 00 00 7F 7E 82 90 FF 0A 09 17 02 00 A0 22
00 00 00 00 01 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 A2 00 00 00 00 00 00 00 00 00 00 00
26 06 00 00 02 03 31 02 4E 53 00 00 00 30 31 30 51 76 00 00 7F 7E 82 90
FF 0A 09 17 02 00 A0 22 00 00 00 00 01 C0 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A2 00 00 00
00 00 00 00 00 00 00 00 26 06 00 00 02 03 31 05 05 05
2016-04-22 16:52:54.517537: Chihiro
05
2016-04-22 16:52:55.580038: Chihiro
05
2016-04-22 16:52:55.595664: READER
02 06 53 31 30 30 03 67
2016-04-22 16:52:57.939418: Chihiro
02
9B 7C 00 00 00 30 30 01 11 82 69 82 68 82 6C 82 50 0D 4E 49 53 53 41 4E
20 53 4B 59 4C 49 4E 45 0D 47 54 2D 52 20 5B 42 43 4E 52 33 33 5D 0D 11
4E 20 43 6C 61 73 73 0D 11 82 52 82 51 82 4F 82 67 82 6F 81 5E 14 42 0D
20 20 20 20 81 9C 20 20 20 20 20 20 20 20 0D 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 0D 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0D 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0D 20 55 52 59 38 42
35 59 57 32 38 4E 35 42 53 4E 03 97 05
2016-04-22 16:52:58.001918: READER
06 02 06 7C 31 30 33 03 4B
2016-04-22 16:52:58.048794: Chihiro
05
2016-04-22 16:52:58.158150: Chihiro
05
2016-04-22 16:52:58.658170: Chihiro
05
2016-04-22 16:52:59.298796: Chihiro
05
2016-04-22 16:52:59.736297: READER
02 06 7C 31 30 33 03 4B
2016-04-22 16:52:59.908153: Chihiro
05
2016-04-22 16:52:59.923797: READER
02 06 7C 31 30 33 03 4B
2016-04-22 16:53:00.548779: Chihiro
05
2016-04-22 16:53:01.205050: Chihiro
05
2016-04-22 16:53:01.845657: Chihiro
05
2016-04-22 16:53:02.470659: Chihiro
05
2016-04-22 16:53:03.095659: Chihiro
05
2016-04-22 16:53:03.720661: Chihiro
05
2016-04-22 16:53:04.376931: Chihiro
05
2016-04-22 16:53:04.392556: READER
02 06 7C 31 30 30 03 48
2016-04-22 16:53:05.455058: READER
06 02 06 80 31 30 33 03 B7
2016-04-22 16:53:05.501914: Chihiro
02 06 80 00 00 00 03 85 05 05
2016-04-22 16:53:05.642558: Chihiro
05
2016-04-22 16:53:05.658165: READER
02 06 80 31 30 33 03 B7
2016-04-22 16:53:05.814433: Chihiro
05
2016-04-22 16:53:05.830059: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:06.126915: Chihiro
05
2016-04-22 16:53:06.142560: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:06.470667: Chihiro
05
2016-04-22 16:53:06.486293: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:06.767560: Chihiro
05
2016-04-22 16:53:06.783167: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:07.095687: Chihiro
05
2016-04-22 16:53:07.111292: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:07.408169: Chihiro
05
2016-04-22 16:53:07.423795: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:07.751919: Chihiro
05
2016-04-22 16:53:07.767544: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:08.048812: Chihiro
05
2016-04-22 16:53:08.064420: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:08.361295: Chihiro
05
2016-04-22 16:53:08.376920: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:08.720670: Chihiro
05
2016-04-22 16:53:08.736315: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:09.033190: Chihiro
05
2016-04-22 16:53:09.033190: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:09.345672: Chihiro
05
2016-04-22 16:53:09.361316: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:09.658172: Chihiro
05
2016-04-22 16:53:09.673817: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:10.001941: Chihiro
05
2016-04-22 16:53:10.017548: READER
02 06 80 34 30 30 03 B1
2016-04-22 16:53:10.298818: Chihiro
05
2016-04-22 16:53:10.314443: READER
02 06 80 30 30 30 03 B5
 
A few observations on WMMT:

-There seems to be card r/w activity happening in the middle of a race. I can hear the unit moving and glanced over to see logs being generated.

-Even though the DOC cards can be used for storing the data for WMMT, it appears that maybe the ink is supposed to be able to be wiped away for updated info to be printed, which isn't working on these cards. The card I used for this test now has big black smears across it.

-As far as I can tell, the actual data being written/read is smaller than ID3. Here's what I believe to be card data from the above test with beginning characters and checksum from the respective source removed. This is the data originally written to the card the first time and then subsequently read back in.
HEX:
51 76 00 00 7F 7E 82 90 FF 0A 09 17 00 00 A0 21 00 00 00 00 00 C4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 00 00 00 00 00 00 00 01 00 00 00 D6 05 00 00 02 03

-I'd have to run it through again to tell for sure, but the data may be encrypted similar to ID3. At the very least, ASCII doesn't show anything legible.
ASCII:
Qv...~‚.ÿ..... !.....Ä..............................Q...........Ö.....

-Similar to ID3, some of the actual printing commands are ASCII, with car name and I believe online code at the end being legible:
›|...00..‚i‚h‚l‚P.NISSAN SKYLINE.GT-R [BCNR33]..N Class..‚R‚Q‚O‚g‚o.^.B. .œ . . . . URY8B5YW28N5BSN.—.
 
Last edited:
-Even though the DOC cards can be used for storing the data for WMMT, it appears that maybe the ink is supposed to be able to be wiped away for updated info to be printed, which isn't working on these cards. The card I used for this test now has big black smears across it.
afair in the docs was mentioned several printer types, perhaps WMMT uses some other ?

-As far as I can tell, the actual data being written/read is smaller than ID3.
I recommend you to read Japanese docs. card's magnetic strip consists of three data 'tracks', each 69 bytes long, last command parameter byte select which one or several at once of them must be read or written.
so for example WMMT's 4E 53 00 00 00 30 31 30 means: 53 - write command, last 30 - first data track selected, so only 69 bytes will be written here.
in the case of ID3 R/W commands last number is 36 which means all 3 tracks read/written at once.
didn't yet analyzed WMMT logs, but at least DerbyOwners games uses sequential data track access features, like write first track, then read 2nd, etc


Here's what I believe to be card data
you missed first 2 bytes, 51 76 is card data as well

thanks a lot for logs
 
you missed first 2 bytes, 51 76 is card data as well
Corrected. I compared the output and input too quickly and cut those off.

didn't yet analyzed WMMT logs, but at least DerbyOwners games uses sequential data track access features, like write first track, then read 2nd, etc
so for example WMMT's 4E 53 00 00 00 30 31 30 means: 53 - write command, last 30 - first data track selected, so only 69 bytes will be written here.
A quick review of the logs for WMMT make me think it's not reading/writing multiple tracks. Maybe as progress is made more tracks are included? I'm only seeing the 53 command sent twice each time with the exact same track (30) and data.

Also, when comparing what was written both times, I see a lot of similarities in the data. Maybe it's not encrypted? Once I get around to sending card data to the game with an emulator, I can play around with editing the data.

Data written the first time:
51 76 00 00 7F 7E 82 90 FF 0A 09 17 00 00 A0 21 00 00 00 00 00 C4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 00 00 00 00 00 00 00 01 00 00 00 D6 05 00 00 02 03

Data written the 2nd time:
51 76 00 00 7F 7E 82 90 FF 0A 09 17 02 00 A0 22 00 00 00 00 01 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A2 00 00 00 00 00 00 00 00 00 00 00 26 06 00 00 02 03


Maybe WMMT doesn't keep track of as much data as ID3? If so, I wonder how they manage all of the tuning options which are more robust than ID3. I guess the game could just store a simple value in some of these bytes that indicates what options were chosen. There probably aren't too terribly many combinations. I think ID3 stores a lot time records on the card. I'm not sure if WMMT does. I don't have its View Change button wired up to be able to scroll through the data when it loads in.
 
I put in an actual WMMT card into the reader and confirmed that the ink is being erased. Therefore my conclusion is that DOC cards are not an appropriate replacement, even though the data can be stored to and read from them.

I wonder if a stock card could potentially be wiped clean and reused if you sent the wipe command to the printer and reloaded it into the hopper.
 
Here's some sequential card data as I progressed:

51 76 00 00 7F 7E 82 FF FF 0A 07 17 02 00 20 22 00 00 00 00 01 C4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 00 00 00 00 00 00 80 00 00 00 00 46 06 00 00 04 03

51 76 00 00 7F 7E 82 FF FF 0A 07 17 06 00 20 22 00 00 00 00 02 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A4 00 00 00 00 00 00 80 00 00 00 00 9A 06 00 00 04 03

51 76 00 00 7F 7E 82 FF FF 0A 07 18 7E 00 20 22 00 00 00 00 44 BC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8D 02 00 00 00 00 00 80 00 00 00 00 3C 07 00 00 04 03


So far I'm not seeing where other data tracks are accessed.

My guess is that driver name and car info are stored in those bytes at the beginning that are remaining constant.

I believe it's wiping all printed data and reprinting each time the card is ejected.

Furthermore, there's a lot of activity in the reader unit at the beginning of every race and every time tuning is complete. It seems to have been handled inefficiently. I would have thought they could handle it like ID3 where nothing is physically printed until the card is ready to be ejected. It seems like with all the activity in the middle of gameplay, it puts more strain on the unit than is needed. Like every time HP is upgrade, I think it's wiping and reprinting in the middle of gameplay.
 
Comparison between 2 cards.
Same car and color chosen on both.

Card 1: Name: JIM
51 76 00 00 7F 7E 82 FF FF 0A 07 18 7E 00 20 22 00 00 00 00 44 BC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8D 02 00 00 00 00 00 80 00 00 00 00 3C 07 00 00 04 03

Card 2: Name: JIMMY
51 76 00 00 7F 7E 82 82 8E 0A 07 17 02 00 20 22 00 00 00 00 01 C4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 00 00 00 00 00 00 80 00 00 00 00 58 05 00 00 04 03

You brilliant cryptologists and programmers here are probably going to laugh at my amateur analysis. ;)

I believe the names in each are saved as follows:
7F 7E 82 FF FF
7F 7E 82 82 8E

There are a total of 5 spaces available for a name. Each one begins with JIM (7F 7E 82). The first would have the 4th and 5th blank characters blank. The 2nd one shows that M is repeated in the 4th space.

I can comprehend decimal values a little better, so let's look at 7F 7E 82 in DEC:
127 126 130

"J" is shown as being 1 higher than "I", which it is both alphabetically and in the list of letters to choose from when entering the name. "M" is shown as 3 higher than "J", which checks out. "Y" ends up being 12 higher than "M" which also checks out!

So I think it will be pretty easy to figure out names, at least the alphabetical characters. I may take a picture of the name entry screen and maybe the values for non-alphabetical characters will just correspond to the position on the chart.

And somewhere on here is going to be # of plays, so I suspect I'll be able to edit that so that it never increments!
 
Just a thought but since it looks like its not using standard hex to ascii character maps to send the names over to be store/written on the card, any chance you could map out the hex values to letters and numbers using the name entry as suggested and using those codes to search your data to see where/if the car name and power output etc, is being sent instead of using a standard hex to ascii program to look. If that makes sense.
 
Just a thought but since it looks like its not using standard hex to ascii character maps to send the names over to be store/written on the card, any chance you could map out the hex values to letters and numbers using the name entry as suggested and using those codes to search your data to see where/if the car name and power output etc, is being sent instead of using a standard hex to ascii program to look. If that makes sense.
I doubt car data is stored similarly. Given the relatively small number of cars, one way would be to assign a number to each one. Say there are 20 cars and they are numbered 1-20. A single byte could store that. Then there's car color. Again, relatively few choices.

That's just a guess, though.
 
I've got a working emulator together for WMMT. It works for starting a new game and buying a new card or inserting an existing card.

I'm still testing some things, but I discovered an additional layer of checksum in the card file. I believe it's Checksum-8 from the beginning of the data to byte 59, with the checksum being in byte 60. One time I was able to successfully edit driver name, but my tests since then haven't been working out, as the game gives an error indicating that the card should be inserted again.
 
The WMMT card emulator is working out well so far. I'm almost through all the races that are selectable initially. So far the data has been consistently written to the first data track on the card.

I'm not sure why, but all attempts at editing card data are now resulting in failure. There might be some third checksum that happened not to change the one time I successfully edited driver name. Unfortunately I don't have that card data anymore. I'm going to have to analyze some more card data to see if I can figure this out.

I can confirm that this game writes card data down to the card at the end of every race. It actually looks like it happens twice every time. Whereas ID3 is writing to the card only about 50 times before making you get a new card, if you kept playing WMMT without quitting, the game could theoretically write to the card an infinite amount of times without decrementing number of plays until servicing. I would guess the 50 play limit is relatively arbitrary. Assuming you played 2 races every time you loaded up the cards, you're potentially writing to it 200 times in 50 sessions.
 
Great work you're doing here. I can't help (no ID3 cab), but following you. If sometimes you need a tester for you emulator, just ask. I've got Naomi/Naomi 2/Chihiro with NetBoot and CF, Lindbergh multi, an OutRun2 cabinet, some Raspberries or old PCs.
 
Great work you're doing here. I can't help (no ID3 cab), but following you. If sometimes you need a tester for you emulator, just ask. I've got Naomi/Naomi 2/Chihiro with NetBoot and CF, Lindbergh multi, an OutRun2 cabinet, some Raspberries or old PCs.
You're welcome to try the ID3 card emulator. I'll try to better organize the info at some point, but the file, hardware, wiring and directions are buried in this thread somewhere. :P

Playing these card based games with the ability to actually save progress and resume adds a whole new level of awesome in home use. I don't think ID3 even upgrades your car if you play without a card. WMMT at least lets you upgrade your car without a card, but you lose all progress when you quit.

I currently have run it on my Windows 10 and Windows 7 laptops. I'd like to get it running on Rasberry Pi, but I'm not sure how I want to handle it. If someone had PiForce Tools running, ideally it could run concurrently and maybe utilize the built in monochrome LCD and buttons. I don't know that I'm going to ever set up that specific hardware for myself, so I don't think I'll be the one to integrate the two. It very possibly could end up being made to run on a PiZero as a cheap dedicated card r/w emulator device, but I'm not sure how I'd handle choosing card files without integrating a screen and some kind of input like a keypad.
 
well done.

is there any chance you can dump ROM from WMMT reader ?
Here you go, sir! :D

EPROM chip is: ST brand M27C1001

Label says:
CRP1231LR10 8B16
Ver. 01.10 (Japanese characters)
01/10/12 NA
(Japanese characters) : ME163-5258Z01
IMG_20160429_101924.jpg
 

Attachments

  • wmmt crw rom.zip
    37.6 KB · Views: 142
great thanks.
after quick compare I see a lot of differences with ID3 firmware, so this is seems really new revision with numerous changes, not just a few protocol changes with goal to make them not compatible with each other, as I was (mistakenly) thinking.
 
great thanks.
after quick compare I see a lot of differences with ID3 firmware, so this is seems really new revision with numerous changes, not just a few protocol changes with goal to make them not compatible with each other, as I was (mistakenly) thinking.
Yeah, there's something physically happening that's different between the 2. I'm not sure what the "ink" that's printed on the cards actually is, but I suspect it's not ink in the traditional sense, like an ink jet printer with an ink reservoir. Is it some kind of reactive surface on the card that the printer is activating? At any rate, the WMMT unit when using a WMMT card can physically wipe the card face clean of all printed data. I suspect the ID3 unit is not capable of doing this. I had accidentally loaded one into the hopper backwards and it printed in the wrong spots. I reloaded the card, and it wiped it clean and printed to the correct spot.

Edit: BTW, the WMMT cards end up with blue text on them instead of black that I see on the ID3 and DOC cards, even when these cards are printed to in the WMMT unit. This further makes me think it's some kind of reactive surface on the card.
 
I'm still testing some things, but I discovered an additional layer of checksum in the card file. I believe it's Checksum-8 from the beginning of the data to byte 59, with the checksum being in byte 60. One time I was able to successfully edit driver name, but my tests since then haven't been working out, as the game gives an error indicating that the card should be inserted again.
After a little more analysis, I think it's Checksum-16.

Here's the full data that gets sent back in from the card reader:
Blue section is has checksum-16 calculated for it.
Red section is where checksum-16 is stored.
02 4B 33 31 30 30 51 76 00 00 7F 7E 82 90 FF 0A 09 17 00 00 A0 21 00 00 00 00 00 C4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 00 00 00 00 00 00 00 01 00 00 00 D6 05 00 00 02 03 51

I'm using the built in checksums in the HxD hex editor program, and it calculates Checksum-16 for the above blue section as 05D6, so you have to swap it around for the data stored in the card.

It seems to hold true for another card, too, where HxD caclulates Checksum-16 as 073C.
02 4B 33 31 30 30 51 76 00 00 7F 7E 82 FF FF 0A 07 18 7E 00 20 22 00 00 00 00 44 BC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8D 02 00 00 00 00 00 80 00 00 00 00 3C 07 00 00 04 03 4D

Let's see if I can edit data now. :)
 
Success! Yes, WMMT cards use Checksum-16. I can successfully edit names and I found a spot I can edit to change number of plays left until servicing. At one point I believe I also changed my car.

Good news is that I won't have to edit number of plays because I modified a card to have 0 plays left and my emulator successfully handles changing to a new card! I handled this emulator differently than the ID3 one, so I may go back and see if I can make the ID3 one run similarly.

The interesting thing is that the game can accommodate a number higher than 50 for number of plays left. The odd thing is that the place where I'm editing number of plays doesn't result in the same value across multiple cards. I changed it to FF one one card and it registered 66 plays left. I changed it to the same on another card and it registered 63 plays left.

Changing it to 00 made me change to a new card, so it was either 0 plays left or read in as some negative number and still thought I needed a new card.

Here's the spot in red:
02 4B 33 31 30 30 51 76 00 00 7F 7E 82 FF FF 0A 07 18 7E 00 20 22 00 00 00 00 44 BC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8D 02 00 00 00 00 00 80 00 00 00 00 3C 07 00 00 04 03 4D
 
I booted WMMT and got this message one time:
IMG_20160429_120957.jpg

Unfortunately the game requires card r/w cleaning at some interval. I'm going to record a log of the cleaning process, if I can make the actual unit think I've inserted a cleaner card. I doubt there's any data transfer with a cleaning card so maybe the game just believes you if you tell it one is inserted.

To clear this message, either the emulator needs to fake through the cleaning process in the test menu, or data needs to be cleared so the cleaning record resets, at which point other game settings are lost and need to be configured again. I did the latter. I'm not sure if this would ever pop up in the middle of a game.
 
Back
Top