(Comp.sys.handhelds)
Item: 928 by cloos at acsu.buffalo.edu
Author: [James H. Cloos]
  Subj: CRC routine for 48
  Date: Thu Oct 18 1990 12:06 

Enclosed is a crc routine that takes as input a hex dump of the form:
"84E2040D814C474"
and returns a binary integer (in that case #807Ch) corresponding to what
BYTES would return from the original object.

For instance, the above dump corresponds to
84E20  :  ID
40     :  length is 0x4 BYTES
D8     :  ascii code of \->
14     :    "    "   "  A
C$     :    "    "   "  L
74     :    "    "   "  G

Add the crc in reverse field format and you get the string:
"84E2040D814C474C708"
which when fed into ASC\-> returns '\->ALG'

What does this all mean?  Well, with this you can put together a hex string,
get the crc, attatch the crc, put a \n after every 64th character, and
use ASC\-> to compile it.  Why is this better than using the STR\->OBJ
program previously posted (& avail in all of the archives) you ask?
Simple: ASC\-> is more forgiving.  Even if the crc is correct for the given
sequence of nybbles, ASC\->, in my testing, kills the compiled obj and gives
you an "Invalid string error." when displaying the compiles obj would crash.
(Ie., I compiled some gibberish, as well as some hex dumps that had typos
with both methods.  ASC\-> never crashed (unless you gave it a 4 char string
such as "0000"!) but STR\->OBJ dutifully compiled the junk and left it on
the stack.  Here we bombed.  (Actually, they may not have even gotten THAT
far, but the end result is the same.)  Besides, the algorithm is useful
for more than just this, and can be converted back to C, though if you do
this, remember to do it a nybble at a time, not a byte at a time.

I should point out that the algorithm comes from kermit (see _KERMIT -
A File Transfer Protocol_ by Frank da Cruz, Digital Press, 1987. p. 257).