Crunch/LZDEF20.DOC
From Just Solve the File Format Problem
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