Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!tamsun.tamu.edu!ftg0673 From: ftg0673@tamsun.tamu.edu (Rick Grevelle) Newsgroups: comp.sys.handhelds Subject: Re: Using bin2asc (HP48SX) Message-ID: <14341@helios.TAMU.EDU> Date: 8 Apr 91 14:41:13 GMT References: <69320@eerie.acsu.Buffalo.EDU> Sender: usenet@helios.TAMU.EDU Organization: Texas A&M University Lines: 29 In article 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