Quote:
My HP-48SX bit the dust after a final/fatal fall
I'm sorry to read that. I hope that the 50g works out for you. You may want to
look at the documentation for the 48G series for some changes that may not be
well-documented for the 50g.
Quote:
and i was left with a host of backups of UserRPL programs (mostly backed-up as
entire directories) made using binary transfer.
I notice this statement in ASCIIBIN.TXT:
Quote:
Unfortunately, this program sometimes fails on directories. I'm not
entirely sure why it doesn't work (since it properly imports some
directories) and don't have a solution at present. For these pesky
directories, you'll still have to use ASCII Kermit to transfer the file
with a cable.
That rather surprises me. I don't know why it should fail either, short of
insufficient memory. Looking at their source code, they use the SysRPL command
EDITDECOMP$ to decompile the object to a source code string, which, as far as
I know, should decompile any pure UserRPL object, including any directory, and
if a directory contained any non-UerRPL object, then a Kermit ASCII transfer
should fail to properly decompile it as well.
Well, give it a try, and if you have any problem, then post again and we'll
try to work around it.
By the way, for "importing" and "exporting" objects with Emu48, use the Edit
menu's "Load Object..." and "Save Object...".
When you load ASCIIBIN.48 into Emu48, it will appear on the stack as something
like:
1: External External
External <3d>
External <11d>
External <1d>
That's okay; it's just the calculator's way of displaying a SysRPL program
that it doesn't "know" how to decompile properly. Just go ahead and STO it
with the name of your choice.
Also note that Emu48's "Save Object..." saves the object as a
binary-transferred file, so it has a 8-byte binary transfer header,
"HPHP48-W", plus, in the case of a string, five more bytes for the prologue
address and string length. My "ASCII on SD" program would ignore that, but for
most transfer methods those first thirteen bytes may well need to be edited
out with a text editor. I think it best to edit out everything before the
"%%HP:"
Quote:
Fortunately, there are no SYSEVAL sequences in my programs.
Good; as long as you're certain, that saves you a bit of editing.
Quote:
I will try your method(s) tonight.
Let us know how it works out.
Quote:
FYI and for my own curiosity's sake: I am running XP on my laptop but I have a
DOS emulator (DOSBox) running on it that appears to work satisfactory. I had
downloaded a DOS version of an ASCII to Binary converter for HP48 files and
was able to convert the few stand-alone programs (that I had saved seperately
from the directories) from binary programs to ASCII.
That's interesting; I wasn't aware of any such ASCII to binary converter for
DOS, although certainly it should be possible (although a lot of work) to
develop one.
Quote:
"%%HP:T(1):="D9D...." type strings. I got stuck when trying to figure-out how
to convert these into UserRPL source code strings. I had naively tried to use
Conn4x to dump them onto my 50g - with the mere result that it looked exactly
the same on the calculator (i.e. a mere string file that looked like
"%%HP:T(1):="D9D...." ) on the calculator.
It appears that something went wrong with (at least) generating the ASCII
transfer header. If the calculator receives data that doesn't contain a valid
(for the model) binary or ASCII transfer header, then it safely stores the
entire data stream as a character string, rather than attempting to compile it
to an object or (much worse) store it as an object.
A Kermit ASCII or Conn4x "text" mode transferred file will have a transfer
header similar to:
%%HP: T(3)A(D)(F(.);
The value for T() can be 0, 1, 2, or 3. This tells the calculator which
translation mode should be used when receiving the file.
The value for A() can be D, R, or G. This tells the calculator which angular
units mode should be in effect when compiling the source code, for the sake of
complex numbers and vectors with an angular component.
The value for F() can be either a period or a comma. This tells the calculator
which "Fraction mark" mode should be in effect when compiling the source code.
When writing your own source code files on a PC, you can put the parameters in
any order. For example,
%%HP: A(D)F(.)T(3);
works as well.
Also, parameters can be left out of the ASCII transfer header, in which case
the receiving calculator's current mode is used. A minimal ASCII transfer
header would be:
%%HP: ;
In this case, the header tells the calculator to to treat it as a source code
file (attempt to compile it), use whichever translation mode is currently in
IOPAR (or create a default IOPAR if it isn't found), and use whichever angular
units and fraction mark modes are currently in effect.
The 49 series (49G, 49gII, 49g+, and 50g) use the same ASCII transfer header
as the 48 series, although of course the binary transfer header differs.
Unfortunately, the ASCII transfer header doesn't include any information as to
whether the 49 series should be in exact or approximate mode when compiling
the source code. Some reasonable rules of thumb would be: If the file
originated from (or was written for) a 48 series, then have the 49 series in
approximate mode when downloading it (unless you want all reals without a
fraction mark to be compiled as zints). For 49 series objects, have the 49
series in exact mode when uploading or downloading (unless you want all zints
to be changed to reals).
Quote:
Was my biggest problem that the translate code was somehow set (by default?)
to one (as per the setting during the original archiving process?) or was it
that the binary to ASCII conversion needs to be performed on a HP48 emulator
like emu48? Just curious.
Binary transferred files don't include (or have any use for) the translation
mode; they're very simply an 8-character binary transfer header followed by
the compiled object, possibly padded to a full byte at the end. So I surmise
that the garbled ASCII transfer header with the T(1) is something done by your
DOS-based binary to ASCII converter.
Actually, any translation mode should work okay. I suggested mode 3 because I
generally find such files easiest to view and edit.
Also, it seems to me that MS Windows sometimes tinkers with non-ASCII
characters? Maybe when using the Windows clipboard?
Regards,
James