HP Forums

Full Version: HP-49G and HP-49g+
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Hi,

may I ask you what is the procedure to connect two HP-49G (or two 49g+) to exchange variables and programs?

I know from the HP-49g+ manual that SEND and RECV should be the commands, but no connction procedure is described (e.g., should an XSERV | SERVER command be used?), nor if a 49g+ can communicate (with IOPAR equalized?) with a 49G. The manual lacks any description in its over-800 pages, on how two connect two calculators, or at least I couldn't find it.


Any help?

-- Antonio

Hi,

I believe that a brief description of the procedures involved can be found in the Help file for Conn4x. Look under XModem Library\XModem Server Menus. I hope this points you in the right direction.

Ken

For a pair of 49Gs, connect the calculators using the 10-pin to
10-pin cable. Make sure that the reserved variable IOPAR matches
in the calculators (and makes sense). Flag -33 should be clear in
both calculators (Transfer via wire). You could tranfer using
either the Xmodem file transfer protocol or the Kermit file
transfer protocol. For Xmodem, you could use XSEND on one and
XRECV on the other, or you could put one into Xmodem server mode
and use XPUT and XGET on the other. For Kermit, binary transfers
are faster than "ASCII" transfers, so set flag -35; you could use
SEND on one and RECV on the other, or put one into server mode and
use SEND, KGET, and FINISH on the other.

Starting with the 49G, XON/XOFF software flow control no longer
works, so the "serial I/O" commands (XMIT, SRECV, and so on), may
cause a receive buffer overrun if you send more than 255 bytes at
a time.

Perhaps easiest is to press APPS, select I/O functions, and then
use the obvious options in the choose boxes and input forms.

For the 49g+, transferring between two calculators "via wire" is
impossible because you'd need one of them to be a "USB host" and
the other to be a "USB device", and the 49g+ is a "USB device"
only. For transfers between a pair of 49g+es, use IrDA, that is,
set flag -33, line up the IR arrows and have the calculators
within an inch or so, and otherwise proceed as with a pair of 49Gs
communicating via wire.

For transfers between a 49G and a 49g+, a direct connection isn't
possible; you have to use something else (such as a PC) between
them. Note that you can open two instances of Conn4x with one
connected with the 49G and the other connected with the 49g+, and
"drag and drop" (or copy and paste) between them.

The 50g plus has IrDA, USB, and serial ports, so a 50g can
communicate with another 50g or a 49g+ via IrDA. The 50g (in
"Transfer via wire" mode) uses flag -78 to select between using
USB and serial, but I don't, offhand, know which state is USB and
which is serial. If you could get the right cable (input and
output lines reversed and no connection on the battery+ line), you
should be able to connect a pair of 50gs via their serial ports.

Note that the 50g's serial port is not RS-232 compatible, so to
use it to communicate with a 49G (or any other RS-232 compatible
port), you'd have to use level-shifting hardware between them.

Also note that the IrDA on the 49g+ and 50g is not compatible with
the IR transfer signal used with the 48 series.

The 48G series doesn't have the Xmodem server built-in, but the
Conn4x package includes an Xmodem server library for the 48G
series.

The 48SX/S doesn't have Xmodem built-in, but you could try a
search of hpcalc.org for Xmodem for the 48SX/S; it might be
available for all I know.

The 49g+ and 50g can print via IR to the HP82240A/B printer, but
the range is greatly reduced from what it is with the 48 series.

Regards,
James

Wow! I'm impressed! Thanks very much.

-- Antonio

Greetings James,

I am always impressed by your posts to this forum. They are always well thought out, clear and comprehensive. I have found that most of the nitty gritty details you expose are not to be found in the manuals, Usenet or the Web. Where did you learn all this stuff?

Ken

I'd have another question:

is it possible in RPL to move a variable into a port by program?

I'd like to write somthing like

:3:'VAR1' MOVE
or
:3:'VAR1' STO
just like PURGE works.

Any ideas?

-- Antonio

Aww shucks....

First off, I think that there may be more information available
than you're aware of.

For the 49 series, make use of the hp 49g+/ hp 48gII
graphing calculator advanced user’s reference manual

(AUR); a hyperlinked version is available at
http://www.hpcalc.org/details.php?id=6374. Except for such
details as the ports, memory, and external communications, this
pretty well applies to the 49G and 50g as well.

What you really need to make full use of the 48GX is the
HP 48G Series Advanced User's Reference Manual.
Unfortunately, I don't find an on-line copy of it. If I find the
time and feel ambitious enough (and can get my fingers warmed up
enough that I'm not too clumsy), I might scan it for a future
Museum CD-ROM set / DVD. I see that
Samson Cables offers the
printed book for $79.99 used or $90.00 new, but I'd suggest
checking eBay first.

For anyone using RPL models, I most highly recommend Bill Wickes's
Insights series. For those who learned Classic
RPN first, it's probably best to read his HP 41/HP 48
Transitions
first. These are available in the current
(Version 5.00) Museum CD-ROM set / DVD.
See:http://www.hpmuseum.org/cd/cddesc.htm.

By the way, so far, Dave has offered a special "Upgrade" price to
those who already have the set, and I'll expect that he'll
continue this for the next version, so I see little reason to wait
for the next version (which, for all I know, may be more expensive
than the current version if you buy it for the first time).

There's a lot of information at http://www.hpcalc.org/,
http://move.to/hpkb,
http://staff.science.uva.nl/~dominik/hpcalc/
http://page.mi.fu-berlin.de/~raut/, and links from
http://m.webring.com/hub?ring=hp48. Last but not least is
the usenet group comp.sys.hp48; you can search
the Google
archive of the newsgroup
all the way back to July, 1991; if
you don't find an answer, then ask.

Other than that, I suppose that it's a matter of experience with
RPL models (since the 28S). Don't believe everything that you
read; if you want to know how the technical writer thought
something was supposed to work, then read the fine documentation.
If you want to know how something really works, then experiment as
well.

As for writing clearly, well, I do make it a point to read my
posts over before actually posting them, asking myself whether a
reasonable person might misunderstand what I'm writing, and
whether I've really answered any question. Unfortunately, I do
have a strong tendency to ramble, making a short story long; I
suppose because everything is related to everything else.

Regards,
James

Quote:
What you really need to make full use of the 48GX is the HP 48G Series Advanced User's Reference Manual. Unfortunately, I don't find an on-line copy of it.

Hi James,

I have one scanned copy of it in .pdf format (HP Part No. 00048-90136), 764 pages, 40MB. I don't remember where I found it. I thought it was in the Museum DVD, I've just checked and it was not there.

Regards,

Gerson.

Edited: 9 Dec 2006, 6:47 p.m.

Quote:
I thought it was in the Museum DVD, I've just checked and it was not there.

Check here: http://www.hpcalc.org/details.php?id=6036

Regards, Thor

I second the thanks; I wasn't aware of that file. At about 36 MiB for the download, I'm in no hurry to check it out. Perhaps Dave can get the 48G documentation from Eric for the next CD-ROM set / DVD? I expect that Eric still has the original colour file.

hpcalc.org is wonderful, but for very large files, I think that it's better to have them on a disc than to download them.

Regards,
James

Note that each new RPL operating system is mostly a superset of the previous one, so don't ignore information on an earlier model; there's a good chance that it still applies to your model.

Regards,
James

Quote:
I'd have another question:

is it possible in RPL to move a variable into a port by program?


Certainly!

What isn't possible is to overwrite or edit an existing port
variable. The philosophy is that objects in ports are "backup"
objects that shouldn't be modified, although of course it should
be possible to discard them. To replace a port variable, first
PURGE the existing port variable and then STO the new object with
the same name. To edit a port variable, first move it to home,
then edit it, and finally move it back to the port.

But regarding your question about "moving" a variable to a port, I
expect that the command that you're overlooking is \->TAG. See
that (and DTAG) in the AUR.

Are you looking for code to "inline" in a program, or for a
program to store as a variable and call from other programs?

Something as simple as:

%%HP: T(3);
@ Move global variable to port program.
@ For any RPL calculator.
@ STO may silently fail if port doesn't exist.
@ Will error out if the global variable doesn't exist.
@ In 49g+ or 50g, will error out for port 3 if card not present.
@ Will error out if the port variable already exists.
@ Arguments:
@ Level 2: 'GlobalName'
@ Level 1: real or zint port number.
@ Results from bytes:
@ Checksum: # 789Ch
@ Size: 27.5
\<<
OVER RCL @ Recall the object (error if undefined
@ name).
PICK3 @ Copy global name down.
ROT @ Move port number down.
\->TAG @ Make port name.
STO @ Store as port variable.
PURGE @ Purge original global variable.
\>>
Should be okay as long as you get the port number right.

But note that, at least on the 49g+, although a STO to port 3 will
error out if a card isn't present, the calculator will happily
(and silently) store a variable to the bit bucket if you tell it
to STO to some other port that doesn't exist. To guard against
this possibility, we could do:

%%HP: T(3);
@ Move global variable to port program.
@ For 49g+ or 50g.
@ Will error out if the global variable doesn't exist.
@ Will error out for bad port number.
@ Will error out for port 3 if card not present.
@ Will error out if the port variable already exists.
@ Arguments:
@ Level 2: 'GlobalName'
@ Level 1: real or zint port number.
@ Transfer or enter in exact mode.
@ Results from bytes:
@ Checksum: # 7009h
@ Size: 67.
\<<
OVER RCL @ Recall the object (error if undefined
@ name).
PICK3 @ Copy global name down.
ROT @ Move port number down.
IF
DUP 3 > @ Too high?
OVER 0 < @ Too low?
OR
THEN
515 DOERR @ "Bad Argument Value" error.
END
\->TAG @ Make port name.
STO @ Store as port variable.
PURGE @ Purge original global variable.
\>>
But could the STO silently fail for some other reason? I doubt it,
but I don't really know for certain. We could use VTYPE or RCL to
verify that the STO actually worked, but note that both of these
will strip any tags and try again if they don't find the variable
on the first pass, so if we checked before purging the original
global variable, then they'd find the global variable if the port
variable didn't exist. I'll use local variables to work around
that. The following is probably overkill, but verifies that the
move actually worked before entirely abandoning the original
object and global name.
%%HP: T(3);
@ Move global variable to port program.
@ For 49g+ or 50g.
@ Will error out if the global variable doesn't exist.
@ Will error out for bad port number.
@ Will error out for port 3 if card not present.
@ Will error out if the port variable already exists.
@ Will error out if the new port variable doesn't exist or its
@ content isn't the same as the original object for any reason.
@ Arguments:
@ Level 2: 'GlobalName'
@ Level 1: real or zint port number.
@ Transfer or enter in exact mode.
@ Results from bytes:
@ Checksum: # 65C9h
@ Size: 265.5
\<<
OVER RCL @ Recall the object (error if undefined
@ name).
PICK3 @ Copy global name down.
ROT @ Move port number down.
IF
DUP 3 > @ Too high?
OVER 0 < @ Too low?
OR
THEN
515 DOERR @ "Bad Argument Value" error.
END
\->TAG @ Make port name.
VARS @ Current directory variables list.
0 @ Initial value for e.
\-> @ Bind local variables.
g @ Original global name.
o @ Original object.
p @ Port name.
v @ Original VARS list.
e @ Error flag.
\<< @ Begin defining procedure.
o @ Original object.
p @ Port name.
STO @ Store as port variable.
g @ Original global name.
PURGE @ Purge original global variable.
p @ Port name.
IFERR
RCL @ Try recalling port variable.
THEN
1 'e' STO @ Set error flag.
ELSE
IF
o @ Original object.
SAME NOT @ Not the same?
THEN
1 'e' STO @ Set error flag.
END
END
IF
e @ Error flag set?
THEN
o @ Original object.
g @ Original global name.
STO @ Restore original global variable.
v @ Original VARS list.
ORDER @ Restore original order.
p @ Port name.
" not stored correctly."
+ @ Make custom error message.
DOERR @ Error out.
END
\>> @ Abandon local environment.
\>>
Regards,
James

Edited: 10 Dec 2006, 12:40 a.m.

Hello,

I thought that only the AUR cover page was color!

However, as I only have the french AUR, can anybody tell me which part of the content of the English manual is in color ?

Many thanks!

Etienne

Edited: 10 Dec 2006, 7:02 a.m.

Very very very kind and clear.

As usual.

-- Antonio

Blue seems to be used for emphasis. For example, it's used for major headings, like "Contents", "Programming", "Programming Examples", and "Command Reference", and within "Programming", specific instructions, such as "To cause a user-defined error to occur with a program:" on page 1-51. Within the command reference, the heading command name for each command is in blue, and where examples are given, "example:" or "examples:" is blue. Maybe it's just my eyes and the type sizes, but it seems to me that two shades of blue are used for the text. Some illustrations, such as the torus on page 1-45, are a light shade of blue with a dark blue outline.

When I was experimenting with scanning the 48G series manuals, I found it difficult to find settings for my scanner that would show the blue clearly on my PC's display, and also print out clearly on my black and white printer.

Regards,
James

James,

Thank you for your detailed answer. I understand better now.

The french AUR is fully Black & White. The torus you refer to on page 1-45 is black and there are no grey shades.

Therefore, I'll scan it 300dpi BW...on my next free weekend, it's huge!

Thanks again and cheers from France.

Etienne