CRN v2.4

CRN.REL is an adaptation of Steve Greenbergs CRUNCH system to execute on
8080/8085/V20 processors, and be an independent module suitable for
inclusion in other programs.  This is a sketchy description.

The entry point to CRN is "CRN", which should be declared extenal in the
calling program.  This entry should be called with a parameter in a (see
below), and the address of a 25k block of memory in HL.  CRN will then
call the (user supplied) routines GETCHR and PUTBYT to perform its
"crunching" operation.

GETCHR must return the next input byte from the input file or device in
the A register, with the carry clear until EndOfFile.  When all input
characters have been supplied, the carry should be set.  If a checksum
is to be accumulated it should be done by GETCHR.

PUTBYT will receive "crunched" output bytes in the A register, and must
write them to the output file or device.  Every 256th call to PUTCHR
will be made with the Z flag set, which can be used to trigger monitor
operations if desired.  Any write errors must be handled by PUTBYT.

Two additional routines ".IDIV" and ".IMUL" must be supplied.  For CRN


unsigned operations.  The code is available in BUFFLIB (using the /s
option to search when linking).

When CRN is called it becomes the master controller, and makes further
calls to GETCHR and PUTBYT, with it's own stack setting.  At exit (i.e.
the crunching is complete) control is returned to the original caller,
with 0 in the A register, and the carry clear (assuming no errors). If
an error occurs, the A register will contain an error code, and the
carry will be set.  The codes are:

     0    No error
     1    Input file already crunched or squeezed
     2    Input file empty (or only 1 byte)
     3    Insufficient memory

The original call to CRN passes a "strategy" parameter in the A register.
The following bit fields are significant:

    Bit  Weight  Meaning (if 1)
     7     80h   Ignore a squeeze/crunch mark.  Error 1 will not occur.
                 This allows any binary pattern to be crunched.
     6     40h   Do not allocate a private stack.  The existing SP is
                 set above the memory area to be used (usually to the
                 top of available memory).  Allows more efficient use
                 of memory.
    5,4    30h   The two bits in this field describe the "checksum"
                 flag to be emitted.  The value (right shifted 4 bits)
                 is placed in the output stream checksum flag position.
                 Assignments are:
                       0    Normal checksum (modulo 65536)
                       1    CRC16 checksum
                      2,3   not yet assigned.
    3..0   0fh   This field can hold values from 0 to 15, and control
                 the adaptive reset facility.  The recommended values
                 are 4 (allow reset after table full and 1024 codes 
                 reassigned) and 0fh (allow reset after table full).

FCRUNCH uses 044h for this parameter, and sets it's stack to the top of
memory.

The following data segment locations are available to the calling program,
and may be monitored as desired.  THEY SHOULD NOT BE ALTERED.

INCNT       A count of input bytes received
OUTCNT      A count of output bytes emitted
NXTCOD      The number of codes assigned
TTOTAL      The number of code re-assignments made

These are all word (2 byte) locations.

                        -----------

Since nothing works like an example, the source for FCRUNCH is contained
in this library.  It is a functional replacement for CRUNCH, with slightly
different conventions and facilities, and executes on Z80/8080/8085/V20
processors (unlike CRUNCH, which requires a Z80).  Most of the abilities
of CRN are used in FCRUNCH, which also uses BUFFLIB to supply the file
i/o facilities.

I suggest you also read UNC.DOC, which may clarify the system further.

       C.B.F