FONTCHARACTER Reference - compatibility, sets

[SimonLothar]

Well, it looks like MB_strcpy doesn't use the result of MB_ByteCount. So anyway, yeah, that looks null-terminated.

MB_ByteCount is called inside of MB_strcpy again.

Well actually, the syscall I have here (OS 2.05, fx-9860GII-2) uses a cmp/gt, so it is < 0xLLFF (where 0xLL is the leading character).

With
mov #-1, r1
extu.w r4, r6
extu.b r1, r1
cmp/gt r1, r6

it is r6 > 0xLLFF (not < 0xLLFF).

[cakeisalie5 Profile Website]

MB_ByteCount is called inside of MB_strcpy again.

Well, that's at least sort of null-terminated, as expected

MB_ByteCount: Show

Code: Select all

/**
 *   MB_ByteCount:
 *   Count the number of bytes a multi-byte string.
 *
 *   @arg   str      the string.
 *   @return         the length of the string.
 */

int MB_ByteCount(char *str)
{
   if (!str)
      return (0);
   for (int len = 0; *str; len++, str++) {
      if (*str == 0x7F || *str == 0xE5 || *str == 0xE6
       || *str == 0xE7 || *str == 0xF7 || *str == 0xF9)
         str++, len++;
   }
   return (len);
}

it is r6 > 0xLLFF (not < 0xLLFF).

Actually, it's 0xLLFF > r6 (the disassembler just puts it in another order than the official one)

[SimonLothar]

the disassembler just puts it in another order than the official one

Funny thing, that. A disassembler which freely swaps the order of operands.

[lephe Profile]

Swapping operands, are you sure? Here's what the Renesas SH-3 software manual says:

Code: Select all

CMP/GT Rm,Rn    0011nnnnmmmm0111
When signed and Rn > Rm, 1 → T

I've double-checked the language file from my disassembler and it states:

Code: Select all

0011nnnnmmmm0111    cmp/gt rm, rn

Then (to be sure) I tried disassembling a simplistic assembly file; here's what I got:

Code: Select all

rook» tmp $ cat a.s
cmp/gt r2, r3
rook» tmp $ sh3eb-elf-objdump -D a.bin -b binary -m sh3
(...)
   0:   33 27          cmp/gt   r2,r3
rook» tmp $ fxos disasm a.bin -o 0 -l 2
     0:  3327   cmp/gt   r2, r3

As you can see gcc and the doc use the same operand order as me. Did I miss anything?

Edit: After a short talk with Cakeisalie5 about this matter, I realized that the problem came from the bt instruction just after the test. This branch leads to the following if/else case so the test is negated. The disassembler was right regarding the operand order, and Cake's C code should state <= 0xLLff instead of <.

[cakeisalie5 Profile Website]

My fault. >_> (at least now I know)
So yeah, it's <= 0xLLFF.

[cakeisalie5 Profile Website]

Finally made something more or less complete! I just need to perfect the names and Unicode equivalents, and to correct the IDs so I can use it in a C library, but otherwise, the FONTCHARACTER reference should allow to make more or less the same opcode resolution table as in the OS!

Also, compatibility from 1.00 to 2.05 is managed, using sets (OS_1.00, OS_1.05, OS_2.00, OS_2.04).
The source is here:

https://github.com/cakeisalie5/fontcharacter_reference

[DasHeiligeDönerhuhn Profile]

Dunno if it helps, but on page 138 and onward of this PDF document there is a specification of Classpad2 characters. https://asset.re-in.de/add/160267/c1/-/ ... -H-x-T.pdf