cloos@acsu.buffalo.edu (James H. Cloos) (10/18/90)
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.
Here is the downloadable file:
---------------------------------Cut me here, bitte!------------
%%HP: T(3)A(R)F(.);
@
@ KCRC (archived as kcrc.48) #CB3Ch and 162.5 bytes.
@
@ Disclaimer:
@ The required wrapper to use it with hexdump strings on the 48
@ is mine. The thought that this might be the crc algorithm
@ used by BYTES is from reading the src to usrlib (nibble.c [sic]
@ file) Copyright 1990 by HP. As the algorithm is not theirs,
@ and as I had to write the wrapper, and as I had to then compare
@ it with the output from BYTES to determine if the output would
@ be the same, I felt it is acceptable for me to post & otherwise
@ distribute it.
\<< \-> s
\<< # 0h 1 s SIZE
FOR J "#" s J
DUP SUB + "h" +
STR\-> OVER XOR # Fh
AND # 1081h * SWAP
SR SR SR SR XOR
NEXT # FFFFh
AND
\>>
\>>
-----------------Cut here, too, sil te plait---------------------
I call the routine KCRC and will ul it to wuarchive under the name
kcrc.48 .
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).
Disclaimer:
The required wrapper to use it with hexdump strings on the 48 is mine.
The thought that this might be the crc algorithm used by BYTES is from
reading the src to usrlib (nibble.c [sic] file) Copyright 1990 by HP.
As the algorithm is not theirs, and as I had to write the wrapper, and as
I had to then compare it with the output from BYTES to determine if the
output would be the same, I felt it is acceptable for me to post &
otherwise distribute it.