Spice series ROM self-test reverse-engineered Message #1 Posted by Eric Smith on 9 July 2004, 4:13 a.m.
I've mentioned here previously that on the Spice series (HP-3xE/C), the self-test uses a CPU instruction that reads an entire 1K block of ROM words (10 bits each, 10240 bits total) and computes some sort of check on it. Recently some email from Bill Weise prompted me to spend some time figuring out what exactly it is checking. The instruction seems to only provide a pass/fail result, and I'm not yet sure exactly how it indicates that.
Originally I thought it was probably computing a checksum, but I tried both a simple checksum and a checksum with end-around carry, and neither returned a constant value for every 1K block of ROM I've dumped.
Given that the calculator hardware works in an entirely bit-serial manner, it occurred to me that they might have implemented a CRC. Aside from guessing, I had no way to know what CRC polynomial they might use. I decided that the easiest way to find out would be to write a program that simply does a brute-force search by computing CRCs with all polynomials of orders 3 through 16 over two of the 1K*10 ROM page images. For any polynomials that compute the same CRC for both images, the program would then check the other images.
This program took about six minutes on an Athlon XP 1900+ system, and determined that the CRC polynomial is either CRC-10 (x^10 + x^9 + x^5 + x^4 + x + 1) or the reverse (x^10 + x^9 + x^6 + x^5 + x + 1). I'm not sure which because I find the definition of the CRC a bit confusing, since various references show the bits shifting in opposite directions, and the XOR happening on the input or the output side. But in any case, I now know how to verify a Spice ROM image.
More details including links to the code I wrote to do this may be found in my Advogato diary entry.
Presumably HP generated the ROMs by taking each 1K chunk of the assembler output (with one word of zeros reserved for the CRC, probably the last word), computing the CRC of first 1023 words, and storing it (or the complement?) in the 1024th word. A more complicated procedure would have been needed if they wanted to store the CRC in a word other than the last word.
I just realized that if the CRC word that needed to be stored in the ROM happened to be computed as 1060 octal, they wouldn't be able to use it, because that is the bank switch instruction, which is actually active even during the ROM selftest operation. So if the CRC did produce that value, they would have had to change the value of another word. Most of the time there was probably at least one more spare word in a 1K bank that they could tweak for this purpose.
I suspect that RAM write instructions are also live during the ROM selftest operation; there would have been little reason to make the RAM chips smart enough to detect the beginning and end of the selftest operation and disable writes. The logic would have been complicated, and they do a destructive RAM test anyhow.
If they'd tried to use the Spice CPU in a calculator with a printer, card reader, etc., they would have had to put some logic in the controller for those devices to prevent them from responding to ROM words read during the selftest that happen to be device control instructions. That may be one reason why they did not switch to the Spice CPU for later production HP-67 and HP-97 machines. That might also be why they removed the ROM self-test CPU instruction from the Nut CPU as used in the HP-41 and Voyager series.
On some of the Saturn-based calculators, they did add CRC hardware which is used for the ROM selftest (and for other purposes on the graphing calcs), but it operates under software control rather than as an automatic block CRC.
|