HP41 Card Reader bug in conjunction with X-Memory

[Thott]

I found in the book from K. Jarret “Erweitere Funktionen des HP41 - leicht gemacht”
(in German) the following text regarding HP41 bugs. Sorry but it translated by Google. May be a little bit ugly.

Is this a known bug?

———-

“The third bug occurs in conjunction with the card reader functions 'VER' and '7CLREG'. The execution of these functions can undesirably alter the content of the X-memory. As long as you have not read the relevant details in Appendix A, you should definitely refrain from the 'VER' version if there is an X-Memory module in the plug-in sockets 2 or 4. Meanwhile, the X-functions module can be plugged safely anywhere. A short synthetic routine, presented in Section 10D, allows the trouble-free use of 'VER'.
The third bug is in the card reader and indeed in all devices, where under 'CAT 2' one of the messages
CARD READER
CARD RDR 1D
CARD RDR 1E
CARD RDR 1F
appears.

Only recently manufactured devices, the version of which is indicated a 1G or higher, are dotted with respect to 'VER'.
The HP-41 CX does not contain any bug in connection with the X functions. But again, avoid 'VER' if you are using an older card reader and have not worked through section 10D yet.

 As soon as the card reader function: VER 'is called with a plug-in socket 2 (the numbers of the jacks can be found on the back of the computer) the X-memory module is inserted; the contents of the first register of this module undergo a change. The same misfortune happens when the module is seated in slot 4 of a jack extension or is part of a dual module (see Appendix C, item 7).
Assuming the conditions described, the contents of the register located in memory location 1007 are changed when using 'VER', unless the module at number 2 contains no data at all. Incidentally, it is even possible in the worst case that the vulnerable register even forms the second register of a file, resulting in a particularly painful to be assessed damage to the X-Memory directory. If in doubt, consult Section 10C again to understand what happens when the 'VER' bug dies.

The 'VER' bug can easily be avoided by not putting any X memory module in second place. Rank 4 is occupied by the card reader anyway, and an X-Memory module in 1st or 3rd place is not threatened. However, if you need two X-Memory modules, you will need to either fill a module sitting at # 1 or # 3 first with files before you put the second in second place, or you will plug both - if the computer is switched off - at the same time , If you follow this advice, you can at least find the register that is endangered by the 'VER' bug in a well-defined place: it is, if you proceed as described, exactly the 366th register of the X-Memory. To determine which of your files this register belongs to, all you need to do is look through the X-Memory directory and add two registers per file (for the two head registers) to the file sizes you have specified. By doing so, you can determine exactly in which file: and at which point in the determined file destruction is to be feared. Thus, following the execution of 'VER', the file in question can be checked and, if a repair proves impossible, it can be purposefully deleted. If the 366th register is, unfortunately, the second key register of a file, access to this and all subsequent files will almost always disappear altogether (see Section 10C).
Good news for those who have not yet read Section 10D: It is possible to completely avoid the destruction of the 366th register by using the synthetic program "VER" described in Section 10D. It takes less time to execute than the amount you need to spend to 'XEQ' VER '".
If you have connected a jack extension (see Appendix C, point 7), there is another equally easy way to avoid the 'VER' bug: Turn off the X functions and the X memory modules, before you run 'VER'.
In all card readers sits the '7CLREG' bug. The card reader function '7CLREG' is used to ensure the transfer capability of HP-67/97 programs containing the 'CLREG' function to the HP -41; It simulates the HP 67/97 function 'CLREG'. The '7CLREG' bug manages to spoil the contents of an entire X-Memory module. If you call '7CLREG' on less than 25 available data registers, data in the 360. Registers of the X memory will be lost, provided the 'VER' bug's recommendations on the usage order of the X-Memory - Modules have been followed so that the X ~ Memory module sitting in 1st or 3rd position contains the 365th register as the last register. Moreover, after the use of '7CLREG' under the data register condition mentioned, almost all data from the 366th register at the top of the handle is eluded. As a countermeasure, the only thing left to do is avoid either '7CLREG' or preface this command with the sequence 'SIZE ?, 25, X> Y ?, PSIZE' (see Section 4D) to ensure that the data register q is at least 25.”