Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!portal!cup.portal.com!David_Michael_Kaffine
From: David_Michael_Kaffine@cup.portal.com
Newsgroups: comp.sys.handhelds
Subject: Re: Today the subject is libraries (LONG)
Message-ID: <35976@cup.portal.com>
Date: 16 Nov 90 02:21:18 GMT
References: <46387@eerie.acsu.Buffalo.EDU>
Organization: The Portal System (TM)
Lines: 75

Please bear with me - I've rarely posted my own articles before, and
I'm using an unfamiliar system.

In a recent article (see - I don't know how to do followups correctly yet),
Jim Cloos described the structure of the Library object on the HP-48.  He
left a couple of question marks in the description, which I will try to
elaborate here.

The unknown fields were all a part of the hash table.  Here's my
current understanding of the hash table structure:

#02a4e		Prolog for binary integer
#length		Length of binary from this field to end
#ptr1		5-nibble offset (from start of this field) to first
		  1 character name (#00000 if none)
#ptr2		Pointer to first 2 character name
...
#ptr16		Pointer to first 16 character name
#decompile	5-nibble offset (from start of this field) to #xlib0
		  below.  This tells the 48 where the pointers are
		  for it to decompile a name from an xlib object

1-char-name-data	This is as Jim described - each name is
2-char-name-data	entered here, in no particular order, except
3-char-name-data	that names of the same size are grouped
4-char-name-data	together.  Each name is a two nibble size,
5-char-name-data	the ascii data, then the XLIB number.
...
16-char-name-data

#xlib0		5 nibble offset, which as Jim mentioned, is positive
		  to point backwards (unlike most of the other offsets),
		  This points to the size nibbles of the name for
		  XLIB object #0
...
#xlibn		Pointer for the last named XLIB object's name.



That's it for the hash table.  One other thing that I think Jim
left out - the library object has 4 CRC nibbles appended to it.
These CRC nibbles are calculated using the Kermit CRC algorithm,
but the CRC is calculated starting with the length field, not the
#02b40 field, and includes everything up to (but, for obvious reasons,
not including 8-) the CRC itself.  The length field of the library
includes the 4 CRC nibbles.

WARNING:  Be careful when playing around with library objects with
incorrect CRCs.  I did this several months ago, and started to notice
that I had less memory than expected.  It turns out that if you
install a library with a bad CRC in port 0, at the next system halt,
the bad CRC is detected, and the bad library object is 'pushed' aside
so that all the good objects in port 0 are contiguous.  But, the
bad library still takes up memory!!  I ended up doing a lot of peeking
and poking to reclaim my memory again.  I didn't try it, so I'm not
even sure a memory clear would work.  This warning applies to the
simple library that Jim posted, since it doesn't have a CRC field
(I'm not talking about the CRC needed for the ASC-> program - the
library object itself has an embedded CRC).  I don't know for sure
since I'm not risking any memory lost right now - oh, what the hell,
I just tried it, and sure enough, the library doesn't install correctly.
Instead, when the bad CRC is detected, you get the message
Invalid Card Data,
and the behavior I just described.

One final note - I don't believe there would be any performance
penalty for ordering the various components of a Library object
at random - they are always going to be accessed via pointers.


Again, I apologize if the preceding post is all messy.  It will take
me some time to get used to this new system (I'm using a $#@!% line
editor right now).  But, I'll never learn it if I don't try it.
Please direct replies to the address above, or
Dave.Kaffine@MicroProd.NCR.com