The HP-71 and the Ubiquitous Binary File

[J-F Garnier]

To continue the discussion:

The Stand Alone Module ID, or "IRAM Identifier" is not used by the HP-71 OS to distinguish an IRAM from a ROM, but to distinguish an IRAM from a RAM merged with the main RAM.
This is the only way the OS has, during configuration, to recognize an IRAM from a "merged" RAM. The ROMs are identified by hardware with the C=ID opcode and the OS doesn't look at the first nibbles in that case. They are just unused for ROM (except sometime one byte for the first checksum) and so are usually zero for genuine HP ROMs.

So (from my point of view), the presence of not of the IRAM identifier (the first 8 nibbles) is not a good criteria to identify a ROM image.

Actually, I found that using the IRAM identifier in ROM images is very convenient because you can easily change the module type from ROM to IRAM in Emu71/DOS or with the FRAM71.


Then, about the checksums:
The original HP ROM modules were made with 16kB ROM chips, so HP included a checksum in each chip. This checksum is only used by the test module (service module).
The position of the checksums varies from ROM to ROM:
The last checksum is usually the last byte of the ROM.
The other checksums are usually embedded in the ROM code, sometimes the first checksum is one of the unused first bytes of the ROM.
For instance, for the MATH ROM 1A, I found that the first checksum is at address x7129 (file jp2.a of the restored source files 1A).

Things are getting more complex with the user EPROM modules built from a IRAM port with ROMCOPY.
The ROMCOPY command does insert checksum bytes, but the HP document referenced by Dave here is not so clear regarding checksums.
My understanding is that ROMCOPY (without other checksum directives, for 32K ROM images) sets a checksum in the third byte (nibbles 6 and 7) for the first 16KB block and in the last byte at the end of the ROM image for the last 16kB ROM block.
But, when loading back a HP-71 ROM image in a IRAM port with ROMCOPY, the first checksum is lost because the 8-nibble IRAM identifier is restored by ROMCOPY, and it has to be otherwise the RAM would not be recognized as a IRAM by the system.
So I used to not trust the checksums generated by ROMCOPY.

The HHP and CMT 32K and 64K EPROM modules are using one logical chip (and a single EPROM actually) so the checksums of each 16KB block were no more really needed, and the CMT tools are using a single checksum byte that is simply the last byte of the EPROM.
I found this checksum scheme much better and simpler.

For building a ROM image for the Emu71 emulators, I use an IRAM port in Emu71/DOS, put the file(s) in it, generate the CMT unique checksum byte (at the end) with the PTGENC$ function (see the CMT tool documentation in the HP-71B compendium). The ROMCOPY is not involved, the 8-nibble IRAM header is unchanged and no 16kB checksums are generated.
This is similar to the programming of a CMT EPROM module with the CMT programmer: load the file(s) in the CMT programmer port, generate the checksum with PTGENC$, program the EPROM module.

Note, however, that the checksums are not used by the HP-71B OS, so the consequences of the choice of the checksum scheme are limited, actually you can just ignore them.

J-F