The HP38G has two means of communicating with the outside world, infra-red and serial. The IR is used for communication between two HP38's and the serial is used for communication with a computer or disk drive. This page describes the protocol and file formats used by the HP38.
The HP38 uses a slightly modified version of the Xmodem protocol for IR communications. It is compatible with the IR on the HP48.
You can successfully transfer single part objects from the 38 to the 48 using the built-in XRECV command on the 48. But you have to use my modified XSEND to send them back to the 38. You cannot currently transfer multipart objects (i.e., most Aplets) via IR between the 48 and 38, but I intend to write a modified Xmodem suite for the 48 that allows this.
If you try to transfer a multipart object to the 48 using the built in XRECV, you will only get the first part, which is a list of the names
All objects transfered via IR are transfered in binary mode.
The 10-pin connector on the back of the HP38 is used for serial communication and for communication with an overhead unit. The layout of the serial pins is rather simple -- it turns out that the lower left four pins have the exact same layout as the pins on the HP48.
The 38 uses the Kermit protocol over the serial line. The speed is 9600 baud and the computer must be set in server mode. At the beginning of a session the HP38 will fetch a file called HP38DIR.000. This file contains a table of HP38 object names and 8+3 file names.
Aplets are stored in multiple pieces on the PC. When you tell the HP38 to fetch the main piece of the Aplet it automatically transfers all of the pieces. Objects are transfered in ASCII mode whenever possible.
All Objects start with the string `HP38' followed by either `Bin' or `Asc' and a single character denoting the type of object in the file. Following this character is the name of the object in the file. In binary mode, this name is in the format of the body of an identifier object; that is, one byte specifying the length and then that number of bytes containing the name of the object. In ASCII mode this is stored as a space, an ASCII integer specifying length, another space, and then the ASCII string of the name.
| Byte | Usage |
|---|---|
| A | Used for the HP38DIR.000 |
| B | Binary Aplet data |
| C | Notes sent as character strings |
| D | User programs |
| E | List and Matrix objects |
| I | An `Index' of an Aplet - used in IR transfers |
If you transfer a few objects via IR (hence in binary mode), then you will see that the HP38 uses the same prolog addresses for objects as the HP48 does.
The type `B' object, which is used for binary Aplet data is the most complicated object transfered by the HP38. The prolog indicates that it is an RPL RRP (RAM-ROM Pair) object -- an RPL directory. Here is an empty solve Aplet decompiled by an RPL unthreader program I modified to work with HP38 objects.
All of the entries in the directory are unnamed, suggesting that they have to be in a particular order.
The first entry is a LIST of XLIB references. Then a bunch of real numbers follow. The first four are Xmin, Xmax, Ymin, Ymax respectively and the string nearest the end is the Note attached to the Aplet. You can figure out most of the rest by playing with variables on the HP38, downloading the changed Aplet and decompiling...more info to come later.
Notes are sent as character string objects with a header indicating type `C'.
User programs are also sent as character strings, but are marked as type `D'. When sent in ASCII mode the special characters are translated like in translation mode 3 on the HP48. This makes it possible to compose user programs on the PC and upload them to the HP38.
List and Matricies are marked as type `E' and sent as List and Array objects respectively.
These objects, marked as type `I' are only sent in IR transfers, as the first piece of a multipart object. The name field, which always follows the object type byte is always empty for a type `I' object. The body is a List object containing a Identifier, giving the name of the Aplet, and a bunch of strings, naming the pieces to follow.
This was written by Steve Dunham <dunham@gdl.msu.edu>. It is provided without warranty, etc.