ram@tellabs.com (Bob Martin) (11/08/90)
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. When using kermit to archive them on my Amiga, EARTH stores fine in binary, but simply refuses to even attempt to upload in ASCII (9600, no parity, translation code 3, checksum type 3 for both transfers). When I redownload EARTH (binary), I can display it without error. When ASCII is attempted, the Amiga reports "Host error, out of memory" which is strange since the Amiga is the host and it has about 2 MB of free RAM. WRLD, on the other hand, will upload fine either way (no errors), 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......". And yes, when I set the HP to binary or ASCII, I set the Amiga to match it. Any information to get this working is GREATLY appreciated. One last question: When I want to display Earth in PICT, I need 11K free mem, which is TWICE the size of EARTH. I can understand needing 5.5K free mem, but why 11K? Is there any way to change this? Oh, and also, it needs at LEAST twice the size in free mem, 1.9 times the size in free mem won't cut it. Thanks! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bob Martin | ram@tellabs.com ...!uunet!tellab5!ram Tellabs, Inc. |"Listen to me now, and believe me later" - Hans & Franz Lisle, IL. 60532 |"Flibble-dee Floo" - Grumpy Old Man
rrd@hpfcso.HP.COM (Ray Depew) (11/09/90)
ram@tellabs.com (Bob Martin) asks: > 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. When using kermit > to archive them on my Amiga, EARTH stores fine in binary, but simply refuses to > even attempt to upload in ASCII (9600, no parity, translation code 3, checksum > type 3 for both transfers). When I redownload EARTH (binary), I can display it > without error. When ASCII is attempted, the Amiga reports "Host error, out > of memory" which is strange since the Amiga is the host and it has about 2 MB > of free RAM. Your problem is that, when uploading grobs in ASCII mode, the 48 has to translate the grob from binary to ASCII. The ASCII form takes up about twice as much memory as the binary form. ("about"...) Similarly, when downloading a grob in ASCII mode, the 48 holds the ASCII form in memory while it creates the binary form. So in each case, you have two copies of the grob in memory at once, and even though you have enough room for one binary copy, the 48 gags on the second (ASCII) copy. The "Host error" means that the 48 sent the Amiga a Kermit error message. In Kermit grammar, the 48 is always the host. Don't ask me why; maybe one day I'll read the book and find out. (then again...) I've seen the same "Host error" message using Procomm on an MS-DOS machine and Uniterm on a Brand Ex. > WRLD, on the other hand, will upload fine either way (no errors), 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......". > And yes, when I set the HP to binary or ASCII, I set the Amiga to match it. Well, despite what you just said, it sounds like you had the 48 set to ASCII (and the Amiga set to ???) when you downloaded the binary version of WRLD to the 48. (Is your head spinning yet? Mine sure is...) The "HPHP-E......." header is the normal header for a binary file, and you ONLY see it when you're viewing the file on your PC -- or when you have the ST set to ASCII during download. > Any information to get this working is GREATLY appreciated. > One last question: When I want to display Earth in PICT, I need 11K free mem, > which is TWICE the size of EARTH. I can understand needing 5.5K free mem, > but why 11K? Is there any way to change this? Oh, and also, it needs at LEAST > twice the size in free mem, 1.9 times the size in free mem won't cut it. Sounds like a LAST STACK or LAST ARGS type of problem. (It also shows why HP didn't include a LAST PIC command. Can you imagine what a memory hog THAT would be? ) Are you pressing EARTH PICT STO { # 0d # 0d } PVIEW to see it, or something else that would stuff it into LAST DOODAH? Maybe if you disable LAST DOODAH it will band-aid the problem for you while you check your display algorithm. > Thanks! Good luck. Regards Ray Depew IC's by Bill and Dave rrd@hpfitst1.hp.com
bson@wheat-chex.ai.mit.edu (Jan Brittenson) (11/10/90)
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.