From WikiPrizm
Revision as of 13:35, 1 August 2014 by Gbl08ma (talk | contribs) (Created page with "{{Incomplete}} CASIOABS is the name of the bootloader used on the Prizm and other Casio calculators. On the Prizm at least, it is located on the first sector of flash (a...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

This page has not been completed. Parts may be missing or reorganized before completed. Information is provided as-is and may have errors.

CASIOABS is the name of the bootloader used on the Prizm and other Casio calculators.

On the Prizm at least, it is located on the first sector of flash (at 0x80000000 or 0xA0000000; the OS only starts on the second sector) and is the first code executed by the CPU when it is powered up. This is the only bootloader, and if the first flash sector is erased, the device is bricked - see Behavior on Damage for more information. Getting the first flash sector erased is not exactly hard, as it has no write protection - it is no different from other flash sectors.

Included menus and modes

[to be added]

Behavior on Damage

Information in this section has been verified with actual experience of having the first flash sector erased accidentally.

If the bootloader is damaged, for example, by erasing the first flash sector, and no other damage is done, the calculator will keep operating until the OS attempts to reboot or batteries are taken off (or become empty). During the period the Prizm and its OS still work, there are no changes to normal operation except the following:

  • Every time the calculator is turned on (from "hibernation" of course, as it would no longer cold-boot), the diagnostic mode will open with the message "ABS Mark NG" on the top left, in the place of "LY755D MAIN":


Performing a ROM checksum test from the diagnostic mode results in this:


It is possible to close the diagnostic menu by pressing EXIT (unlike what happens when opened normally, it will not restart the calculator) and continue operating the calculator, which may be useful during an exam, for example (assuming you don't know enough nor care about what's happening, and can keep calm).

  • When connecting to a computer through USB, instead of the usual dialog asking the user to select a mode, a "Receiving..." screen, not usually accessible, appears. This is the color-version equivalent of the screen fx-9860G users see when connecting to a computer through USB. The computer, if a Windows machine configured to look for drivers, will look for CESG502 drivers, the same used for communication with a fx-9860G.
    Presumably, in this mode the calculator is listening for Protocol 7.00 commands, which, eventually along with its command 1 subtype 56 (Upload and Run), can be used to recover a damaged calculator.
  • OS updates using the official update bundles might not work. The updater will send a binary, presumably through Upload and Run, that in normal conditions is used to retrieve information about the calculator and the current OS, as well as receive and flash the new OS when proceeding. However, since the information the updater wants to retrieve is in the first flash sector which, along with the bootloader, may be damaged, meaning it can fail at retrieving such information. In that case (the only studied one), an error message will be shown on the computer and the calculator will not reboot or show any other change on screen. The updater payload doesn't respond to keyboard interaction.
    Further executing the updater bundle will do nothing as it cannot find the calculator in the correct state for receiving the updater payload (it doesn't expect it to be running the payload already). The only way to exit from a binary sent through Upload and Run is rebooting the calculator, which means our exploration ends here.

Recovering From a Damaged Bootloader

Information in this section is purely speculative, because as far as the community knows, no other Casio Prizm has ever failed in a way where a recovery could be attempted. Anyway, here are some ideas on what to do next time.

The "Receiving" mode described above is certainly interesting and useful. Protocol 7.00 includes some commands that may be used to fix a broken bootloader, like: Packet type 0x01 (Command), subtype "50" ("Flash image transfer"). This could possibly be used to transfer a full flash image taken from a working calculator. Bonus points if it can also upgrade the calculator model.

Even if this command is not supported in the listening implementation of the protocol on the damaged calculator, there's also: Packet type 0x01 (Command), subtype "56" (Upload and Run), which is used to update any binary to a specified RAM address (this is what the updater bundles do to send the payload). It should be possible, even if unpractical and with reduced chance of success, to craft a binary that is made to run from RAM, and can write a good CASIOABS from a good copy of it. This copy could be stored on the payload itself (easier, but needs a bigger payload and RAM area to run it), or it could be received through USB (harder, requires that a implementation of the USB protocol be included in the payload, but it's not impossible at least for Casio, because it's what the OS updater does).

Special thanks to Simon Lothar for documenting the Upload and Run functionality.