cloos@acsu.buffalo.edu (James H. Cloos) (04/04/91)
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. 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. Utilities such as `cat -v` Emacs and diff are useful for this. (Remember that the header can also be different, specifically in the 8th byte of the file.) If the orriginal and newly generated bin files match everwhere other than (possibly) the 8th byte, you are done. Otherwise, edit the ASC file, and replace the last five (5) characters of hex data with four (4) zeros, or some other bogus data, but be sure you have replaced 5 nybbles with 4. Now run asc2bin on the file again, and note what crc it calculated. Reverse the order of that 4 digit hex number, and replace the bogus 4 nybbles you had earlier added to the ASC file with those four. The ASC file should now be accurate. Run it thru bin2asc again and compare as before, the only difference that you should find (if any at all) in in the 8th byte. You can now post, type in, or otherwise use the generated and edited ASC file with confidence. Also, if you know what kind of object the binary is, you may be able to determine from looking at the last line of the ASC file whether you need to edit it. For instance, if it is a program, algebraic, unit, library_data or list, the last 5 nybbles of the actual object will be `B2130' and if there is an extra `0' between that and the 4-nybble crc you know immediately that you'll have to edit it. Delete that extra 0 and use asc2bin to determine the actual crc, and put that crc into the file. Do now, though, that if the binary is a library, there will be the library'y internal crc immediately before ASC's crc. So, now that we know how to correct for odd-nybble long binaries in the bin2asc side, has anyone compiled it for messy-dos and/or AmigaDos and/or MacOS? The users of those systems eagerly await such executables. ;^) Happy converting! -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>
kskalb@faui14.informatik.uni-erlangen.de (Klaus Kalb) (04/04/91)
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
cloos@acsu.buffalo.edu (James H. Cloos) (04/05/91)
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. | |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: <>
kskalb@faui14.informatik.uni-erlangen.de (Klaus Kalb) (04/06/91)
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
cloos@acsu.buffalo.edu (James H. Cloos) (04/06/91)
Responding to the followup to my followup, in which the comment was made that you have to know before hand whether the file is even or odd in lenght: in the orriginal post, I described a procedure to determine, from the initial bin2asc output, whether the file was even or odd. Obviously, if the file is supposed to end with a ";" (ie, B2130), this is trivial. It is still possible for other data types, though. -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>
kskalb@faui14.informatik.uni-erlangen.de (Klaus Kalb) (04/08/91)
cloos@acsu.buffalo.edu (James H. Cloos) writes: >Responding to the followup to my followup, in which the comment was made >that you have to know before hand whether the file is even or odd in >lenght: in the orriginal post, I described a procedure to determine, from >the initial bin2asc output, whether the file was even or odd. Obviously, >if the file is supposed to end with a ";" (ie, B2130), this is trivial. It >is still possible for other data types, though. I think it's possible, but it's tough. You have to build in some knowledge of the HP48 datatypes. I am still convinced that theres virtually no way of doing it without knowlegde of the internal structures( eg. about Code objects and RPL programs). The best thing (IMHO) is to build it into the assembler. -KK
ftg0673@tamsun.tamu.edu (Rick Grevelle) (04/08/91)
In article <kskalb.671099011@faui14> kskalb@faui14.informatik.uni-erlangen.de (Klaus Kalb) writes: >cloos@acsu.buffalo.edu (James H. Cloos) writes: > >>Responding to the followup to my followup, in which the comment was made >>that you have to know before hand whether the file is even or odd in >>lenght: in the orriginal post, I described a procedure to determine, from >>the initial bin2asc output, whether the file was even or odd. .......... > >I think it's possible, but it's tough. You have to build in some knowledge >of the HP48 datatypes. .......... All of this is really quite unnecessary, and only came about in the first place because of some rather poorly conceived conversion schemes which shouldn't have been posted. There are in fact more serious flaws to be found in these schemes than the one being run into the ground here; which by the way has nothing to do with the machine code utilized by either of the routines, it's actually due to the misuse of a prefixed machine routine in the preceding RPL segment. The use of the indirect to set ROM ojects is just plain wrong, and will probably result in a memory crash when the object is evaluated, so don't try it. The recently posted HACKIT contains two conversion schemes which alleviate the above difficulties. ->ASCI is a binary-to-ascii conversion, ASCI-> reverses the result. Both routines are sensitive to ROM and RAM objects and will allow for a variety uses. For example, the string "78BF1" will return DUP when the ASCI-> command is used. Spaces and carriage returns are also allowed in these versions. Objects encoded using the ->ASC program, can be unencoded with the ASCI-> scheme as well. Rick Grevelle