HP-41CV "HFF" ROM set

[Eric Smith]

For the first half of the product life of the HP-41CV, and the tail end of the product life of the HP-41C, the mainframe ROMs used were the "GFF" ROMs, which fixed most of the serious known bugs of earlier ROMs. Some of those bug fixes upset early synthetic programming fans, such as fixing "bug 2" which allowed program memory and status registers to be accessed by addresses that wrapped around, and "bug 3" which allowed altering system flags. Of course, other methods were developed for doing those things without reliance on bug 2 and bug 3.

Around late 1983, the HP-41CV changed to using the "HFF" ROM set. As far as I know, there is no published explanation of the difference between ROM 0 revisions G and H. Aside from the version number and checksum, there are two actual changes, at address range 01c9..01f3, and the single word at 081a. I haven't figured out the latter, but I've discovered what the 01c9 change does.

The HP-41 mainframe ROMs have code to support expansion ROMs using "buffers" of registers allocated in main RAM, just after the key assignments. The first register of a buffer contains two copies of the buffer number, used by an expansion ROM to identify the buffer it owns, and a buffer length which is used to locate the next buffer, or the end of the buffers.

There was a longstanding bug in the mainframe ROMs which would cause a hard lockup if the length of a buffer was mismarked as zero. The code to scan the buffers would sit in a tight loop looking at the same zero-length buffer forever. This situation could easily be caused by buggy synthetic programs. The ON-backspace trick wouldn't recover from this, because the buffer check happened before the ON-backspace check. Recovery generally requires removing the batteries until the RAM contents are lost.

The code change at 01c9 in the 0H ROM, and also the 0N ROM of the 41CX, fixes this bug! They reversed the order of the tests, so that the ON-backspace test is done before the buffer scan, so that it can avoid the zero-length buffer lockup.

It has been reported that the 41CV with HFF ROMs may have the "buzz mode" of the 41CX (PPCJ v10n9p24), but I don't have a 41CV with HFF ROMs so I can't confirm that.

Edited: 24 July 2011, 5:13 a.m.

[Håkan Thörngren]

Hmm, 081a changed to NOP (deleted, bug) in H ROM, what did it do before?

Quote:

---

Around late 1983, the HP-41CV changed to using the "HFF" ROM set. As far as I know, there is no published explanation of the difference between ROM 0 revisions G and H. Aside from the version number and checksum, there are two actual changes, at address range 01c9..01f3, and the single word at 081a. I haven't figured out the latter, but I've discovered what the 01c9 change does.

---

[Eric Smith]

I've been looking at the code, but I haven't puzzled it out yet.

[Håkan Thörngren]

I checked and understand. It is a bug. It used to increment the number of instructions in an XROM before checking if a given instruction number was in range.

If you have an instruction XROM i,j and look it up for execution, it will scan the ports for a module with ID i plugged in. Now if j is just one instruction beyond was is actually in the FAT, it will incorrectly think it found the instruction, take the FAT 0,0 trailer and build an execution address from it.

What it should do is keep looking for another module with the same ID i, but with more FAT entries. This is what happens in H ROM.

To take an example, if you look for XROM 10,30, it means you are looking for a module with at least 31 instructions (it starts with 0). So it starts scanning for XROM 10. When found it will load the number of instructions in the FAT. Say it is 30, meaning it has instructions 0-29. In H ROM it loads the instruction count and compare 30<30, so it is false and it will keep looking for another XROM 10 with more instructions.
In G ROM it increments the count and compare 30<31, which is true and it will build an instruction address using the FAT trailer words. It should end up executing from the first address in the ROM page.

Quote:

---

I've been looking at the code, but I haven't puzzled it out yet.

---

[Eric Smith]

Cool! Thanks for the details! I think that bug was described in the PPCJ or Wlodek's book, but I had no idea that they had bothered to fix it.