www.HPComm.org development

HPComm is a free program which allows you to transfer data between a PC, and HP graphing calculators. The latest released version of HPComm is HPComm 3.0r4. The latest version of HPComm38 (which works with the HP38G, HP39G and HP40G calculators) is 1.0r4.

As per the HPComm front page, this program is no longer under development.

The old development page

For what it's worth, the old development page is here.

Windows developers

One big problem with HPComm is that the Windows Explorer emulation is done by our code. It's very hard to do and still isn't right. For instance, HPComm doesn't react when some other Windows program changes files stored on the computer.

An alternative (and potentially easier) way to implement HPComm is using "Shell Extensions". A shell extension fits into the Windows OS and works seamlessly with the rest of the operating system. You can find out more about shell extensions here.

This wouldn't involve starting from scratch however. HPComm is currently implemented with a filesystem abstraction layer, one for the calculator filesystem, and one for the PC. After adding an event handling mechanism to these abstraction layers, a shell extension would work quite well.

Any takers?

Linux developers

Also, someone might find some of these ideas about transfer protocols useful:

Subject: Re: hp49g and linux
   Date: Mon, 8 Oct 2001 10:30:05 +0200 (METDST)
   From: Alen Kovac <akovac@student.math.hr>
     To: mjd@alphalink.com.au

Hi!

Thanks for respond.

> > Kermit is a really nasty protocol and needs a lot of work to implement it
> > from scratch. A good idea would probably be to let the *nix command-line
> > program C-Kermit (http://www.columbia.edu/kermit/ckermit.html) do all the
> > kermit stuff for you...
> 
> That's not a bad idea.  A two-pipe approach could be used.

Yes, that's how I implemented library, I'm running C-Kermit in pseudo tty.
It works fine.

> > The Kermit implementation of HPComm is spoiled with Win32 code (to
> > communicate with the progress window etc.). But you could try to wipe that
> > stuff out of it.
> James and I did some work on trying to insulate the
> GUI code from the comms code.  Not entirely successful
> though.  As James says, Kermit is not pretty.  Also,
> there are quite a number of limitations on the Kermit
> server in the calculator, which means HPComm has to have
> pretty nasty workarounds.

My library is gui independent, callback system is implemented for
GUI update stuff.

> > > As well as speaking Kermit, the HP49G speaks a protocol
> > > based around XMODEM.  The HP guys made this very powerful,
> > > and if HPComm or a similar program was rewritten to
> > > support the use of XMODEM, it would be insanely fast
> > > with the HP49G.
> > 
> > Regarding XModem...
> > HP uses a special protocol to communicate with the calculator (i.e. to get
> > the file listing from the calc etc.). And guess what... Yes. This protocol
> > is not publicly available (afaik) :-(
> > You may try to put some pressure on the guys of HP that they release their
> > protocol specifications!
> 
> Since I used to work with these guys, and it was their
> intention to release the protocol, if you're serious,
> I'm sure I can get the protocol.

That would be very nice, since Kermit is a bit to slow.
There are some problems with transfering files, transfer rate
lowers down rapidly.

Best regards,
 Alen Kovac

Come on, who's the best coder??? :-)

Mitch Davis Jean-Pierre Bergamin Colin Croft