Threaded Mode | Linear Mode

Christoph Giesselink · 11-27-2017, 05:58 PM

(11-23-2017 06:31 PM)hth Wrote: I have implemented a couple of HP-IL routines to read and write a page to and from 41CL physical memory.

HP uses checksums in their files and an leaning towards doing the same. In that case it would seem most logical to use CRC32 as is done by the YCRC command.

But why are there checksums, and are they needed today?
HP-IL passes messages around and it is strongly recommended practise to verify the data when the frame comes back. Thus, the HP-IL protocol should not introduce any errors. I suppose the reason for checksums was that the magnetic tapes used were not entirely reliable/trusted and detecting a problem would be a good thing to ensure data integrity.

So, is this needed today? If people still use old storage media, then probably yes. For PILBox simulation, maybe not? On the other hand, it would be consistent with existing routines to have a checksum.

So I am pondering over if a CRC32 checksum should be written or not (or something simpler), what do you think?

Håkan

Some thoughts about checksums and CRC in connection with HP calculators. I have some experiences with all Saturn based calculators beginning with the HP-71B until the HP-49G.

The cheapest way to detect memory modifications is building a checksum. A checksum is easy to create but has the disadvantage that error detection only works for small memory blocks. Better are CRC's. But CRC needs more CPU power to calculate, moreover the Saturn CPU core don't have the necessary XOR opcode for a fast generation and so this opcode must be rebuild by the AND, OR and NOT operations. This makes it quite hard to write a CRC generator by software. The later Saturnator core in the HP-49G+ and HP50G has the XOR opcode and also of the course the base ARM CPU core.

Because of this, all calculators with the Saturn 1LF2 and 1LK7 CPU use checksums in ROM to verify the proper working of the ROM's during the production process and later in post production for service request.

Calculators with the separate 1LF2 and 1LK7 Saturn are the HP-71B, HP-18C and HP-28C. With the beginning of the Pioneer series, HP used the Saturn CPU only as core component in a multifunction chip containing timers, crystal oscillators, display controller, ...

Therefore HP build HP three chips, the 1LR2 Lewis for the High-End Pioneers with the dot-matrix display, the tinier sister 1LR3 Sacajawea for the Mid-Range Pioneers with the combination of dot-matrix sgements with classic annunciators and finally the 1LU7 Bert for the Low-Range Pioneers with 7 segment display. Because of the larger ROM, HP decided to add a CRC16 hardware generator to the 1LR2 and 1LR3 peripheral. The CRC register in the I/O area is updated on every memory read cycle with the exception reading an address in the I/O area. So HP protected the ROM content now with a CRC instead of a checksum. Only the 1LU7 Bert has no hardware CRC, and so the 10KB of ROM are still protected by checksums.

The next calculator generation, the HP48 with the 1LT8 Clarke and with the Yorke chip had the possibility of data exchange over a serial RS232C interface. For some for me unknown reasons, HP decided to use the Kermit protocol for a secure data exchange. The Kermit protocol needs a CRC16, but different to the one used by the prior Lewis and Sacajawea chip. So the developers of the Clarke chip replaced the generator polynom to the one used by Kermit. The ROM has still CRC's to check the integrity of the ROM content during production and post production for service purpose. Further some RPL objects in RAM contain also a CRC to verify the integrity of the RAM content.

In connection with the HP-49G you sometimes may read something about XMODEM with HP-CRC. XMODEM itself is a small data transfer protocol with less overhead. 128 byte data blocks must be protected by 8bit checksum or a CRC16, the CRC16 is recommended. The CRC16 is mandatory for 1024 byte blocks. But the CRC16 generator polynom of Kermit and XMODEM/YMODEM are different, so HP decided to use the XMODEM protocol but with the Kermit CRC16 generator polynom. So a standard terminal program with XMODEM send/receive possibilties will _not_ work in connection with the Flash-ROM update using the "HP-CRC".

Last rhetorical question, how do you verify data transfers on HP-IL when the controller is listener and one device is talker? The controller is initiating the transfer with a SDA and the talker device respond with the first data byte. In the next step the controller send the received data byte as request for the next data byte until the controller receive an EOT data frame. So the received data is definitely different from the send one, so the controller has no change to verity the received data for correctness. So any verification of data correctness must be done by the data management itself.

Christoph