BL> BTW, the reason I did the translation is that the Pascal SWAG was
BL> stuffed up with three different answers. You are the only one who 
BL> knows what he is doing with CRCs.

Actually, that might not be true.  For starters, the reference I used was a
magazine article from "embedded systems programming" which Roy or
Dieter (I think) sent me.

Secondly, someone was quoting the X.25 specs, saying that the seed value
should be 0xffff for the CCITT one.  The X.?? specs were sufficiently vague
that I couldn't be dead sure that was true (my own reference explicitly
said that 0xffff seed was only for SDLC). Next, there was no mention of
XORing the 32-bit CCITT result with 0xffffffff, but that's what Zmodem
does, and that's what these people (in NET_DEV) were saying they thought
was always the case.

Basically, if you want to know for sure, you're going to have to pop down
to Australian Standards (in Homebush Bay I think) and try to find the
definitive answer and then attempt to interpret it.

I thought my source of information was good, but now I am unsure.

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

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

BL> BTWTBW... adding the CRC to the serial port is  messy, isn't it? It
BL> would be nicer to generate the CRC as a little array, since that's
BL> the way it gets sent.

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

---