Study of the cas format by Tom Wheeley and Tom Lynn

.CAS file specifications
========================

This document is (c)Copyright 1996 Tom Wheeley and Tom Lynn, although I
suppose technically the information contained within isn't :-)  You may
distribute it freely, so long as this message is not removed.  Many sections
are imcomplete, and possibly inaccurate (You Have Been Warned!)


Overview
========

The .CAS file format is split into two sections; header and data.
The data formats vary quite considerably between different CAS files, but the
header remains quite similar throughout.

Each section begins with a colon `:' (0x3a) and ends with a checksum.

Checksum
========

The checksum needs to be correct, or the calculator, PROGLINK or CASIOWIN
will not read the file.  CaS will continue, but issue a warning the event
of a checksum mismatch.

The checksum is created by adding all the bytes in the section (excluding
the colon), modulo 256. This is then subtracted from 256.  Thus it can be
created by csum=(csum-value) & 255.

Another way to look at it, is that all the bytes in the section, excluding
the colon but including the checksum, add up to 0, mod 256.

Header Layout
=============

Overview
--------

The header is structured as follows:

2  bytes     Magic
5  bytes     Type specific data (auxiliary header)
12 bytes     Editor filename
19 bytes     Unused?


Details
-------

2 bytes    Magic     Determines the type of file:

                     AA        Dynamic graph functions
                     AD        Variable memory
                     AL        All
                     AM        Alpha variable memory
                     BU        Backup
                     DM        Defined memory
                     DD        Screenshot
                     EN        One Editor file
                     FN        Set of Editor files
                     F1        One function memory
                     F6        Set of function memories
                     GA        Set of graph functions
                     GF        Graph zoom factor
                     GR        Graph range
                     GT        Function table
                     MA        Set of matrices
                     PD        Polynomial equations
                     P1        One program
                     PZ        Set of programs
                     RT        Recursion table
                     SD        Simulaneous Equations
                     SR        Linear regression data
                     SS        Standard deviation data

                     
5 bytes    type specific data.  Details given below.


12 bytes   filename  The filename for an editor program.
                     This should not be in lower case, as it will make the
                     program hard to call, but the Casio will accept it.
                     All unused chars are filled with 0xff

19 bytes   reserved  These bytes never seem to be used, and are filled with
                     `0xff'


Type specific header
====================

Program  (P1)
~~~~~~~
This contains a Program header, defined as:
  1 byte     unknown
  2 bytes    size
  1 byte     program type
  1 byte     unknown
  
* Size

Beware that the size is stored in big-endian format.  Read the bytes
sepearately and use:

  (size & 0xff00) >> 8    (first)
  (size & 0x00ff)         (second)

to be sure.

* Program type

This is arranged as a bit-field:

  bit(hex)         meaning

   1               Unknown
   2               Store stats data
   4               Matrix mode
   8               Unknown
  10               Standard Deviation mode
  20               Linear Regression mode
  40               Base-n mode
  80               Draw stats graph

Obviously many combinations are silly.

Multiple Program (PZ)
~~~~~~~~~~~~~~~~
Here there is a similar program header, but the program type is not used.
The size bytes refer to the entire size of all the programs put together.

Numbers
~~~~~~~
Data types which contain numbers have either 'RA' or 'CA' as the first
two bytes of the auxiliary header.  It is my guess that R and C stand
for Real and Complex respectively.

Screenshot
~~~~~~~~~~
  1 byte    Heigth of image
  1 byte    Width of image

Rest unknown.  Notably also, the first byte of the filename field is used.


Data
====

Next follows the data, preceded of course with a colon and terminated with
a checksum.

AFAICS, there are three main types of data:
  Programs
  Numbers
  Screenshots


Program Data
~~~~~~~~~~~~

    The program data is loosely based on the ASCII character set -- certainly
all the alphanumeric characters are in the right place.  All the scientific
and other functions are represented by a single token:

  `cos'  is represented by 0x82, not by `c', `o', `s' (0x63, 0x6f, 0x73).

    To allow for a representation for every character, some tokens are
`shifted';  ie they are preceded by the code 0x7f (127).  Thus the code for
`i' meaning sqrt(-1) is:

  0x7f 0x50

    There is also reason to believe that this is the internal format used by
the calculator itself, as a program consisting solely of `i' occupies 2
bytes, rather than the 1 occupied by a program consisting solely of `cos'.

    For a list of all known codes, see the file `token.ctl'.  Note that the
convention used in that file is that shifted opcodes are simply incremented
by 256 (0x100).  So complex i (or j) is designated 336 (0x150).  The base of
numbers in the tokens file follows C conventions.
  
    The program is terminated with an 0xff.  The 0xff terminator is included
in the checksum calculations, as i is part of the program data.


Screenshot data
~~~~~~~~~~~~~~~
    The data for these is made up of 8 pixels to every character, as would
be expected.  I expect that the cfx9800 screenshots could just _possibly_
be more than 1bpp :-)  I'll know for certain if anyone wishes to donate one
of the aforementioned items  (or screenshots therefrom =).

   For the black and white models, each byte contains info on 8 pixels,
reading across the screen.  However, the next byte covers the next 8 pixels
*below*, not across.  Note also that the file also starts in the top right
of the screen, working to the left.  I am uncertain as to whether the 8 bits
in a byte read to the left or to the right with increasing significance.

  Thus to recap, the file reads downwards, from right to left, in blocks of 8
pixels across.

Arrangements of files
=====================

Single Programs
~~~~~~~~~~~~~~~


Multiple Programs
=================

    A multiple program file consists of a normal header, then a colon and
then 38 5 byte program headers (discussed above).  This is followed by a
standard checksum, before a colon starts the next section.  Each program
header contains the size and type information for its respective program.

Note that the sum of the sizes of all the programs should equal the size
specified at the beginning of the CAS file, minus 2.  These extra two
characters covered by the first size indicator are the colon at the beginning
of the program data, and the checksum at the end.

    This contain the data for all the possible programs.  Programs 0-9,
A-Z, r then theta follow, every program being terminated by a 0xff.  Thus
empty programs are represented by just the 0xff and have a length indicator
of 1.  A checksum follows the long mass of programs, covering all of them.


Multiple Editor Files
=====================

    These seem to have a full header and checksum for every editor file,
and are written end to end in the file.

Conclusion
==========

As you can see these specs are very incomplete.  Information not yet
ascertained includes the following important sections:

  .  Number formats (as in SD data, matrices)
  .  Editor file considerations
  .  Format of the `core dump' produced by backup; esp. where and how the
     passwords are stored >:->