I seem to have stumbled upon a small bug in either the ZEPROM PROGRAMMER code, or perhaps the HP-41CX OS. I found it while attempting a copy of the Programmer ROM image from one ZEPROM to another. The original ZEPROM was configured as a straight 16K device, with the Programmer in core 3 (fourth page), installed in port 1 of the HP-41. The ROM's address space was then in block B (11). The target ZEPROM, attached to the Zeprom Voltage Converter fixture, was in Port 3 of the HP-41, so the four (blank) ROM pages were at pages C through F (12 through 15). I used the ZEPROM Programmer function "COPYPG" to copy from page B (11) to page F (15).
The ROM copied successfully, but upon further examination, I found a byte of 0FDh (253) had been burned into a single word in the first page of the target ZEPROM, at address 4C (76 words into the space). This of course can be a problem because these bits can't be cleared without erasing the whole device. Whatever you put into that byte will likely be different because of the extra burned bits.
A second try with a verified erased ZEPROM produced the same result.
On a third try, I offset the two ZEPROMS; the source was located in port 1, and the target was moved to port 4. The addressing of the target ZEPROM did not change, it's design is such that it still occupies pages C through F, whether it in port 3 or 4. However, the copy was successful, with no extra byte loaded into the first page.
Since this repeated, it appears that either the ZEPROM Programmer code has a bug that writes to this extraneous byte during a page copy, or its possible that the HP-41CX firmware or hardware has a bug that does the same thing. It normally wouldn't be noticed, because ROM is always supposed to be in this address space, and won't be affected by an extraneous write command, unless of course, the space is occupied by a ZEPROM that is being programmed with a power supply voltage of 12 volts (from the ZVC). I remember that the card readers with ROM versions before 1G had a similar bug; extraneous data would be written to some extended memory address during the execution of the "VER" (verify) command.
Any experiences or ideas? I have my work around, but just curious if this was a known issue.
Dan
Edited: 2 July 2008, 12:13 p.m.