In the Protocol 7.00, there are few packet formats (actually, one general packet format, and one for screenstreaming), but all packets start with a packet type, which is made of one byte:

Value Type Format
0x01 Command General
0x02 Data General
0x03 Swap General
0x05 Check General
0x06 Ack General
0x0B Screen Specific
0x15 Nak General
0x18 Terminate General

General packet format

Once the packet type is passed and the packet format is found to be the general one, all bytes in the packet should be ASCII-HEX encoded, i.e. in the [‘0’ — ‘9’, ‘A’ — ‘F’] ([0x30 — 0x39, 0x41 — 0x46]) range. This could be made to ensure that no RS-232-like control codes are emitted out of the packet types, or even to be able to “easily” print the packets without hexdumping — who knows?

The first two bytes is the subtype, encoded on two characters, e.g. “4F”. The meaning of this subtype depends on the packet type — some packet types don’t even need it, so the subtype usually ends up being “00”, but it is always there.

Then we have the extended information zone. It starts with one byte telling if yes (equals to ‘1’) or no (equals to ‘0’) this zone is extended. If it is, then this byte is followed by a 4-digits size of the encoded data zone (e.g. “004F” for 79), followed by the encoded data itself.

The data itself is encoded using a simple algorithm (and the decoding process should be easy to deduce):

  • if it is a byte under 0x20, 0x20 is added to the byte, and it is preceded by a backslash (0x5C);
  • if it is a backslash (0x5C), it is just preceded by a backslash;
  • otherwise, the byte is copied as is.

Once the data part (which could only weight one byte if the boolean was ‘0’) is read, there is a two-characters checksum, or, as you could call it, “checksub”. Every byte in the encoded packet, excepted the packet type and the current checksum, is removed from a counter (which starts at zero). You can also calculate it by doing a normal checksum on bytes, then calculating the two’s complement of the found result (Simon Lothar does that).

An example packet can be [0x06, 0x30, 0x30, 0x30, 0x37, 0x30], which is a simple ACK packet with a 1-byte data part.

Screen packet format

Although at the time where the fx-9860G came out there was only one screen packet format, more have been added since, and I’ll give a general method of decoding screen packets, which don’t have the same « all ASCII-HEX » logic from earlier.

Once the 0x0B packet type has been read, a five-character screen packet type is sent. The original screen packet type has the TYP01 type, and this is a raw 1024-byte dump representing the monochrome screen from the fx-9860G.

The TYPZ1 screen packet type has been added afterwards. It is followed by a “TYPZ” header, where all numbers are ASCII-HEX encoded:

  • 8-character screen size in bytes (e.g. “028800”);
  • 4-character width in pixels (e.g. 384);
  • 4-character height in pixels (e.g. 192);
  • 1 character that’s always ‘1’;
  • 3 characters representing the format.

Known formats are:

  • RC2: 16-bit mode;
  • RC3: 3-bit mode;
  • RM2: 2-bit mode (?).