Newsgroups: comp.sys.handhelds
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!faui14!kskalb
From: kskalb@faui14.informatik.uni-erlangen.de (Klaus Kalb)
Subject: Re: Using bin2asc (HP48SX)
Message-ID: <kskalb.670886112@faui14>
Organization: CSD., University of Erlangen, Germany 
References: <68702@eerie.acsu.Buffalo.EDU> <kskalb.670769081@faui14> <68953@eerie.acsu.Buffalo.EDU>
Date:  5 Apr 91 21:15:12 GMT
Lines: 44

cloos@acsu.buffalo.edu (James H. Cloos) writes:

>In article <kskalb.670769081@faui14> kskalb@faui14.informatik.uni-erlangen.de (Klaus Kalb) writes:
>|cloos@acsu.buffalo.edu (James H. Cloos) writes:
>|
>|>Last night I came up with a method of using the bin2asc program with files
>|>that are an odd number of nybbles long.  As some of you will remember, it
>|>was shown that this doesn't work too well because the program assumes that
>|>there is an extra nybble of info at the end of the file; this disrupts the
>|>calculation of the crc, thus making the generated ASC file unuseable.
>|

[stuff deleted]

>I went thru each of the binaries I have stored here on our SunCluster.
>Those whach are an integral number of bytes long (after transfer to the 48)
>bin2asc w/o flaw.  Those that are an odd number of nybbles long (again, as
>measured on the 48), if the extra nybble (in all of my tests it WAs a zero,
>but that might be different on other systems; that is why I used the more
>general term) is removed, asc2bin run on the ASC file to determine what the
>calculated crc is for the rest of the data, that crc put into the ASC file,
>the newly edited ASC file run thru asc2bin, and the version letters in the
>headers of the newly generated and the orriginal binary files changed so
>that tey match (asc2bin.c, as posted, defaults to `C'), you will find that
>the two binaries are exact copies of each other.

Now I see....
Of course this will work. But you have to *know* that the thing has odd length
beforehand !

My problem was: I created an object using star on the SUN, ran bin2asc on it,
stuffed that output in a larger HP48 User Language source file, transferred
it in mode T(3), and *BINGO*, ASC-> barked.

My point is: How can bin2asc *KNOW* that the thing has odd length without
having it ever transferred to the HP48 ?

Your point seems to be: 
Have different asc2bins for even and odd length.
Or give it an option asc2bin -e and asc2bin -o.
That's possible. But how to do automatically ???

-KK