BL> You are the only one who knows what he is doing with CRCs.

 PE> Actually, that might not be true. For starters, the reference I
 PE> used was a magazine article from "embedded systems programming"
 PE> which Roy or Dieter (I think) sent me. Secondly, someone was
 PE> quoting the X.25 specs, saying that the seed value should be
 PE> 0xffff for the CCITT one. The X.?? specs were sufficiently
 PE> vague that I couldn't be dead sure that was true (my own
 PE> reference explicitly said that 0xffff seed was only for SDLC).

  Oh, no! All the SWAG 16-bit CRC use a zero seed. 

 PE> Next, there was no mention of XORing the 32-bit CCITT result
 PE> with 0xffffffff, but that's what Zmodem does, and that's what
 PE> these people (in NET_DEV) were saying they thought was always
 PE> the case.

  The idea is to get the bytes in the order they are sent by comms
(they are sent backwards) without having to process them. Your 32-bit
CRC gives the same answer as the 'zmodem' ones in SWAG, so I assumed
you had it right. In fact, they are still backwards and need extra
processing. I thought I might have a look at generating the CRC as an
array rather than a longint... not that it matters for speed when you
onky have to do it on the end of each block anyway.

 PE> Basically, if you want to know for sure, you're going to have
 PE> to pop down to Australian Standards (in Homebush Bay I think)
 PE> and try to find the definitive answer and then attempt to
 PE> interpret it. I thought my source of information was good, but
 PE> now I am unsure.

  I cam to the conclusion you had it right by a process of
elimination checking the SWAG results.

 BL> BTWTW... why do you rabbit on about unsigned longints in your
 BL> code? All the operations are bitwise, so why does it matter?

 PE> Bitwise operations on signed integers that have negative values
 PE> in them are not guaranteed to do what you would like. Unsigned
 PE> ones are. There are multiple ways of implementing signed
 PE> integers (2's complement, sign-magnitude). 

  Within the one language??

  Anyway, my point is what does it matter if you are only dealing with 
a string of 32 bits. They can call it anything they like... right?
 
 BL> BTWTBW... adding the CRC to the serial port is messy, isn't it?
 BL> It would be nicer to generate the CRC as a little array, since
 BL> that's the way it gets sent.

 PE> When you call the serial port routines, presumable via
 PE> com_putc() etc, you then need to calculate the CRC, and then
 PE> you com_putc() the result of the CRC. BFN. Paul. 

  Yes... as I said. It has to be split into bytes backwards and adds
an extra process. The secret of good engineering is to only do things
once. Once you have somethign that works, the next step is to go back
and remove all the extras.
 
Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---