@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:
Code:
000000000000000000000000
000000000000000000000000
011111111111111111111110
111111111111111111111111
111111111111111111111111
111111111111111111111111
100111001000000100111001
100110011000000100111001
100110011001111100010001
100000111001111110000011
100000111000000110000011
100000111000000111000111
100000111001111111000111
100110011001111111000111
100110011001111111000111
100111001000000111000111
100111001000000111000111
111111111111111111111111
111111111111111111111111
111111111111111111111111
011111111111111111111110
000000000000000000000000
000000000000000000000000
000000000000000000000000
Converting to blanks and black squares for easier viewing:
Code:
■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■ ■■■ ■ ■ ■■■ ■
■ ■■ ■■ ■ ■■■ ■
■ ■■ ■■ ■■■■■ ■ ■
■ ■■■ ■■■■■■ ■■
■ ■■■ ■■ ■■
■ ■■■ ■■■ ■■■
■ ■■■ ■■■■■■■ ■■■
■ ■■ ■■ ■■■■■■■ ■■■
■ ■■ ■■ ■■■■■■■ ■■■
■ ■■■ ■ ■■■ ■■■
■ ■■■ ■ ■■■ ■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■
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.