Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!usc!hacgate!tcville.HAC.COM!ferris
From: ferris@tcville.HAC.COM
Newsgroups: comp.sys.handhelds
Subject: Assorted HP48 questions
Message-ID: <8815@hacgate.UUCP>
Date: 13 Jun 90 00:36:44 GMT
Sender: news@hacgate.UUCP
Reply-To: ferris@tcville.HAC.COM ()
Distribution: usa
Organization: Hughes Aircraft Co., El Segundo, CA
Lines: 36


I am another quite happy HP48SX owner, having just recently acquired one.
I am especially delighted as my previous calculator, which I still
proudly own, is a 1980 vintage HP41C. Comparing the two, it's astounding
to realize how much the technology has grown in the past ten years.  And
I'm still impressed by what my 41 can do (especially with the PPC ROM
installed)!

So kudos to all the folks up in Corvallis!

I have run up with a couple of questions that puzzle me, though.

I have the distinct impression, and I have a sinking feeling that it is
because it is correct, that for an object to be globally accessable,
it must reside in the HOME directory.  If this is indeed true, it is
unfortunate there isn't a path variable the user can create.  The situation
in which this creates the most trouble is having a program in a lower
directory assigned to a key.  When in another directory and in USER mode,
pressing that key places on the stack the name of the program, which EVALs
to only itself.  Is there a _system provided_ way to make a key assignment
inactive when not in the directory that the object assigned to that key
resides?  What this boils down to is having different key assignments for
each directory. Is this possible?

I have noticed when using the BYTES command, that 100% of the time, the
number of bytes returned is _lower_ than the amount specified either in
the manual or by other people when keying their programs.  The checksums
match, but the byte count is lower. I have revision D of the ROMs, and
I've been wondering if HP came up with a different way to store objects
that is less space consuming. Now I certainly won't pass up more
efficient data compactions!

Thanks to anyone who can shed some light on these issues.
Mark Ferris                         smart:    ferris@tcville.edsg.hac.com
Image and Signal Processing Lab     dumb:     ferris%tcville@hac2arpa.hac.com
Hughes Aircraft Co., EDSG           uucp:     hacgate!tcville!ferris