FONTCHARACTER Reference - compatibility, sets

[cakeisalie5 Profile Website]

Hi, as you may or may not know, I'm making a FONTCHARACTER reference in order to be able to read, write, describe and convert to Unicode FONTCHARACTERs (I call FONTCHARACTERS the code <-> character correspondance, not the fixed-width or multibyte format). It's long, but at least, when it's done, it won't have to be done by anyone else (they will just be able to include this and use it in their projects).

I would like to include a sets system in this FONTCHARACTER reference. A set is a pack of characters/opcodes (I count opcodes as characters, because they are in the same encoding, just not used in the same way) that has parents (and include their characters). An example set is the "OS2" set, which includes the characters from the "OS1" set (see below) and would bring new ones. I'm also willing to include "extension" sets (characters that alternative interpreters bring, like C.Basic).

The problem is, I don't really know the history of this encoding, so I don't really know what sets to use. What is, globally, the history of characters in CASIO calculators ? Is there a way to export the characters/opcodes from a raw OS image in order to guess where some characters appeared?

Thanks in advance!
(and sorry for the "flood" with so many different subjects, I'm just trying to tidy up all the things I can grab )

[SimonLothar]

You can find the standard 8x8 character glyphs by the following method.

8x8 character glyphs: Show

Code: Select all

   for ( i=0;i<=6;i=i+1){
      // Get 8x8 glyp00-pointer
      // query syscalls 1b7..1bd (Multibyte high byte:00,E7,F9,E6,E5,7F,F7)
      // pointer to the call code
      base = Dword( Dword( 0x8001007c ) + 4*(0x1b7+i) );
      //
      ea = BADADDR;
      j1 = 0;
      while( Word( base ) != 0x000B ){   // loop until RTS opcode
         if ( ea == BADADDR ) if ( ( Word( base ) & 0xF000 ) == 0xD000 ) ea = base; // check for first mov.l-opcode
         if ( ( Word( base ) & 0xF0FF ) == 0x4008 ) j1 = 1;   // check for shll2-opcode
         base = base + 2;
      }
      // get the offset
      j = Byte( ea+1 );
      j = 4*j;
      j = ( ea + j + 4 ) & 0xFFFFFFFC;
      ea2 = Dword( j ); // pointer to the first glyph
      
      Message( "%.8x %.8x %.8x\n", ea, ea2, j1 );
      // if j1 == 0: there is only one empty (space) glyph
      // if j1 == 1: there are 256 consecutive glyphs
      // every glyph is a 8X8 pixel bitmap (== 8 consecutive bytes)
   }


The code is written in a C-like language. It should do to explain the way, how to analyze an OS image to gain the glyph table pointers and the corresponding character definitions.


This is an example of some 8x8 glyph definitions

example: Show

[cakeisalie5 Profile Website]

Yay, I'll try using that! What about the multi-character opcodes (that are defined using one or more other characters), have you found out how it's stored?

[SimonLothar]

Yay, I'll try using that! What about the multi-character opcodes (that are defined using one or more other characters), have you found out how it's stored?

I do not understand what you mean. Could you give an example, please.

[cakeisalie5 Profile Website]

For example:
- 0xF710 is resolved as "Locate ";
- 0xC8 is resolved as "a" (but 'a' is 0x61, and 0xC8 is described in the catalog as "a (Reg)").

[SimonLothar]

Yes. Opcodes and MB-characters follow different concepts.

Syscall 0x07FC can be used to fetch the display-string of an opcode.
The display-string consists of MB-characters.

F. i. 0xC8 is the opcode for the regression coefficient a and it is displayed using the character a (0x61) resp.the string "a".
0x81 is the opcode for sin and it is displayed using the string "sin".

---
0x07FC: int OpcodeToStr( unsigned short opcode, unsigned char *string );
Returns a displaystring in string according to opcode.
The string is copied. The size of the target buffer string must be 32 bytes.

[cakeisalie5 Profile Website]

Yes. Opcodes and MB-characters follow different concepts.

But they are located on the same table, right? Like, the FONTCHARACTER reference I put together puts the two in the same table, and there were no incompatibility.

Syscall 0x07FC can be used to fetch the display-string of an opcode.
The display-string consists of MB-characters.

The problem is, I would like to be able to reproduce this (and related) syscalls on the PC. One of the primary goals would be to see which characters are implemented in an OS image, in order to check if each opcode is supported by the system or not. That's why I asked if we could extract this opcode <-> multi-byte string correspondance from the system :p

[SimonLothar]

But they are located on the same table, right?

The charater definitions, t. i. the glyph-tables are located in different tables compared to the opcode/string tables. I checked images between OS 1.02 and OS 2.09. The glyph tables have been extended at least since OS 2.00.

The problem is, I would like to be able to reproduce this (and related) syscalls on the PC. One of the primary goals would be to see which characters are implemented in an OS image, in order to check if each opcode is supported by the system or not. That's why I asked if we could extract this opcode <-> multi-byte string correspondance from the system

That is more complicated. I am not sure, if it is possible to develop an algorithm to gain the opcode-to-string tables. In the worst case you have to use an OS-dependent absolute address-table. I'll have a look.

[SimonLothar]

There seems to exist a systematic method to retrieve the opcode-table-pointers from a fx-9860 OS image (at least for OSes 1.02 to 2.09).
Again this is a method written in a C-like language.

Method: Show

Code: Select all

// detect OpCode-tables
// start with syscall 7fc
// find the first "mov.l @(h'84,pc), rn", which loads an address in the OS range
// that is the pointer to the opcode 00 pointer table;
// the pointers to the opcode tables F9, 7F, F7, E5, E6 and E7 (E7 not available with any OS) follow - exactly in this order - separated by 0x800.
// if the content of the E7-table is not an address in the OS-range, the E7-opcodes do not exist (OS 1.xx).
// each the table entry consists of the pointer to the OpCode-string, f. i. "sin" and a Dword, which represents some information concerning the type of the opcode.

   base = Dword( Dword( 0x8001007c ) + 4*0x7fc );
 
   ea = BADADDR;
   j1 = 1;
   while( Word( base ) != 0x000B ){   // loop max until RTS opcode
      if ( ea == BADADDR ) if ( ( Word( base ) & 0xF000 ) == 0xD000 ) ea = base; // check for mov.l-opcode
      if ( ea != BADADDR ){
// get the offset
         j = Byte( ea+1 );
         j = 4*j;
         j = ( ea + j + 4 ) & 0xFFFFFFFC;
         ea2 = Dword( j ); //
// does it point into the OS range?
         if ( ( ea2 < 0x80010000 ) | ( ea2 > 0x80400000 ) ) ea = BADADDR;
         if ( ea != BADADDR ) break;
      }
      base = base + 2;
   }
   
   ea00 = ea2;
   if ( ea00 != BADADDR ){
      for ( j=0; j < 7; j = j + 1 ){
         for ( i=0;i<256;i=i+1){
            ea2 = ea00 + j*0x800 + i*8;
            
            if ( ( Dword( ea2 ) > 0x80010000 ) & ( Dword( ea2 ) < 0x80400000 ) ){
               MakeNameEx2( ea2, form( "OpCodes_%s_%.2x", substr( "00F97FF7E5E6E7", j*2, j*2+2 ) i ) );
               MakeDword( ea2 );
               MakeUnknown( Dword( ea2 ), 4, 0 );
               MakeByte( Dword( ea2 ) );
               MakeNameEx2( Dword( ea2 ), form( "OpCode_%s_%.2x", substr( "00F97FF7E5E6E7", j*2, j*2+2 ) i ) );
               MakeStr( Dword( ea2 ), BADADDR );
               MakeDword( ea2+4 );
            }
            
         }
      }
   }


Keep in mind, that the strings the table points to, are Multibyte-Strings.

Example: Show

[cakeisalie5 Profile Website]

So I've adapted it to understand and read using a file's content on my PC:
[[See next post]]

And if I understand well, the second dword is the flags of the entry. What I don't understand is that in your example, the size of the element is the high nibble of the first byte of the flags, where here, it looks like it is the lowest nibble. Also, the characters looks deformed: for 0x0E, it should be 0xE591 but it is 0xE691, 0x14 should be [0x66,0x31] but it is [0x66,0xD1]...