Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!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) Newsgroups: comp.sys.handhelds Subject: Re: Using bin2asc (HP48SX) Message-ID: Date: 4 Apr 91 12:44:41 GMT References: <68702@eerie.acsu.Buffalo.EDU> Organization: CSD., University of Erlangen, Germany Lines: 35 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. I don't think that's true. If an object of odd nybble length is stored on a byte oriented host, it must be padded with a trailing zero nybble. Ever seen a file size of 5.5 bytes on your host ? So bin2asc doesn't assume the trailing nybble, it is really there ! >However, the following can alleviate this problem: >After running the bin file thru bin2asc, save it under a different name. >Now run asc2bin on the generated ASC file. Compare the orriginal bin file >with the newly generated bin file, and determine if there are any >differences near the end of the file. The bin2asc program on the host can't tell wether the last nybble is significant or not. Converting back to binary and comparing doesn't help, because the trailing zero nybble really is there in the binary file. So you will get no diffs, even on odd length objects. >You can now post, type in, or otherwise use the generated and edited ASC >file with confidence. Did you try that ? Sorry to say, I can't see how this can work. >Happy converting! It's still a pain. -KK