Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!microsoft!alonzo
From: alonzo@microsoft.UUCP (Alonzo GARIEPY)
Newsgroups: comp.sys.handhelds
Subject: Re: usrlib format
Message-ID: <56291@microsoft.UUCP>
Date: 3 Aug 90 21:38:06 GMT
References: <1990Jul27.102116.8104@santra.uucp>
Reply-To: alonzo@microsoft.UUCP (Alonzo GARIEPY)
Organization: Microsoft Corp., Redmond WA
Lines: 41

alo@kampi.hut.fi (Antti Louko) writes:
> I have done some reverse-engineering to find out the library format.
> Everything else seems to be quite clear but I don't have any idea how
> the checksum is calculated. This checksum appears to be 16-bit.
> One-bit change in the library contents seem to change whole checksum.

The HP 48 has a hardware CRC.  Every time you read a nibble from memory
the 16 bit CRC at address #00104 is updated.  Checksumming a block of
memory (as the BYTES command does) involves zeroing that location and
then reading the entire block of memory.  The CRC hardware picks the data 
right off the bus.  Among other things, this means you can checksum a block 
of memory at the same time you move it.  Libraries use the same CRC.  You
must disable interrupts if you do this from machine language.

Experiment
----------
Since Kermit also needs a CRC, my guess was that they may be using the Kermit 
CRC throughout.  Here is a fragment of C code that calculates the type-3 
Kermit checksum.  It is based on the CRC-CCITT polynomial x^16+x^12+x^5+1.

crc()
{   	/* Compute a nibble-oriented type-3 Kermit block check.             */
    	/* This algorithm was invented by Andy Lowry of Columbia University */
	unsigned n, crc;  

	crc = 0;
	while (getnibble(&n))
		crc = (crc >> 4) ^ (((n ^ crc) & 0x0f) * 0x1081);

	return (crc);
}

Alas, this doesn't seem to correspond to the HP 48 hardware CRC.  

HP, can you post a C program fragment that calculates a checksum 
equivalent to the one in hardware?

Thanks,

Alonzo Gariepy
alonzo@microsoft