The Museum of HP Calculators

HP Forum Archive 16

[ Return to Index | Top of Index ]

HP-49G and HP-49g+
Message #1 Posted by Antonio Maschio (Italy) on 8 Dec 2006, 11:16 a.m.

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

      
Re: HP-49G and HP-49g+
Message #2 Posted by Ken Ratkevich on 8 Dec 2006, 12:57 p.m.,
in response to message #1 by Antonio Maschio (Italy)

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

      
Re: HP-49G and HP-49g+
Message #3 Posted by James M. Prange (Michigan) on 8 Dec 2006, 8:18 p.m.,
in response to message #1 by Antonio Maschio (Italy)

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

            
Re: HP-49G and HP-49g+
Message #4 Posted by Antonio Maschio (Italy) on 9 Dec 2006, 5:31 a.m.,
in response to message #3 by James M. Prange (Michigan)

Wow! I'm impressed! Thanks very much.

-- Antonio

            
To James: How'd you get so good?
Message #5 Posted by Ken Ratkevich on 9 Dec 2006, 7:16 a.m.,
in response to message #3 by James M. Prange (Michigan)

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

                  
Re: To James: How'd you get so good?
Message #6 Posted by Antonio Maschio (Italy) on 9 Dec 2006, 12:16 p.m.,
in response to message #5 by Ken Ratkevich

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

                        
Programs to move variable to port
Message #7 Posted by James M. Prange (Michigan) on 10 Dec 2006, 12:11 a.m.,
in response to message #6 by Antonio Maschio (Italy)

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.

                              
Re: Programs to move variable to port
Message #8 Posted by Antonio Maschio (Italy) on 10 Dec 2006, 11:16 a.m.,
in response to message #7 by James M. Prange (Michigan)

Very very very kind and clear.

As usual.

-- Antonio

                  
Re: To James: How'd you get so good?
Message #9 Posted by James M. Prange (Michigan) on 9 Dec 2006, 6:13 p.m.,
in response to message #5 by Ken Ratkevich

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

                        
Re: To James: How'd you get so good?
Message #10 Posted by Gerson W. Barbosa on 9 Dec 2006, 6:45 p.m.,
in response to message #9 by James M. Prange (Michigan)

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.

                              
Re: To James: How'd you get so good?
Message #11 Posted by Thor Lansen on 9 Dec 2006, 7:37 p.m.,
in response to message #10 by Gerson W. Barbosa

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

                                    
Thanks! (NT)
Message #12 Posted by Gerson W. Barbosa on 9 Dec 2006, 8:00 p.m.,
in response to message #11 by Thor Lansen

                                    
48G Series Advanced User's Guide
Message #13 Posted by James M. Prange (Michigan) on 9 Dec 2006, 11:42 p.m.,
in response to message #11 by Thor Lansen

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

                                          
Re: 48G Series Advanced User's Guide
Message #14 Posted by Etienne Victoria on 10 Dec 2006, 4:39 a.m.,
in response to message #13 by James M. Prange (Michigan)

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.

                                                
Re: 48G Series Advanced User's Guide
Message #15 Posted by James M. Prange (Michigan) on 10 Dec 2006, 3:34 p.m.,
in response to message #14 by Etienne Victoria

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

                                                      
Re: 48G Series Advanced User's Guide
Message #16 Posted by Etienne Victoria on 10 Dec 2006, 3:41 p.m.,
in response to message #15 by James M. Prange (Michigan)

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

                        
RPL information
Message #17 Posted by James M. Prange (Michigan) on 9 Dec 2006, 11:47 p.m.,
in response to message #9 by James M. Prange (Michigan)

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

[ Return to Index | Top of Index ]

Go back to the main exhibit hall