Transport medium and protocols

All communication protocols used by CASIO calculators are present over mediums and transport protocols, that presents a stream-like interface as well as other transport-specific operations that may be necessary.

Serial transport

The serial transport is the only transport present from the oldest calculators supported by Cahute, to the newest ones. It is used for calculator-to-calculator communication, as well as, for older models, host-to-calculator communication.

It presents a byte-oriented stream, with settings that must be set on both sides for the communication to be established. Said settings include:

  • The baud speed;

  • The number of stop bits to use (1 or 2);

  • The parity (even, odd, none/ignored);

  • Additional hardware and software flow control settings, such as DTR/RTS or XON/XOFF.

These settings are defined differently depending on the communication protocol: while some are to be defined manually on both end, like CAS40 protocol – Serial protocol used by pre-1996 calculators, some use rendez-vous settings, like Protocol 7.00 – Serial and USB protocol used by post fx-9860G calculators, and may allow these settings to be renegotiated during the communication.

Note

Some calculators advertised as USB-compatible, such as the Graph 100+, did not actually have a USB port. However, the box in which the calculator was sold also included an SB-88 USB-serial cable, which allowed PCs to communicate with the calculator’s serial port through one of its USB ports. Therefore, the logics used in this case are actually those of the serial transport.

The following communication protocols can be found over serial transport:

Serial transport over USB bulk

The unveiling of the Classpad 300 and fx-9860G, in 2003 and 2005 respectively, introduced Mini-B USB ports on the calculator directly for host-to-calculator communication, using any compatible cable.

Note

In practice, not all cables seem to work with these calculators, as manifested in the comments of Améliore ta Graph 35+ USB/E en Graph 75(+E) ! or Fa 124 pour Graph USB.

Some cables also seem to work, but not support some operations required for some speed hacks to work such as Protocol 7.00 packet shifting, as manifested in #31 for example.

Once the link is established, and the Device enabling control flow is executed, data is transferred using Data transfer.

The following communication protocols can be found over serial transport over USB bulks:

Device enabling control flow

Some older fx-9860G derivatives, such as the fx-9860G Slim running OS 1.x, require a special USB control flow to be executed before they can send or receive any data. This can manifest differently depending on the application protocol:

This control flow has the following properties:

  • bmRequestType set to 0x41, to designate a vendor-specific interface request with no incoming data transfer;

  • bRequest set to 0x01, as it is the command that enables Protocol 7.00 data transfers.

  • Both wValue and wIndex set to 0x0000.

  • No data transfer.

Using libusb, this can be done using the following excerpt:

libusb_control_transfer(
    device_handle,
    0x41,  /* bmRequestType */
    0x01,  /* bRequest */
    0x0000,  /* wValue */
    0x0000,  /* wIndex */
    NULL,
    0,
    300
);

Ideally, this flow is run by a driver that can be used as soon as the calculator is connected to the host. Otherwise, it means that the calculator may freeze until a transfer utility is used, such as one of Cahute’s command-line utilities.

Data transfer

In order to transfer data from the host to the device, or from the device to the host, USB bulk transfers are used.

Warning

While USB bulk endpoints are frequently hardcoded as 0x82 for Bulk IN and 0x01 for Bulk OUT in community-made communication tools for CASIO calculators, these have been proven to change on certain platforms, including MacOS / OS X; see #3 for more information.

It is therefore recommended to detect the Bulk IN and OUT endpoints automatically before opening the device. When using libusb to detect calculators, Cahute does this with a more advanced version of the following code:

struct libusb_config_descriptor *config_descriptor;
struct libusb_interface_descriptor const *interface_descriptor;
struct libusb_endpoint_descriptor const *endpoint_descriptor;
int j, bulk_in = -1, bulk_out = -1;

libusb_get_active_config_descriptor(calc_device, &config_descriptor);
interface_descriptor = config_descriptor->interface[0].altsetting;

for (j = 0; j < interface_descriptor->bNumEndpoints; j++) {
    endpoint_descriptor = interface_descriptor->endpoint[j];
    if ((endpoint_descriptor->bmAttributes & 3) != LIBUSB_TRANSFER_TYPE_BULK)
        continue;

    switch (endpoint_descriptor->bEndpointAddress & 128) {
    case LIBUSB_ENDPOINT_OUT:
        bulk_out = endpoint_descriptor->bEndpointAddress;
        break;

    case LIBUSB_ENDPOINT_IN:
        bulk_in = endpoint_descriptor->bEndpointAddress;
        break;
    }
}

USB Mass Storage (UMS) transport

Starting from the fx-CG20 (Prizm) and fx-CP400+E, which came out in 2011 and 2016 respectively, calculators started supporting a “USB Key” mode, that present both their main and storage memory over USB Mass Storage (UMS) with Bulk-Only Transport. This had the advantage of not requiring any specific driver or software to interact with such filesystems.

However, with the introduction of this mode, calculators now used UMS for all use cases, including screenstreaming which still uses Protocol 7.00 Screenstreaming – fx-9860G and fx-CG screenstreaming

The following communication protocols can be found over UMS:

Custom SCSI commands

CASIO makes use of the C0h to FFh SCSI vendor-specific range to implement its own SCSI commands.

0xC0

This command is a 16-byte command that is run to poll the device’s status. The command format is the following:

Offset

Size

Description

Value

0 (0x00)

1 B

Command code.

0xC0

1 (0x01)

15 B

Reserved.

Must be set to 0x00.

The command prompts the device to answer with a 16-byte device status, with the following format:

Offset

Size

Description

Value

0 (0x00)

1 B

Unknown.

Set to 0xD0.

1 (0x01)

5 B

Reserved.

Set to 0x00.

6 (0x06)

2 B

Amount of available bytes to be requested.

Big endian 16-bit integer.

8 (0x08)

2 B

Reserved.

Set to 0x00.

10 (0x0A)

2 B

Activity status.

Big endian 16-bit integer.

12 (0x0C)

4 B

Reserved.

Set to 0x00.
0xC1

This command is a 16-byte long command that is run to read available data. The command format is the following:

Offset

Size

Description

Value

0 (0x00)

1 B

Command code.

0xC1

1 (0x01)

5 B

Reserved.

Set to 0x00.

6 (0x06)

2 B

Requested bytes count.

Big endian 16-bit integer.

8 (0x08)

8 B

Reserved.

Set to 0x00.

The command prompts the device to answer with the requested data.

0xC2

This command is a 16-byte long command that is run to write data to the calculator. The command format is the following:

Offset

Size

Description

Value

0 (0x00)

1 B

Command code.

0xC2

1 (0x01)

5 B

Reserved.

Set to 0x00.

6 (0x06)

2 B

Bytes count.

Big endian 16-bit integer.

8 (0x08)

8 B

Reserved.

Set to 0x00.

The command should be accompanied with the data to send.

Windows USB drivers

Any user program using the Windows API (Win32) requires a kernel driver to communicate with the calculator for both Serial transport over USB bulk and USB Mass Storage (UMS) transport. This kernel driver can be one of:

CESG502

CESG502 is distributed with FA-124, and is necessary for CASIO’s software to successfully detect and communicate calculators connected using USB. This means it is necessary to support it for any user program that co-exists with it to work with CASIO’s driver.

CESG502 abstracts both Serial transport over USB bulk and USB Mass Storage (UMS) transport behind a stream-oriented device. It can be detected using libusb, but cannot be opened using the same tool; one must use detection with SetupAPI or cfgmgr32, check that the device driver is CESG502, and if it’s the case, open and use the device using fileapi (CreateFile, ReadFile, WriteFile, CloseFile).

Note

It is possible to access device instance properties on Windows OSes before Vista, e.g. Windows XP; see Accessing Device Instance Properties (Prior to Windows Vista) for more information.

It uses {36fc9e60-c465-11cf-8056-444553540000}, the same GUID as generic USB devices, which is normally forbidden for Independent Hardware Vendors (IHV) such as CASIO, so this key cannot be used to uniquely identify the driver.

Cahute currently matches the service (CM_DRP_SERVICE) to PVUSB, since this is the value encountered in the wild.