CCITCRC documentation (82/Feb/05) by C.B. Falconer, 680 Hartford Tpk, Hamden, CT. (203) 281-1438 CCITCRC is a program to read any CP/M file and print a cyclic- redundancy-check number based on the CCITT standard polynomial: x^16 + x^15 + x^13 + x^7 + x^4 + x^2 + x + 1 Useful for checking accuracy of file transfers, and more accurate than a simple checksum. Optionally will write an output file to the default drive, listing the CRC's of all files checked in a single session. A second value is output, which, if patched into the last 2 bytes of the file, will cause the CRC to be zero. Thus files with such patches no longer require a CRCKLIST for validation. This assumes the file space is available. I consider this a major added convenience. CCITCRC runs on both 8080s and 8088/86 cpus under CPM. An MSDOS version is also available. Commands: ccitcrc [drive:] [f] Examples: ccitcrc myfile.asm (check only myfile.asm) ccitcrc *.asm (check all .asm files ccitcrc *.* f (check all files, make file of results) CCITCRC is based on CRCK and variants by Keith Petersen, Dave Barker, Kelly Smith, and others. It is NOT compatible with CRCK (see notes below by Dave Barker). I have taken this opportunity to correct the initial state of the CRC checksum to avoid the zero-run problem and to enable the embedded CRC sums in files. The distributed library components all contain embedded self-checking CRC checksums. THE ONLY STABLE STATE of the CRC checksum is the zero case. All others are highly unstable, and thus more sensitive to errors. For comparison, the 8080 version of this program assembles in 5 to 10 seconds, on a 2.5 Mhz Kaypro, using SLRs Z80ASM, and leaves a ready to run CCITCRC.CMD on a 5 Mhz 8088 executed about 20% slower than did CCITCRC.COM on a 2.5 Mhz Z80. Disks and drives were identical. With reasonable code optimization I would expect times to be very similar, with a slight edge for the 8088. Note that the Z80 code does not use the Z80 instructions. Both the CPM80 and CPM86 versions were created from CRCK 5.1 for CPM86, with the added look-back crc value. Crcs are now output as bytes. The program name has been revised because the output of this system is not compatible with the widely disseminated earlier CRCK program. In addition the CRC value is initialized to 0FFFFh, so that initial runs of zeroes will affect the CRC. Zero initialization cannot detect variations in length of files of zero bytes, however the value of 0ffffh is sensitive to all input sequences, except for one that causes a 0 CRC to be generated, followed by zeroes. This is an extremely unlikely occurance. The 2nd value is meaningless for null files. The CPM86 code is crude. Many unnecessary CS:referances are generated, and 8086 register usage is poor. It is a direct 8080 code image. The MSDOS version allows for "short records". Thus it is possible to append the CRC value (the left pair) to the file, and increase the file length by 2 bytes. This is always safe. Any such file transmitted by XMODEM will be padded to a multiple of 128 bytes with zeroes, by most systems. These will not affect the embedded checksums (but non-zeroes will). Thus MSDOS users have several methods of appending available. A useful utility would be an automatic extender, given the file name and CRC value. 11/27/81 version 5.0, Dave Barker All earlier versions of CRCK.ASM (up to at least Ver. 4.2 of 10/06/80) seen by this writer (DAB) have a serious flaw in the algorithm used to generate the CRC value. Mr. Petersen used a routine from "EDN" magazine, June 5, 1979. Although the routine published in EDN was a workable one, the way in which it was applied in CRCK.ASM was incorrect (i.e. the routine should have been called 8 times per byte, each time with only one bit of the message in the A register, then, at the end of the file, 2 null bytes should have been processed as if they were part of the file). The method that is used in CRCK.ASM Version 5.0 is a table lookup method. Instead of calling a routine 8 times each byte of the message is processed in one short piece of straight line code. The table that is used in this method is first generated during initialization.