Crunch/LZDEF20.DOC

Latest revision as of 01:14, 6 December 2012

Here, extracted for convenience, is a description of the Crunch header format LZDEF20.DOC, included in CRUNCH20.LBR CRUNCH20.LBR (as LZDEF20.DZC -- yes, crunched):

               --------------------------------------------
                Crunched File Format, Rev. C   30 Aug 1986
               --------------------------------------------

         ID  FIELD:  Bytes 0 and 1 are always 076H and 0FEH,  respec-
    tively.  This identifies the file as "crunched".

         FILENAME:   The  filename field starts at byte 2.  It  is  a
    field  of variable length, terminated by a zero byte.  The  field
    contains  the  filename as ASCII chars, including  an  ASCII  "."
    immediately preceding the filename's extension.  Less than  eight
    characters may precede the ".", but three characters must  follow
    it  (ie  blanks in the extension  are to be explicitly included).
    Additional  characters after the 3rd extension character but  be-
    fore  the  zero byte specifically are allowed.  Those  characters
    preceded by a "[" char and followed by a "]" char are defined  as
    in  informal  file id or date stamp. Most versions of  UNCR  will
    echo these chars to the console for reference. Those bytes  which
    are  not  between these brackets are ignored by the  current  un-
    cruncher (reserved for future expansion).

         Following the zero byte are the following 4 bytes, in order:

         REFERENCE REVISION LEVEL:   1 byte  }
         SIGNIFICANT REVISION LEVEL: 1 byte  } described later
         ERROR DETECTION TYPE:       1 byte  }
         SPARE:                      1 byte  }

         CRUNCHED  OUTPUT: After the SPARE byte, the actual  crunched
    output  begins.  The crunched output is a series of variable  bit
    length  codes where byte boundaries are insignificant.   Crunched
    data  is  terminated by detection of an embedded EOF  code.  Zero
    bits are padded after the EOF to get back on byte boundary again.

         CHECKSUM: The next two bytes are the 16-bit checksum,  least
    significant  byte first.  The checksum is the modulo 2^16 sum  of
    all  the bytes as input from the physical input stream, prior  to
    repeat  byte encoding (or, in the case of uncrunching, as  output
    to the physical output stream, after repeat byte decoding).

         REMAINDER  OF THE SECTOR: The remaining bytes in the  sector
    following  the checksum are irrelevant.  CRUNCH fills  them  with
    "1A"'s.
    
              ---------------------------------------------

         These are the four bytes not fully described above:

         "Reference  Revision Level":  The program/revision level  of
    the  program that performed the crunch operation.  This  byte  is
    put  in  for general reference only. The current  value  is  "20"
    (hex).

         "Significant Revision Level":  If the value of this byte  in
    a  crunched data file exceeds the value contained within the  un-
    crunching  program, the message "File requires newer revision  of
    program" will be displayed.  If changes or enhancements are  ever
    made to CRUNCH which are significant enough to actually output an
    incompatible file, the information in this byte will allow a  new
    revision  of UNCR to be compatible with all existing data  files,
    old  or  new.  The error message gets displayed only  if  someone
    tries to uncrunch a new file with an old uncruncher which doesn't
    know about the "future" format yet. Current value is "20" (hex).

         "Error Detection Type": If this value is non-zero, the  cur-
    rent  uncruncher will not examine the checksum or give  an  error
    associated  with  it.  This will permit a CRC type (or  no  error
    checking) value to be used if circumstances warrant it. The  cur-
    rent  UNCR program is always checking for "illegal" codes,  which
    are  ones which have not been defined by previous codes.  If  any
    are  encountered,  the message "Invalid Crunched File"  is  disp-
    layed. This inherent self-checking probably precludes the  neces-
    sity of more advanced error checking.

         "Spare":  The SPARE byte is a spare byte.

                                               - Steven Greenberg

                                             Rev C  30 Aug   1986
                                             Rev B  16 June  1986
                                             Rev A  30 March 1986