The HP-71 and the Ubiquitous Binary File

[Dave Frederickson]

The Binary file. With regard to the HP-71 and it's emulators it's been used to identify ROM, IRAM, and LIF disc images. Sometimes it's more convenient to have a ROM or IRAM image in the other form. Here's how to convert between formats.

An IRAM image can be distinguished by examining the first 4 bytes of the file. If the bytes are "3BDDDDED", the Stand Alone Module ID, or "IRAM Identifier", then the image is for an IRAM or EPROM. Anything else and it's a ROM image. Also, if you run TITANCHK on an image file and it fails then it's likely an IRAM image.

IRAM's have one checksum as the last byte in the image. ROM's have one checksum per 16k ROM chip. The first 16k chip has it's checksum in the fourth byte and the last 16k chip has it's checksum in the last byte. Refer to the ROMCOPY docs for the location of the checksums in 48k and 64k ROMs.

To convert a ROM image to an IRAM image is simple. Change the first four bytes to "3BDDDDED" using a hex editor. The checksum is optional however it can be generated using the CMT TOOLS for burning EPROM's.

To convert an IRAM image to a ROM image requires generation of the checksum(s).

1. With a hex editor, change the first four bytes of the image to "000000FE" and if it's a 32k image the last byte to "FE".

2. Run TITANCHK on the modified image. For example, suppose we want to change the MATH 2B5 IRAM image to a ROM image.

Code:

C:\math2b5> titanchk MATH2B5.BIN
TITAN ROM Test V1.10
Unpacking data...
ROM Chip 1 = 70 -> Fail
ROM Chip 2 = 06 -> Fail
Checksum Error!

3. Invert the bits in the two calculated checksums. This is also known as the 1's complement. For the first chip the complement of 70 is 8F and for 06 it's F9.

4. Using the hex editor, change the checksum for the first chip to 8F (the fourth byte) and the checksum for the last chip to F9 (the last byte).

5. Rerun TITANCHK.

Code:

C:\math2b5> titanchk MATH2B5.BIN
TITAN ROM Test V1.10
Unpacking data...
ROM Chip 1 = 01 -> Ok
ROM Chip 2 = 01 -> Ok
Checksum(s) ok!

You now have a ROM image that can be loaded into Emu71 as a ROM or into FRAM71 using ROMCOPY.

[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

[Christoph Giesselink]

(08-15-2020 04:19 PM)J-F Garnier Wrote:  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.

I don't agree with this. IMHO a single 1 byte checksum over a size of 32KB or more makes no sense in my eyes any more. The risk of multiple errors resulting into a correct checksum grows with the size of the checksum area.

Just think about transfer protocols. One of the easiest ones is the X-Modem protocol with a block size of 128 byte. With a block size of 128 bytes you can protect the data block using an 8 bit checksum or a 16 bit CRC. The 16 bit CRC should be prefered by the receiver. When you use X-Modem-1K with a block size of 1024 bytes, the use of the 16 bit CRC is mandatory.

So lets have a look back into the HP calculator world end of 80'ies. The next calculator generation, still without a CRC generator, is the 18C and 28C. Here a 32KB ROM block is protected by a 16 bit checksum. Using checksums in the Saturn CPU family ended with the Low End Pioneer series calculators with the 1LU7 Bert chip. There for the 10KB ROM a 16bit checksum is used. All others and later ones used one or more 16 bit CRC's.

There's one exception, I found no protection in the HP39/40 ROM. A self test on this calculator shows no result of a ROM check and even more, changing larger parts of the ROM, don't bother the self test. The HP49G is better in this case, here I know that the 1st 32KB containing the BOOT block has no CRC. All other Flash pages use CRC's also the objects in the Port2 memory.

[Dave Frederickson]

(08-15-2020 04:19 PM)J-F Garnier Wrote:  So (from my point of view), the presence [or] not of the IRAM identifier (the first 8 nibbles) is not a good criteria to identify a ROM image.

That contradicts the IDS.

3.6.2 Stand Alone Module ID
The Stand Alone Module ID field is used to distinguish an Independent RAM from other forms of memory modules. For Independent RAMs, this field has the hex value B3DDDDDE. For ROMs and all other forms of memory modules, this field may have any value except the IRAM value.

So the IDS explicitly states that a ROM may not have the Stand Alone Module ID although I suspect that is only for checksum purposes.

Regarding ROMCOPY, this program is intended for creating ROM images from an IRAM. When the image is created ROMCOPY generates the checksums and places them in the image as specified in the ROMCOPY doc. For IRAM and EPROM images the CMT TOOLS include a variation of ROMCOPY called EPRMCPY. The difference is EPRMCPY doesn't remove the Stand Alone Module ID nor add checksums when creating an image.

If you consider images with the Stand Alone Module ID to be ROM images then those images will FAIL TitanChk and the Service Module ROM test. Rather, following the IDS breaks nothing.

Dave

[J-F Garnier]

(08-15-2020 06:52 PM)Christoph Giesselink Wrote:  

(08-15-2020 04:19 PM)J-F Garnier Wrote:  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.

I don't agree with this. IMHO a single 1 byte checksum over a size of 32KB or more makes no sense in my eyes any more. The risk of multiple errors resulting into a correct checksum grows with the size of the checksum area.

I don't agree with your point either :-) 32kB or even 64KB doesn't make a big difference vs 16KB.
The risk of multiple errors resulting into a correct checksum grows with the number of errors, not the checksum area.
A single byte fault will always be detected and the chance of a double random byte fault to still produce the same sum is 1/256.
It also depends on the failure modes: is the main failure mode a single bit error, a full nibble or byte random change, or a large memory area read as zero or FF?

J-F