Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!decwrl!shelby!snorkelwacker!ai-lab!wheat-chex!bson
From: bson@wheat-chex.ai.mit.edu (Jan Brittenson)
Newsgroups: comp.sys.handhelds
Subject: Re: Kermit woes with large graphics objects on 48
Message-ID: <11786@life.ai.mit.edu>
Date: 9 Nov 90 18:20:35 GMT
References: <4498@tellab5.tellabs.com>
Sender: news@ai.mit.edu
Organization: nil
Lines: 66

In article <4498@tellab5.tellabs.com> ram@tellabs.com (Bob Martin) writes:

 > I have two large objects on my 48. One is a GROB of the EARTH's
 > surface, about 5K, and the other is an animated (rotating) WoRLD,
 > about 8K.

   First, I've been looking for a world map suitable for digitizing -
could you consider posting yours uuencoded?

 > When using kermit to archive them on my Amiga, EARTH stores fine in
 > binary, but simply refuses to even attempt to upload in ASCII ... the
 > Amiga reports "Host error, out of memory" which is strange since the
 > Amiga is the host and ...

   The HP-48 is the host in this case. When transfering an ASCII GROB
to the 48, the data size is somewhat more than twice the size of the
GROB (one nibble of data becomes one hex character). In addition to
buffering the ASCII data transfered, you need space for the object
itself. So you need _at least_ three times the GROB size to transfer
it. An 8kB GROB requires _at least_ 24kB of free memory to transfer.
Binary objects, on the other hand, can simply be transfered `as is,'
with very little overhead. That's why you can archive an (almost) full
48.

 > WRLD, on the other hand, will upload fine either way (no errors),

   WORLD is 5kB, and so requires somewhat more than 15kB (9kB less
than EARTH) to transfer.

 > however, when I donload it back to the 48, only the ASCII version
 > works. When I execute the binary version, instead of executing, I get
 > a quoted string in level 1 like "HPHP-E......".

This for sure qualifies for the FAQ...

   Make sure you have BINARY (command: SET FILE-TYPE BINARY, SET
BINARY, SET FILE TYPE BINARY, or whatever it's called on your system
this week) mode enabled. If the binary object received isn't a proper
object, it is simply reverted to a string. `HPHP-E' is simply the
preamble identifying this as a binary object.

 > And yes, when I set the HP to binary or ASCII, I set the Amiga to
 > match it.

   Are you *sure* you did so? For binary transfer, only the sending
end needs to be set to binary mode. Set both ends to 8 bits, no stop
bits, no parity. Also, some brain-dead systems just can't handle
binary files of arbitrary size - does your Amiga?

 > One last question: When I want to display Earth in PICT, I need 11K
 > free mem, which is TWICE the size of EARTH.

   Yes, that's probably true. From what I've seen of the GROPs in the
ROM, it appears a copy of the source GROB is created that's bit
aligned with the destination GROB. If the destination is a system
object in RAM (such as the graphic display, i.e. PICT), a copy of that
is created as well. The copy-and-align scheme allows easy use of
64-bit wide operations (such as the general block copy routines) on
the bulk of the data.

   A simple solution might be to cut your earth object down to several
smaller objects and write a piece of code to put it in PICT. Use the
graphical display to cut out suitable subrectangles, put them on the
stack, and record their relative positions.

A more expensive solution is to buy a 128k RAM card.