View source for Crunch/LZDEF20.DOC

Here, extracted for convenience, is a description of the [[Crunch]] header format LZDEF20.DOC, included in [http://www.classiccmp.org/cpmarchives/cpm/mirrors/oak.oakland.edu/pub/sigm/vol294/crunch20.lbr 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