Steve Russell wrote:
> source=
> http://www.piclist.com/postbot.asp?id=piclist\2002\11\13\182704a
>
> Each sector (typically 512 bytes) of a floppy disk has a CRC (Cyclic
> Redundancy Check) code stored with it. CRC is a fancy checksum - an
> algorithm calculates a 16-bit (IIRC) number that is based on the
> contents of the 512 bytes of data and writes it to the disk at the
> same time as the data is written. When the drive reads data from a
> sector, the *drive controller* (no CPU involved) calculates the CRC
> from the data read and compares it with the CRC that is stored on the
> disk. I believe the algorithm used is designed to be such that
> typical errors in the data (or the CRC itself) will mean that the two
> CRCs will be different.
>
> An algorithm that ensures a statistically fair spread of calculated
> CRCs will read a faulty disk and calculate a CRC equal to the stored
> value only 1 in 2^16 times - on which occasion, the error will go
> undetected. The use a of an algorithm that anticipates the typical
> type of error will do better than that.
>
> Steve.


... more info:


A typical media failure will not create a single bit error, the media spot
deffect sometimes hit several tracks and many bytes, this will create a
multiplication of the error correction effectivenes, but ends up always in
1/65536*8 error bit undetection. No matter how many bits are involved in
the failure spot, the 1/65536*8 flaw still always the same.

The CRC-16 will always ends up in zero when processing its own final
numbers.
For example, using a program I develop years ago to calculate CRC in DOS
command line, http://www.ustr.net/files/crc16.exe you can see this example
when calculating CRC16 for hex bytes 01-02-03-04-05;

C:\> crc16 01 02 03 04 05 0e
+--------- Wagner Software - 1987 ---------+
+--------3270-CRC=x16+x14+x1--[A001]-------+

01 02 03 04 05
Final CRC Transmited: 0EBB


Then, when inserting the CRC calculated (0EBB) in the calculation, the
result goes to zero.

C:\> crc16 01 02 03 04 05 0e bb
+--------- Wagner Software - 1987 ---------+
+--------3270-CRC=x16+x14+x1--[A001]-------+

01 02 03 04 05 0E BB
Final CRC Transmited: 0000

This is how the majority of CRC checkings are made, the data is read
including the CRC check bytes, if the actual generated CRC goes to zero,
then both crc's were equal and data is valid.

The CRC-X25 (CCITT), always end up with a fixed value of "FFFF" when
including an exclusive or FF from the recorded CRC into the calculation,
examples:

C:\> crcx25 01 02 03
+--------- Wagner Software - 1997 ---------+
+      CCITT-CRC=x16+x12+x5+x1--[8408]     +
+------INVERTS (NOT) ALL BITS BEFORE TX----+

01 02 03
Final CRC Transmited: 3B9D


C:\> crcx25 01 02 03 C4 62
+--------- Wagner Software - 1997 ---------+
+      CCITT-CRC=x16+x12+x5+x1--[8408]     +
+------INVERTS (NOT) ALL BITS BEFORE TX----+

01 02 03 C4 62
Final CRC Transmited: FFFF


C4 = XOR FF of 3B
62 = XOR FF of 9D

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body