- Thread starter winteriscoming
- Start date
-
- Tags
- card reader id3 initial d3 naomi 2
winteriscoming
Champion
WMMT 1 and 2 card printing done via script based on how many line of print data come through. WMMT1 is 10 lines, while WMMT2 is 11.
I also got the size management after the HP/ figured out.
I need to get this integrated into my main script and the frontend, and start some more testing.
I'll probably keep messing with font edits throughout.
I also got the size management after the HP/ figured out.
I need to get this integrated into my main script and the frontend, and start some more testing.
I'll probably keep messing with font edits throughout.
Attachments
mathewbeall
Champion
I have to say - what you have there looks amazingly awesome... I don't think you have to mess with the fonts at all! 
I am ready to test when you want to send post the code!
Matt
I am ready to test when you want to send post the code!
Matt
ok i got this partially figured out now.
open circles mean you have been undefeted totally in story mode. the first time you lose 1 store mode the symbols go solid the pic is from namcos wmmt 2 official website translated in english.
untitled picture from namcos wmmt 3 official website indicates if you complete all 80 episodes without losing you get the bgm from wmmt 1 & 2. so knowing if you are open circle (undefeated) would matter vs.knowing if you lost at least once. (most people would have never known this)
based on what i read i have built another guess about the different symbols. my guess is each time you complete the entire story mode the symbol changes. wmmt2 and later games give rewards each time you complete the entire story mode and replay the entire story mode multiple times.
Attachments
Last edited:
here is how the symbols work in story mode. Full count is 20. at story 21, the symbol changes and all 20 the other are cleared and the bottom right corner gets a circle representing the first 20 completed stories.
For mt2 there are 80 stories. The 3 boxes on the right keep track of 20 stories. Circle at bottom first 20 stories completed. Diamond above the circle indicates 2nd 20 stories. Triangle above diamond indicates 3rd 20 stories completed. Star indicates story 61-80 and stays in the main 20 boxes. in the picture below a wmmt1 card was used on wmmt2 79 stories are completed.
So the 3dx+ card below is at story 50. Player is undefeted. Circle and diamond on the left bottom count 40. There are 10 triangles in the main boxes indicating story 41-50 have been completed.
total game stories:
wmmt 1 60
wmmt 2 80
wmmt 3 80
wmmt 3dx 100+ tuners races appear to not be recorded
wmmt 3dx+ 100+ tuners races appear to not be recorded
For mt2 there are 80 stories. The 3 boxes on the right keep track of 20 stories. Circle at bottom first 20 stories completed. Diamond above the circle indicates 2nd 20 stories. Triangle above diamond indicates 3rd 20 stories completed. Star indicates story 61-80 and stays in the main 20 boxes. in the picture below a wmmt1 card was used on wmmt2 79 stories are completed.
So the 3dx+ card below is at story 50. Player is undefeted. Circle and diamond on the left bottom count 40. There are 10 triangles in the main boxes indicating story 41-50 have been completed.
total game stories:
wmmt 1 60
wmmt 2 80
wmmt 3 80
wmmt 3dx 100+ tuners races appear to not be recorded
wmmt 3dx+ 100+ tuners races appear to not be recorded
Attachments
Last edited:
winteriscoming
Champion
I have the file structure figured out for storing printed data printed data pictures, and I have a method in place for assigning a background card. These are displaying successfully in the frontend.
I have integrated the picture creating method into the wmmt script, but the script is crashing at the print command and I ran out of time to look into it today.
I have integrated the picture creating method into the wmmt script, but the script is crashing at the print command and I ran out of time to look into it today.
mathewbeall
Champion
If you need help troubleshooting - more than happy to help.
winteriscoming
Champion
I wish I could quickly send it to you, but it takes forever for me to save down and then post an RPi image. Beyond that, I'm not sure what all specific files are different than your current version to be able to just send change files.
mathewbeall
Champion
No worries! Thanks!
winteriscoming
Champion
I forgot to mention that I've got the method down that I think will translate well to ID1-3 printing. I believe the 7D command is the erase print command. When that gets called in WMMT, I delete the print image file. Otherwise, as print commands come in, I will just append onto the existing printed image. I have tested, and appending onto an existing image works. ID1-3 will never see an erase command, so all changes will be appended.
From the logs I've got here in the thread, I passed one of the print commands from ID3 through my current print script, and it seems like it will mostly be the same. There will likely be some special handling of the printing from each game, though.
From the logs I've got here in the thread, I passed one of the print commands from ID3 through my current print script, and it seems like it will mostly be the same. There will likely be some special handling of the printing from each game, though.
winteriscoming
Champion
I figured out the issue. Print commands were being passed to the new method with a preceding space that broke things...
I am now successfully generating print files, and the frontend is showing an image for a chosen card if a background has been assigned and if a foreground print image is available.
A couple of things to work through:
-Background image is only assigned for a new card in the normal script workflow. I will probably need to come up with a startup script that assigns background images for existing cards where one does not exist. The idea is that a card gets assigned to your data randomly, just as if it were dispensed from the physical reader.
-(*EDIT: Figured this one out with directory alias in apache config)Management of scanned cards. I would like to have these managed on the boot partition for easier Windows access, but ultimately they need to end up somewhere that the apache server can access and post them on the frontend.
I am now successfully generating print files, and the frontend is showing an image for a chosen card if a background has been assigned and if a foreground print image is available.
A couple of things to work through:
-Background image is only assigned for a new card in the normal script workflow. I will probably need to come up with a startup script that assigns background images for existing cards where one does not exist. The idea is that a card gets assigned to your data randomly, just as if it were dispensed from the physical reader.
-(*EDIT: Figured this one out with directory alias in apache config)Management of scanned cards. I would like to have these managed on the boot partition for easier Windows access, but ultimately they need to end up somewhere that the apache server can access and post them on the frontend.
Last edited:
mathewbeall
Champion
I would say leave it random - just like the card reader is on the original game
winteriscoming
Champion
@saturnnights had discovered this already, but as I'm looking closer into replicating printed data, I'm understanding better what is happening. As usually on this forum, the help of others is invaluable, and I very much appreciate the public sharing of discoveries and knowledge.
So, with that in mind, much of this is a rehash of previously posted information, but now its coming from the perspective of using this information for the purposes of generating print images.
On some games, during boot there are a number of commands that get sent to the card reader to establish custom fonts that are used in the printed data for a game.
Initial D3 is an example. It uses these for the icons that are essentially black boxes with white text in them to represent areas cleared and it is also used for the printed icon that says "KEY" which also happens to be a black box with white text.
In my early attempts at passing ID3 data through my current image generator, it had some odd results that I now realize would be custom characters that are not present in the font file I'm using.
The challenge then is going to be:
-Interpret and store custom font data.
-Make use of custom font data.
There are only so many custom characters in a given game, so it would not be unreasonable to set up a font file per game and just use that in the interpreter. I know this would work. I've made some custom characters in my testing already. I think this might be the easiest way forward.
Interpreting the character data is the least of this task. They come in the 7A commands, and they are in the form of 72 byte packets that make up a 24x24 dot image in binary. 0s are blank and 1s are black dots.
If I focus on the KEY character, I found it in one of my ID3 boot initialization logs and the data packet is:
000000000000007FFFFEFFFFFFFFFFFFFFFFFF9C8139998139999F11839F838381838381C7839FC7999FC7999FC79C81C79C81C7FFFFFFFFFFFFFFFFFF7FFFFE0000000000000000
Converted to binary and arranged into 24 rows and columns:
Converting to blanks and black squares for easier viewing:
So interpreting them isn't going to be too bad.
The next steps would be figuring out which character code these get assigned to and edit a font file to contain them at the correct addresses so they'll be used accordingly.
As far as I can tell just based on print data I'm seeing and the results I get from my interpreter, WMMT1/2 don't use these custom characters. ID3 definitely does, and based on a print I see from Mario Kart, it very likely uses them, too.
So, with that in mind, much of this is a rehash of previously posted information, but now its coming from the perspective of using this information for the purposes of generating print images.
On some games, during boot there are a number of commands that get sent to the card reader to establish custom fonts that are used in the printed data for a game.
Initial D3 is an example. It uses these for the icons that are essentially black boxes with white text in them to represent areas cleared and it is also used for the printed icon that says "KEY" which also happens to be a black box with white text.
In my early attempts at passing ID3 data through my current image generator, it had some odd results that I now realize would be custom characters that are not present in the font file I'm using.
The challenge then is going to be:
-Interpret and store custom font data.
-Make use of custom font data.
There are only so many custom characters in a given game, so it would not be unreasonable to set up a font file per game and just use that in the interpreter. I know this would work. I've made some custom characters in my testing already. I think this might be the easiest way forward.
Interpreting the character data is the least of this task. They come in the 7A commands, and they are in the form of 72 byte packets that make up a 24x24 dot image in binary. 0s are blank and 1s are black dots.
If I focus on the KEY character, I found it in one of my ID3 boot initialization logs and the data packet is:
000000000000007FFFFEFFFFFFFFFFFFFFFFFF9C8139998139999F11839F838381838381C7839FC7999FC7999FC79C81C79C81C7FFFFFFFFFFFFFFFFFF7FFFFE0000000000000000
Converted to binary and arranged into 24 rows and columns:
Code:
000000000000000000000000
000000000000000000000000
011111111111111111111110
111111111111111111111111
111111111111111111111111
111111111111111111111111
100111001000000100111001
100110011000000100111001
100110011001111100010001
100000111001111110000011
100000111000000110000011
100000111000000111000111
100000111001111111000111
100110011001111111000111
100110011001111111000111
100111001000000111000111
100111001000000111000111
111111111111111111111111
111111111111111111111111
111111111111111111111111
011111111111111111111110
000000000000000000000000
000000000000000000000000
000000000000000000000000Converting to blanks and black squares for easier viewing:
Code:
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■ ■■■ ■ ■ ■■■ ■
■ ■■ ■■ ■ ■■■ ■
■ ■■ ■■ ■■■■■ ■ ■
■ ■■■ ■■■■■■ ■■
■ ■■■ ■■ ■■
■ ■■■ ■■■ ■■■
■ ■■■ ■■■■■■■ ■■■
■ ■■ ■■ ■■■■■■■ ■■■
■ ■■ ■■ ■■■■■■■ ■■■
■ ■■■ ■ ■■■ ■■■
■ ■■■ ■ ■■■ ■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■The next steps would be figuring out which character code these get assigned to and edit a font file to contain them at the correct addresses so they'll be used accordingly.
As far as I can tell just based on print data I'm seeing and the results I get from my interpreter, WMMT1/2 don't use these custom characters. ID3 definitely does, and based on a print I see from Mario Kart, it very likely uses them, too.
mathewbeall
Champion
MKGP for the most part has regular text that I can see..... Name, Number of coins, Rank, Item count.... but under the Grand Prix Champion Cups part it seems as if it's a bitmap - not a font..... And then the password is just regular text.
winteriscoming
Champion
Another great piece of info in the printer doc is with regards to data interpretation during the print command. There are some control characters that affect the printed data, and being able to interpret them will be helpful, especially when dealing with the custom font data.
Per the translated document:
The following things can be specified as the control code of the print data.
& Hd :new line
& H11 : Double height specified
& H14 : Character size canceled
& H1b + & H73 + yy + xx: character size setting
-yy & H31 (vertical 1 times) ~ & H34 (vertical 4-fold)
-xx & H31 (1 times horizontal) ~ & H34 (Horizontal 4-fold)
& H1b + & H67 + external character No. : External character No. In registered external character font
I had already been interpreting x0d as new line, but the others are very helpful in determining what the commands mean. I now see how sizing changes are controlled. I also see how the established custom characters are addressed.
Here is one line line 1 of data from an ID3 print packet:
Line 1: 20 20 20 20 20 20 20 20 1B 73 32 31 82 60 82 61 82 62 20 20 20 20 14 20 20 20 1B 67 01 37 32 31
That ends up being 8 standard size spaces, then 1B 73 32 31 sets the font to vertical 2x and horizontal 1x. Then it's shift-jis letters JIM, 4 spaces as the same font size. Cancel font changes (i.e. revert back to normal), 3 spaces, call custom character with 1B 67 at spot 01 (KEY character since it was the first character registered, I believe), and then normal characters 721.
I know WMMT1/2 are using some of these sizing codes, so now I can figure out what to do easier.
Per the translated document:
The following things can be specified as the control code of the print data.
& Hd :new line
& H11 : Double height specified
& H14 : Character size canceled
& H1b + & H73 + yy + xx: character size setting
-yy & H31 (vertical 1 times) ~ & H34 (vertical 4-fold)
-xx & H31 (1 times horizontal) ~ & H34 (Horizontal 4-fold)
& H1b + & H67 + external character No. : External character No. In registered external character font
I had already been interpreting x0d as new line, but the others are very helpful in determining what the commands mean. I now see how sizing changes are controlled. I also see how the established custom characters are addressed.
Here is one line line 1 of data from an ID3 print packet:
Line 1: 20 20 20 20 20 20 20 20 1B 73 32 31 82 60 82 61 82 62 20 20 20 20 14 20 20 20 1B 67 01 37 32 31
That ends up being 8 standard size spaces, then 1B 73 32 31 sets the font to vertical 2x and horizontal 1x. Then it's shift-jis letters JIM, 4 spaces as the same font size. Cancel font changes (i.e. revert back to normal), 3 spaces, call custom character with 1B 67 at spot 01 (KEY character since it was the first character registered, I believe), and then normal characters 721.
I know WMMT1/2 are using some of these sizing codes, so now I can figure out what to do easier.
winteriscoming
Champion
The "COINS" section at the top would be custom characters. The "100cc Class" and brackets around it may be individual custom characters, too. I could see how that would work. Otherwise there is apparently an option to print an image with the 7B command.MKGP for the most part has regular text that I can see..... Name, Number of coins, Rank, Item count.... but under the Grand Prix Champion Cups part it seems as if it's a bitmap - not a font..... And then the password is just regular text.
I'll have to get some logs from it to see, but the image printing doesn't seem too terrible, and I would like to think there's a way to make the image generator use that information.
Edit: I'm guessing based on the script I have for Mario Kart that it's not using the 7B command. It doesn't look like there were any accommodations made for that command in the replies being given.
Last edited:
winteriscoming
Champion
There are a few things left to implement, but I've got the print image generator handling the special cases from the printed data.
Here is the output for an ID3 print command:
Here's the output from a WMMT2 print command:
Both were passed through the same script with no manual overrides or special accommodations for a given issue.
An asterisk is currently printed in place of a custom character (as seen in the ID3 sample), but otherwise, all sizing and spacing is taken from print commands.
WMMT data fits perfectly on the card:
Here is the output for an ID3 print command:
Here's the output from a WMMT2 print command:
Both were passed through the same script with no manual overrides or special accommodations for a given issue.
An asterisk is currently printed in place of a custom character (as seen in the ID3 sample), but otherwise, all sizing and spacing is taken from print commands.
WMMT data fits perfectly on the card:
winteriscoming
Champion
I have a method in place for building out and using the custom characters/icons. I can take in the bytes found in logs and process them into the icons that can the be sized and printed as needed to match up with fontsizes in the printed image. I can even make them match the color of the printed fonts (i.e. blue for those that can erase like WMMT and Mario Kart, and black for those that can't like ID3).
These are the icons registered by ID3 at boot:
For some reason it registers the same star in 2 slots.
These are actually going to end up being pretty easy to deal with. On a per game basis, I just need to get a boot log and throw the data from the 7A commands into an array. The address in the array will be able to line up with the code called in the print commands to display a given icon.
So I can just put together an array for each game, and know when I'm printing data for a given game, I can pull the icon from the correct place and render it. The script will render the icons from the bytes on-the-fly when printing. They're very small, so the processing time is very quick.
I am currently processing prints asynchronously to the main script, but I don't necessarily have to. The script could end up being made to give "busy" replies during printing if it becomes necessary (i.e. in case the game starts sending out multiple prints sequentially). I probably should go ahead and implement it that way to be more in line with the behavior of the actual hardware.
These are the icons registered by ID3 at boot:
For some reason it registers the same star in 2 slots.
These are actually going to end up being pretty easy to deal with. On a per game basis, I just need to get a boot log and throw the data from the 7A commands into an array. The address in the array will be able to line up with the code called in the print commands to display a given icon.
So I can just put together an array for each game, and know when I'm printing data for a given game, I can pull the icon from the correct place and render it. The script will render the icons from the bytes on-the-fly when printing. They're very small, so the processing time is very quick.
I am currently processing prints asynchronously to the main script, but I don't necessarily have to. The script could end up being made to give "busy" replies during printing if it becomes necessary (i.e. in case the game starts sending out multiple prints sequentially). I probably should go ahead and implement it that way to be more in line with the behavior of the actual hardware.
winteriscoming
Champion
I did an overhaul on the printing script to accommodate icons, accept print line parameter (games that issue multiple print commands can start on lines other than the first), and give better behavior with font size changes in the same line. I suspect I haven't captured all possible font changes, but it appears that only 2 sizes get printed - regular and large at 2x. I'll have to see as I venture into other games if that holds true.
I haven't gotten a chance to look into more ID3 print commands to see if I'm handling it well.
One thing I haven't incorporated yet is the possibility for rotated prints. Rotation comes in as a parameter. As an example: WMMT cards are printed landscape mode, while ID3 cards are portrait. It may not end up mattering since I'll need to know what the game is in order to generate an image that overlays a card scan, and can just handle the game-specific orientation that way.
I probably need to tweak it a bit for WMMT since alignment isn't quite where I had it before, but here are the results of the in-game test print:
By the way: The stars, diamonds and circles are all regular characters available in the shift-jis fonts (translated to unicode), so nothing fancy with regards to custom icons are being used there.
The large font is wider than I'd like it to be. I may work on that. I am unsure if the large font width comes into play with regards critical alignment of smaller font on the same line. The alignment doesn't matter much on ID3. Mario Kart has a box for coins after the name, but I don't know if it prints the coin info as an independent print command or as part of the same line as the large font. If it's part of the same line, then I'll definitely have to the large font at a better width. If needed, I can edit letter directly in the font file, but it's possible I can use the script to manipulate them via scaling.
We'll see. This is going to be an evolving project as I layer in support for additional games.
I haven't gotten a chance to look into more ID3 print commands to see if I'm handling it well.
One thing I haven't incorporated yet is the possibility for rotated prints. Rotation comes in as a parameter. As an example: WMMT cards are printed landscape mode, while ID3 cards are portrait. It may not end up mattering since I'll need to know what the game is in order to generate an image that overlays a card scan, and can just handle the game-specific orientation that way.
I probably need to tweak it a bit for WMMT since alignment isn't quite where I had it before, but here are the results of the in-game test print:
By the way: The stars, diamonds and circles are all regular characters available in the shift-jis fonts (translated to unicode), so nothing fancy with regards to custom icons are being used there.
The large font is wider than I'd like it to be. I may work on that. I am unsure if the large font width comes into play with regards critical alignment of smaller font on the same line. The alignment doesn't matter much on ID3. Mario Kart has a box for coins after the name, but I don't know if it prints the coin info as an independent print command or as part of the same line as the large font. If it's part of the same line, then I'll definitely have to the large font at a better width. If needed, I can edit letter directly in the font file, but it's possible I can use the script to manipulate them via scaling.
We'll see. This is going to be an evolving project as I layer in support for additional games.
