Prev: I don't get it... HP 50G
Next: Sparcom Mechanical Engineering Pac for HP 48SX
From: Scotty on 2 Aug 2006 01:57
On Tue, 01 Aug 2006 21:05:40 -0500, "John H Meyers"
<jhmeyers(a)nomail.invalid> wrote:

>On Tue, 01 Aug 2006 06:38:05 -0500, CR wrote:
>
>> Transfer your directory from the 48 to a PC,
>> using either Kermit or Xmodem.
>> Binary transfer is fine.
>> Execute the OT49 function [ObFx].
>
>> If your directory is just data, as your post indicated,
>> everything should be OK.
>
>Strings, graphics, vectors, matrices, and complex numbers
>are binary compatible between 48 and 49 series;
>a lot of other "data" is *incompatible* -- even integer-valued
>small real numbers from -9 thru +9 are *not* compatible
>(and could cause a crash if used), even if within lists.
>
>And if you have any *programs* in there,
>they could be dangerous to run if transferred in binary mode.
>
>You are much better off using only Kermit, only in *ascii* mode
>(flag -35 cleared), which will export in *plain*text*
>(which the HP50 can re-compile); if anything was a SysRPL program,
>it was incompatible anyway, so just edit it out.
>
>> Good luck
>
>Especially after binary transfer :)
>
>By the way, not only does plain MS-DOS Kermit (or Hyperterminal's Kermit)
>work fine with HP48, but so does an *emulated* HP48 on your PC,
>which can use a computer's serial port, which can in turn
>be connected via cable to your calc, for a "calc-to-calc" transfer.
>
>You *can* transfer in binary to an emulated HP48, or in ascii
>to an emulated HP49 (the 49G emulation is fine for HP50 as well),
>and then from the emulator to a PC file, then via either
>transfer kit or SD card to HP50.
>
>[r->] [OFF]

Thanks for the information. I was wondering about some of that stuff.
I tried to transfer an old game I wrote for the 48GX in USER RPL and
it balked at the ZINTS. Scary news about some of the numbers possibly
causing a crash. Glad to know also that there's a limited solution.

Best,
Scott
From: John H Meyers on 2 Aug 2006 02:42
On Wed, 02 Aug 2006 00:57:00 -0500, Scotty wrote:

> I tried to transfer an old game I wrote for the 48GX in USER RPL
> and it balked at the ZINTS.

Set 49/50 calculator to "Approximate" mode before transferring
any HP48 series objects in ascii mode; alternatively,
set Approximate mode after transfer, then EDIT the object,
simply pressing ENTER to complete the "edit"
(this recompiles all "integers" as "reals")

Setting Approximate mode:

MODE > CAS > Approx [check mark]

-105 SF

Hold down the right-shift key and press ENTER
until top line of display shows [~] rather than [=]


[r->] [OFF]
From: Jean-Yves Avenard on 2 Aug 2006 03:37
CR wrote:

> 2. Transfer your directory from the 48 to a PC, using either Kermit or
> Xmodem. Binary transfer is fine. Pay attention to the usual naming
> conventions and restrictions.
Binary transfer is NOT fine if the intent is to then transfer the data
to the HP49/50.
It will most likely not work (you will receive something that looks like
"HPHP49-xxxx" on the HP49/50.
And if it does appear correct, chance are very high that you will
wipe-out your memory and the calculator will crash

JY
From: CR on 2 Aug 2006 07:44

Jean-Yves Avenard wrote:
>
> Binary transfer is NOT fine if the intent is to then transfer the data to
> the HP49/50.
> It will most likely not work (you will receive something that looks like
> "HPHP49-xxxx" on the HP49/50.
> And if it does appear correct, chance are very high that you will wipe-out
> your memory and the calculator will crash
>
The transfer can usually work, but of course JYA is spot-on about the header
and possible unpleasant results. I expect the OP saw something like
"HPHP48-Rxxx" when recalling the transferred object to the stack. That was
the whole reason for mentioning OT49 and ObFx. He did say data, which I took
to mean reals, strings, lists or arrays.

As a test, I just used conn4x to transfer a 48gx dir to the 50g. Upon recall
to the stack it looked like "HPHP48-Rxxx .... ". The 50g couldn't compile
this as a valid dir so it remained as a string. Then I executed ObFx to see
DIR
50
DIR
N*
[ ... ]
E*
[ ... ]
etc.
and stored in place of the transferred ob.

I did not tempt fate with this by including any program objects or anything
else that might not compile and play nicely. As others have said, ascii
tranfer is much safer.

CR


From: John H Meyers on 2 Aug 2006 17:44
On Wed, 02 Aug 2006 02:37:37 -0500:

> It will most likely not work (you will receive something
> that looks like "HPHP49-xxxx" on the HP49/50)

That's the original safety feature ("binary header,"
identifying calculator and ROM version) which was
designed into the original HP48 series file transfer system,
whereby any binary file not meant for the receiving calculator
will be left as a string, without attempting
to extract the original object.

"Object fixers," however, are for the express purpose
of defeating that safety feature, and they always "work,"
in the sense of leaving the original object on the stack
(or in a variable), after which "Your Mileage May Vary" :)

The first 20 bits of any 48/49/50 series object is a ROM address
where the CPU *will* go to handle the object; fortunately, ROM addresses
(prologs) for many common objects did not change between 48 and 49
(they are somewhat processor-dependent, and it's the same Saturn CPU,
even though now emulated in latest models), so if you
transferred a directory, it will still be a directory,
although if you transferred the real number object 2.00000000000,
its correct ROM address has moved, from 2A2DE in 48 series
to 2F961 in 49/50 series, causing a possibly severe problem
when the CPU goes to the wrong address after using an "object fixer"
(which doesn't really "fix" anything, but simply bypasses
the original safety check).

Within directories, each variable's content will again in turn
face the same issue as did the original object; within any
composite objects (programs, lists, algebraic formlae, and unit objects),
the same situation is again faced by every element in the composite,
and as soon as you run into one single incompatible item
(pointing to a moved ROM address), "the ball game is over." [TILT!]

For example, is the formula 'X^2.-2.25' compatible between 48 and 49 series?

Well, the overall "symbolic" prolog (DOSYMB) is still at 02AB8,
the embedded DOREAL (for 2.25) is still at 02933,
but the function x- (subtract) has moved from 1AD09 (48) to 39CFC (49),
and even the special real value 2. (%2), represented by a special
ROM address of its own, has moved from 2A2DE (48) to 2F961 (49),
so there is no way that a binary transfer will work in general
on all formulas, programs, unit objects, real numbers or number lists;
it will, however, work on arrays (real or complex, not symbolic)
and complex numbers, strings, grobs, and user binary intgers
(which are different from the new "exact integers").

When in doubt, however, transferring in "ascii" mode is the safer bet.

This mode displays everything in plain text, if possible
(the same as when editing on the calculator), then it transmits
that text, and finally the receiving calculator re-compiles the text,
just as if it had been newly entered in the "text editor" on that calculator.

During these steps, the binary ROM addresses from the original calculator
are forgotten, and everything is re-compiled anew into binary form
on the destination calculator -- you could think of it as similar
to "Rich text format" (RTF) for word processors, which can be used
to transfer documents between computers and programs whose internal
binary document formats are otherwise incompatible, using a common
plaintext language to describe fonts, colors, and all other formatting.

Certain objects (SysRPL/ML programs) can not automatically be transferred
this way, but sometimes can be transferred manually by a similar sequence
of steps (decompile to SysRPL/ML "source" text, transfer, re-compile).

Just as with RTF documents, occasional spots may need a touch-up
after having gone thru decompile to text, before a recompile
on another system, to make them behave exactly like the original,
but whenever you have binary-incompatible systems,
this sort of procedure may be necessary.

On the other hand, one attempt has been made to recognize all the
"supported" ROM addresses in a binary object, and replace them
with corresponding addresses for the other series of calculator;
this is implemented as a PC program converter,
so you could always give it a try and see what happens:

http://www.hpcalc.org/search.php?query=hpconv

In the final execution on a different model, however,
there are still minor differences, e.g. the flag list
(RCLF, STOF) is four words on 49, vs. two words on 48;
the "exact" mode does not exist on the 48;
certain algebraic commands work in 48 but stumble on 49
(and vice versa), etc., so the proof of the pudding
always remains in the eating, and sometimes
rests upon the skill of the cook.

[r->] [OFF]
First  |  Prev  | 
Pages: 1 2
Prev: I don't get it... HP 50G
Next: Sparcom Mechanical Engineering Pac for HP 48SX