Crunch/LZDEF20.DOC

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