JTN: extracted for convenience; see Crunch

2012-12-06T01:14:41Z

extracted for convenience; see Crunch

New page

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

Crunch/LZDEF20.DOC - Revision history

JTN: extracted for convenience; see Crunch