Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ub!acsu.buffalo.edu From: cloos@acsu.buffalo.edu (James H. Cloos) Newsgroups: comp.sys.handhelds Subject: Re: Using bin2asc (HP48SX) Message-ID: <68953@eerie.acsu.Buffalo.EDU> Date: 4 Apr 91 21:02:07 GMT References: <68702@eerie.acsu.Buffalo.EDU> Sender: news@acsu.Buffalo.EDU Organization: State University of New York @ Buffalo Lines: 69 Nntp-Posting-Host: lictor.acsu.buffalo.edu In article 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. | |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 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. Here is the list fo the files I tried this on. I do not have the notes anymore on which were odd and which even length, but it shouldn't be too difficult to do it as well so that we can get some independant verification. 5 SPKR.bin 4 cmpctarry.bin 2 diraiddir.bin* 1 fact.bin 1 iferrlib.bin 2 lbrw.bin 1 matrix.bin 7 mldl.bin 6 tetris.bin 9 tetris3.bin 1 tf.bin 6 tools.bin 2 tree.Z 5 wof3.bin* 6 wof3lib.bin** * -- created by me on the 48 and Kermited to the computer ** -- output file from usrlib here on the SPARCstation. The rest are either uudecoded or asc2bin'ed copies of posted stuff. -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>