Any fast data exchange between any of HP48GX , HP49G and PC ?



#12

Mar 08 , 2004


Thanks to a most appreciated advice given by James M. Prange ( Re: 49g memory dump, James M. Prange - 3 Mar 2004, 5:22 p.m. ) , I just recently went to the " http://etud.epita.fr/~avenar_j/hp/49.html " page to update my HP49G with its current flash-rom software Beta version #1.19-6 .

As I only knew and used " KERMIT " earlier , I also downloaded the recommended " HP Graphing Calculator PC Connectivity Kit 3.0, also known as HPComm 3.0. " software .

First excellent surprise : the data automatically transferred at an - impressive !!! - rate of 1K bytes / second through the " Xmodem 1K-HPCRC " protocol which had become automatically selected . :-)))

Second surprise , not so good : when afterwards attempting to load additionnal data from PC to HP49G , using the same " HPComm 3.0. " software I could not select again in any way the magic " Xmodem 1K-HPCRC protocol " , and I had to revert to old faithful , nevertheless very slow KERMIT protocol !!! :-(((

Would any of you kindly tell me what are the currently available fastest Transfer protocols to exchange data between any of the HP48GX , HP49G and PC . The 1KB/s observed with the Xmodem 1K-HPCRC protocol would correctly fit all my needs . Obviously between HP48GX's , I can use IR - it is quite slow and power consuming - but I also have all connection kits between any of these .


Thnaks in advance from another " Kermit " :-)


Antoine M. " Kermit " Couëtte

antoine.m.couette@club-internet.fr


#13

I'm not sure of understanding you... do you like Xmodem? If so, I ever conect my calculator with my virtual calculator: emu48. Never use HPComm.
Select Xmodem in "both" calcs.


#14

Hi Raul ,


Thank you very much for your time and efforts in trying to understand me .


Yes , I liked the Xmodem protocol because of its speed which I just discovered when loading the flashrom update into my HP49G .

I did not know until then that such 1Kb/second transfer rates are achievable because I earlier kept using a very simple version of the KERMIT protocol .

So , after this " high speed " discovery , I wanted to get again such a 1Kb/second transfer rate for all my future uses . Unfortunately I was not able to select the X modem protocol again when using HPComm 3.0. to transfer additionnal and different files into HP49G .


What I need is being able to use X modem itself or ANY kind of equivalent software which enables BOTH WAYS data transfers at a rate of 1 Kb/sec - or better if it exists - between any of the following HP48GX , HP49G and PC .

Kermit

antoine.m.couette@club-internet.fr


#15

Well, as I said, I alwais use kermit in transfers between the 48GX and the PC (emu48). Just use XSEND nad XRCCV, instead SEND and RCV.
Let me know if you get what you want

Also, read this recent post of James M. Prange

Raul

Edited: 9 Mar 2004, 2:18 a.m.

#16

Use Conn4x from HP

http://h20015.www2.hp.com/en/softwareDownloadIndex.jhtml?reg=&cc=us&softitem=ca-14082-5&prodId=hp49ggraph351775&lc=en&plc=&sw_lang=en&pagetype=software

Olivier

#17

Regarding the 49G revision 1.19-6 ROM, I gather that HP (management)
decided that revision 1.18 was "good enough", and that no more time and
money should be "wasted" on it, but the developers wanted to do more, so
continued with unsupported revisions on their own time, hence the "beta"
designation and refusal of official "HP Support" to deal with the
unsupported releases. I can't help wondering whether that had something
to do with closing down ACO. But in any case, I think that 1.19-6 has
very worthwhile improvements over the "supported" ROM. For any problems
with 1.19-6, ask at comp.sys.hp48 or, if it seems to be a genuine bug or
for enhancement requests, post at http://bugs.hpcalc.org/. I
understand that development for the 49G has progressed beyond 1.19-6,
but that HP has prevented the release of any newer revisions on
"intellectual property" grounds. Maybe someday....

As for the "Xmodem 1K-HPCRC protocol", I don't know that it's used
except for downloading a ROM, but perhaps a search at
http://groups.google.com/advanced_group_search?group=comp.sys.hp48 might
reveal more information.

As Raul recommmended, except for use with the 48SX/S, use the Conn4x
application now, and use the latest revision (Version 2.2 Build 2348 for
Conn4x and, for the 49g+, USB driver revision 1.2, and ROM revision 1.23
Build 31, at my last check). These have some very nice enhancements and
important bug fixes over the ones that came on the CD-ROM with my 49g+,
and I'm now happier with Conn4x than with any other communications
package that I've tried. Also note that any new files seem to show up a
few days earlier on HP's "Business Support" pages than on their
"Customer Care" pages. For the 48G series, install the XSrvr library
that comes with Conn4x; it makes things much easier. But as the
instructions say, install the library in port 0 or 1. I found out
experimentally that if installed in port 2 (and presumably higher), it
hangs the calculator when I try using Conn4x, requiring a "paperclip
reset" to force a warmstart, and leaving an unacknowledged alarm
warning, flag changes, and last command lines and stack saves disabled
(although not a TTRM, and the home directory seems to be uncorrupted). I
recommend that you "don't try this at home".

Conn4x uses the Xmodem protocol, which isn't built-in to the 48SX/S, so
doesn't work with them. I don't know of an Xmodem application for the
48SX/S, but there might be. Otherwise, use the Kermit protocol.

Conn4x does have a "text" transfer option with various translation
options for decompiled objects, similar to an HP calculator Kermit protocol
"ASCII" transfer, and compatible with the Kermit "ASCII" transfer
files, except that for the characters "NUL" (character 0, the "null
character"), """ (character 34, the double quotation mark), and "\"
(character 92), the translations differ; see the Conn4x help file. Conn4x adds the option of translating control codes 0-9, 11-31, and 127 to the "\nnn" codes (independently of the other translation options), the LF (character 10) to CR LF (characters 13 10) pair translation can be disabled independently, and where the Kermit translations always left a CR LF pair untranslated for outgoing transfers, so a tranfer back to the calculator (with any non-zero translation option) changed it to just LF, Conn4x (with LF translations enabled) translates CR LF to CR CR LF, so it's CR LF again when transferred back to the calculator (as long as your text editor hasn't made it's own "End Of Line" translations to it based on the extra CR, which can be avoided by leaving the translate control codes option enabled).

Conn4x also has a "Calculator Commands" window, so you can run the calculator from the PC, similar to the Kermit Remote Host commands. And an "Edit as text" option that uses your PC's text editor (NotePad by default, but you can set it to use your preferred editor) and a file in the PC's %TEMP% directory, sending the changes to the calculator only if you actually save the file on the PC. "Edit as text" may be preferable to the calculator's command line editor in some situations.

Note that the 49 series, unlike the 48 series, decompiles "NUL", """, and "\"
characters to "\00", "\"", and "\\"; an improvement for use on a 49
only, but a 48 series doesn't "understand" that new rules should apply
for compiling these sequences, so they cause problems for 49 series to
48 series transfers. Going the other way isn't quite so bad because
either calculator compiles a literal "NUL" unchanged and the 49 series
understands the counted string form that the 48 series uses when a """
is embedded in a string; the only problem (with these characters) for a
48 to 49 transfer is that a 49 compiles (unless it's within a counted
string) a "\" (not immediately followed by "00", """, or another "\") to
""; that is, it simply discards it. Note that with ROMs prior to 1.19-6,
the 49G incorrectly compiles "\00" to "00" instead of "NUL".

Also note that "binary" transfers between a 48 series and a 49 series
are rejected, and for good reason; they could very well cause a crash or
memory loss if you fooled the calculator into storing an incompatible
compiled object. Well, not completely rejected, but the entire incoming data stream (including the binary transfer header) is stored as a character string object, instead of extracting the compiled object and storing it as such.

A work-around for the problem of transferring an object an that contains
these characters between a 49 and a 48 is as follows. If the object
isn't already a character string (the string with these characters could
be an element of a list or program), first, to assure full precision of
real numbers and user binary integers, do STD and 64 STWS, and to avoid
any angular components being compiled using a different angular unit
(Degrees, Radians, or Gradians), execute RECT. Then do \->STR to
decompile the object to it's string form (this could, except for the
RECT command, be done with a single SysRPL command instead), and store
it as a named variable (a local variable is better, if you care to
automate the process with a program). Be sure that the fraction mark (.
or ,) is the same on both calculators. Now, set both calculators for
binary transfers, and make the transfer, using either Kermit or Xmodem,
and for that matter, either directly or by using a PC as a go-between.
The object arrives with a non-compatible binary transfer header, so the
calculator doesn't attempt to store it as the compiled object; it just
stores the entire data stream as a character string, with the original compiled character string embedded within it. Recall the string
to the stack. It starts with the 8-character binary transfer header,
followed by a 5-nibble character string prologue, followed by a 5-nibble
size field (13 characters so far), followed by the characters in the
original string. Extract everything after the first 13 characters by
doing 14 OVER SIZE SUB to get the original string, then, if the object
wasn't originally a string, do STR\-> to compile the string to the
original object, and then store it in the variable of your choice.

Other problems are that integer valued type 0 "real" numbers from a 48
may be compiled as type 28 "exact integers" on a 49 because they lack
the decimal point used on 49 series real numbers; just set the 49 to
approximate mode to avoid this. Of course, the 48 doesn't have exact
integers, so if it gets one from a 49, it's compiled as a real and, if
more than 12 digits, rounded to 12 significant digits. When doing an
"ASCII" or "text" transfer of a PC file to a 49, have the 49 in exact
mode to avoid changing exact integers to real numbers. Other new object
types on the 49, such as type 29 "symbolic" vectors/matrices, will
result in a syntax error on the 48. The 49's new command names will be
compiled as global names on the 48, and if a global name from the 48
happens to match a new command name on the 49, then it will be compiled
accordingly. I suppose that a transfer with a name that matches a
command would be rejected, but in any case, a name compiled to a
different object type within a composite (list, program, or algebraic)
will cause "unexpected behaviour".

The IR communication between 48 series models is indeed slow; only 2400
bits per second is built-in, although I understand that it can be
"tweaked" higher by adding some applications. And IR does take more
power than "via wire" communications too. Note that IR communications are half-duplex (to avoid reflections being treated as incoming data), so XON/XOFF flow control (useful for raw "serial I/O" communication, but not needed for Kermit or Xmodem) isn't available. But you can hook up wired
connections between 48 series, and between a 48 and the 49G, at 9600
bps. Between two 49Gs, you can also use that oddball 15360 bps speed. Note that on the 49G, XON/XOFF flow control doesn't work, although it's intentional removal is undocumented.
For small transfers, IR is ok, but for larger transfers, I do it via
wire. Of course, the 49G lacks IR, so transfers or printing via IR isn't an option with it.

The 49g+ lacks RS-232 style I/O, so a wire connection works only to a
USB host with the 49g+ USB driver installed. The 49g+ IR is IrDA instead
of "Serial IR", so it doesn't work with the 48 series. I don't have an
IrDA to RS-232 adapter, but I've read that they work just fine. But for
anything except connecting to a PC or other device that can supply power
from a non-data line, be sure to get one that can accept external power
from a battery or AC adapter, and one that doesn't require a device
driver (see http://www.actisys.com/instantir.html for the only example that I'm aware of). I don't know what kind of range you can expect with the 49g+ for
IrDA communications.

The 49g+ does print via IR in the "Red-Eye" protocol required by the
82240A/B (and, I think, some other) HP printers, but the range is
drastically reduced to 2 or 3 inches. If you care to spend some money,
I've read that the Martel printers that accept the "HP IR" protocol work
with the 49g+ as well as the 48 series, although I'd guess with the same
reduced range; see http://www.martelinstruments.com/cased.html.

Regards,
James


Edited: 9 Mar 2004, 8:02 a.m. after one or more responses were posted


#18

James,
I tried to set up Conn4x for communication with my 48gx about a month ago. Since my port 1 and port 2 are full, and I don't like to use port 0 since it takes away from ram, I loaded the required library in port 3. The results were as you described above and in your comp.sys.hp48 post on the subject. To my very un-expert eyes, the calculator was just not working correctly. The paperclip reset would wake it up, but the display seemed "flickery" or tentative, pressing VAR had no effect, and responses to other key presses seemed sluggish. After a few minutes of worrying that I had somehow ruined by gx, I gave it what I believe is referred to as the "three fingered salute", ON-A-F, and said "NO" when it asked if I wanted to try to recover memory. Luckily, with a bunch of empty ports in a 1 meg ram card, I do occasionally create a backup, so I was able to restore things with no real loss. Still it would have been nice if there had been a stern warning with the Conn4x instructions to not use anything other than port 0 or 1.


#19

Thanks for the information. Your experience seems to have been worse than mine. On mine, it did seem to require more time than usual to return from the warmstart, and flashed extra lines and annunciators at first, but seems to be working ok now. All the more reason for "Don't try this at home", and yet another reason for making backups. You never know when an added library, or SysRPL or assembly languange program might cause really serious problems.

Regards,
James

Edited: 9 Mar 2004, 8:19 a.m.

#20

Mar 09 , 2004

Many thanks to you all , Raul Lion , Olivier De Smet , James M. Prange - second time at least you help me here , James !!! -:))) - and Jeff for all the time you took giving me a careful , detailed and comprehensive reply .


As for Raul's suggestion about linking HP48GX to Emu48 , I will take a close look at it as soon as I have Emu48 installed .

I am in the very same situation as Jeff since I use high priority applications which require the 2 ports 0/1 . After studying the documentation about the Conn4x software Olivier had earlier pointed out to my attention , I have decided to avoid it since it cannot be installed outside Ports 0/1 .

I am going to take a careful and more indepth look at the various links James indicated .

Apart from the example of the HP49G Flashrom " fast " update which I discovered by accident a few days ago , it looks like - for the time being - there is no widely recognized software with limited constraints - i.e. which can be started from any port and with a reasonable size - enabling direct Data tranfers at a " fast " rate - i.e. 1Kb/s or higher - between PC , HP48GX and HP49G ( I do not own a 49G+ ) .

Thank you again to you all ,


Kermit


#21

Suit yourself, but note that Conn4x (and other Xmodem applications) can
still work with the 48G series without the XSrvr library by using the
built-in XSEND and XRECV commands, although I expect that many Conn4X
features would be unavailable; I suppose that it would work for the very
basic "binary" transfers only. The Kermit based HPComm, with the
available "ASCII" transfer mode, may indeed be preferable.

The 49G has the Xmodem server built-in, so has no need for the added
library. I recommend that you try Conn4x for use with the 49G at least, even if not for the 48G series.

The XSrvr library takes up 3445 bytes from either port 0 or 1 on the 48G
series.

Regards,
James

#22

PS:

The Martel printers that are listed with "RS232" should also work with the 49G and 48 series (although with the "via wire" printing format) that way.

I don't know whether the 49g+ is capable of printing in IrDA mode as well as the "Red-Eye" mode, but if so, perhaps those listed with "IrDA Stack" and/or "IrDA Phys" might work for that.

Regards,
James


Possibly Related Threads...
Thread Author Replies Views Last Post
  A fast Bernoulli Number method for the HP Prime Namir 16 1,278 11-22-2013, 04:46 PM
Last Post: Namir
  Sheet data importer for HP Prime Marek Russ 4 476 11-15-2013, 04:55 AM
Last Post: debrouxl
  Entering,Saving,and Analysis /Fitting X Y Data on the Prime Harold A Climer 6 662 10-26-2013, 01:54 PM
Last Post: Tim Wessman
  HP PRIME: How to change the column headers and reset data Joseph Ec 5 546 10-18-2013, 02:26 PM
Last Post: Joseph Ec
  HP Prime data sharing Alberto Candel 5 547 10-06-2013, 07:49 PM
Last Post: Alberto Candel
  HP48GX screen replacement Francisco Quiles 9 835 10-03-2013, 09:17 PM
Last Post: Francisco Quiles
  HP48GX Interface to a PC John W Kercheval 7 656 09-29-2013, 10:53 AM
Last Post: John W Kercheval
  Printing HP 9825 data Norman Pillsbury 3 429 06-01-2013, 10:08 PM
Last Post: David Ramsey
  WP-34s data exchange with PC over IR Marcel Samek 3 396 02-26-2013, 11:53 PM
Last Post: Marcel Samek
  GROBs with hidden data in them... Chris Dreher 2 319 12-13-2012, 01:07 PM
Last Post: Chris Dreher

Forum Jump: