HP Forums
Connecting a HP48 for data exchange - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: Articles Forum (/forum-14.html)
+--- Thread: Connecting a HP48 for data exchange (/thread-19709.html)

Connecting a HP48 for data exchange - Christoph Giesselink - 03-23-2023 11:02 PM

Connecting a HP48
  1. Hardware
    The HP48 and the hardware relatives HP38G, HP39G, HP40G and HP49G have a RS-232C port for connecting them with a PC or other hardware extensions. Meanwhile a RS-232C port on a PC is legacy, so a USB to RS-232C adapter cable will help in most cases. Having a Desktop-PC you may consider using a RS-232C PCI card. The serial port on these cards is sometimes better then the USB solutions and will help in connection with difficult external hardware expecting a +/-12V signal level.
  2. Software protocols
    The main software protocol of the HP48 S-series calculator for communication is the Kermit protocol. To support this, HP changed the polynomial of the hardware CRC generator to the one used by the Kermit protocol to support Kermit packets with the CRC instead of a checksum.

    The major problem of the Kermit implementation inside the HP48 and successors is the communication speed. I'm not talking about the serial baud rate of 9600 baud, I'm talking about the software implementation in SystemRPL. The complete Kermit protocol, with the exception of some low level functions accessing the hardware registers, is written in SystemRPL. SystemRPL programs, comparing to CPU binary code, are as interpreter language very slow and have the disadvantage of garbage collection from time to time.

    Just for example, creating a backup archive with a size of 128KB on a HP48SX over the Kermit protocol takes more than 30 min. Using the XModem protocol, implemented in assembler, on the same calculator takes about 3 min. So HP added a XModem XSEND and XRECV command in the HP48 G-series calculators.
  3. XSEND and Emu48
    There's an emulation speed issue on fast host platforms in connection with Emu48 and the XSEND command and related software using the same code (i.e. HP38G and HP48 ROM Upload programs). Use the "Authentic Calculator Speed" mode as workaround. Emu48 v1.66 and Emu48+ v1.65 will fix this without the need of the manual slow down.
  4. Protocol error detection
    The XModem protocol, like the Kermit protocol, supports two ways of transfer error detection, the checksum or the CRC method. HP implemented the Kermit CRC polynomial at the HP48 in hardware, so building a Kermit packet with CRC can be done easily and fast. The XModem protocol use a different CRC polonium, so the XModem CRC must be calculated manually. The easier way is using the checksum method. So the HP48 G-series calculators support the XModem protocol, but only with the checksum method.

    There's a variant of the XModem protocol, XModem-1K. In difference to XModem with a packet size of 128 bytes, XModem-1K use a packet size of 1024 byte. With XModem you have the choice of using the checksum or CRC method, with the fallback on checksum, for error detection. For XModem-1K using the CRC method is mandatory.

    HP had a problem with the HP49G firmware update over the serial port. They wanted to use the XModem-1K protocol for fast transfer but had only a hardware CRC generator with the wrong CRC polynomial for the Kermit protocol. The solution of HP was using the XModem-1K protocol with the Kermit-CRC and called this "XModem-1K with HP-CRC".

    In summer 2022 I wrote a XModem and XModem-1K implementation on the HP48 with CRC, also like 3rd party developers made this decades earlier, with no speed difference on a HP48SX to the checksum method. It was a little bit tricky, because most fast CRC generator functions using a table and the Boolean logic operator Exclusive OR (XOR), which is not implemented in the Saturn CPU core hardware. Therefore the XOR operator has to rebuild by software.
  5. Terminal Program on the PC
    After we talked about different software protocols on the calculator, we have to change our view to the software on the (Windows-)PC.

    Old DOS software from the good old times could not be executed without assistance on a x64 Windows any more, so I had a look for a terminal software supporting
    • the legacy RS-232C port
    • Kermit protocol
    • XModem protocol
    • XModem-1K protocol
    • YModem protocol

    running on Windows10 or later.

    Until Windows XP the program Hyperterminal from Hilgraeve Inc. was part of the Windows distribution and fulfill the points from above. It's not freely available any more. The program delivered with WinXP still work with some restrictions the later Windows versions, but I was looking for a free alternative.

    The only free alternative I found was Tera Term. Since the last couple of month I played with the latest release 4.106. XModem transfers in both directions and Kermit transfers as Sender had been working, but Kermit as Server on the PC completely failed. I first recognized this using Emu48 and verified with a real HP48SX later.

    So I began analysing the Kermit packets and recognized that it seem to be a problem of Tera Term.

    I quick test with Tera Term 5.0 beta 1 on Windows 10 showed, indeed it's an issue of release 4.106. With release 5.0 beta 1 the transfer to the Kermit server was working fine. I made no further investigation.
  6. Why sometimes Kermit?
    Why the Kermit protocol is still so important? The easiest way to get a backup of the HP48 main memory is using the ARCHIVE command. The destination of the ARCHIVE command can be an independent port with the limitation of 128KB or the serial port with a Kermit server as receiver.