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.”

[Sylvain Cote]

(07-29-2019 04:40 PM)Thott Wrote:  Is this a known bug?

I am sure Keith Jarret has validated the bug before publishing it in his 1983 book and I pretty sure that most of the old timer (and younger) has read his book, so I would say yes!

This is the book original English text:

Code:

             HP-41 EXTENDED FUNCTIONS MADE EASY
              By Keith Jarett,  1983 SYNTHETIX

                         APPENDIX A
                  The VER and 7CLREG bugs

     If your card reader is a revision 1G or higher, you may 
skip to the discussion of the 7CLREG bug on the next page. 
To find out which revision you have, run Catalog 2. If you 
see one of these headers:
        CARD READER 
        CARD RDR 1D 
        CARD RDR 1E 
        CARD RDR 1F
then your card reader has the VER bug. If you see 
        CARD RDR 1G
then your card reader does not have the VER bug.

    Here is the full story on the VER bug (for card readers
up to 1F). When the card reader's VER (verify) function is 
executed with an extended memory module plugged into port 2 
(port numbers are shown on the bottom of your HP-41 next to
the serial number), the first register of that module will be 
altered. The same warning applies to having an extended 
memory module plugged into port 4 of a port extender or built 
into a dual Extended Memory module (see Appendix C).

    When you use VER under these conditions, one register 
(decimal location 1007) of your data or program information in 
extended memory will be incorrect, unless there was no data in 
the port 2 module. It is even possible that the altered
register will be a file header register, disrupting the ex- 
tended memory directory.

    If this discussion is not completely clear to you, come 
back to it after you read Chapters 2 and Section 10C. For the 
present, just refrain from executing the card reader function 
VER if you have an extended memory module in port 2. If you 
must have an XMemory module in port 2, at least make sure that 
the module in port 1 or 3 will be filled before the one in
port 2 is used. This is easy to do:
    1) If you have only one XMemory module, put it in port 1
       or 3.
    2) If you have two XMemory modules, install them at the same
       time (while the calculator is turned off, of course).

If you follow this procedure, the register affected by VER 
will be the 366th register of extended memory. If you add up 
the file sizes shown in the extended memory directory and add 
2 more registers for each file header, you can figure out 
which file contains the 366th register. That file should be 
checked or purged after a VER operation. If the 366th regis- 
ter is the second of the two header registers for a file, that 
file and all the following files will probably be lost. This 
paragraph will become clear after you read Section 10C.

    Now for the good news. It is possible to completely 
eliminate the destruction of the 366th extended memory regis- 
ter. The synthetic program "VER" introduced in Section 10D 
does the job, in less time than it takes to press XEQ "VER".
If you have a port extender (Appendix C), another technique is 
almost as handy. Just switch off all XFunction and XMemory 
modules before executing VER.

    All card readers have the 7CLREG bug. The card reader's 
7CLREG function is intended to simulate the HP-67/97 CLREG 
function. This 7CLREG function can ruin an entire module of 
extended memory. I f you execute 7CLREG when the SIZE is less 
than 25, some of the data near register 360 of extended memory 
will be lost. This assumes that the recommended module plug- 
in procedure was used, so that the module in port 1 or 3 
contains register 365 as its last register. In addition, 
7CLREG is likely to cause all extended memory data starting at 
register 366 to become inaccessible. The solution is to avoid 
using 7CLREG, or to precede it with the sequence SIZE?, 25, 
X>Y?, PSIZE (see pages 74-75) to ensure a SIZE of at least 25.

APPENDIX C: AME Port-X-Tender: picture 1 & picture 2 (referenced in the above text)

Code:

    The AME Port-X-Tender, a flat, thin box that fits under the 
HP-41 and adds six more plug-in positions, for a total of ten. 
The 6 extra slots can be used for any modules or peripherals, 
including the HP-IL module. These extra slots are switchable,
allowing you to switch between two sets of extended memory if 
you have an HP-41C or CV (this will not work with the CX 
because some of the extended memory is internal and cannot be 
switched). A lithium battery maintains the contents of all 
modules, whether switched on or not. The Port-X-Tender plugs 
into port 3 with a short cable. The box is held in place with 
fabric fasteners. No modifications to your HP-41 are required.

[Thott]

(07-30-2019 10:37 PM)Sylvain Cote Wrote:  

(07-29-2019 04:40 PM)Thott Wrote:  Is this a known bug?

I am sure Keith Jarret has validated the bug before publishing it in his 1983 book and I pretty sure that most of the old timer (and younger) has read his book, so I would say yes!
[.....]
[.....]

Thank you for the answer.
I didn’t found the original English version from Keith Jarett.

May be it’s on the HP Museum Documentation Stick which I ordered and it should arrive in the next couples of days. I didn’t check it.....

Greetings
Thomas

[rprosperi]

(07-30-2019 11:50 PM)Thott Wrote:  May be it’s on the HP Museum Documentation Stick which I ordered and it should arrive in the next couples of days. I didn’t check it.....

Yes, it is included in the MoHPC USB Document set, along with many, many other books, and of course, hundreds of manuals, etc. More than a lifetime of reading and fun.

I also recommend getting Jake Schwartz' PPC DVD as well. It has all the PPC and similar Journal content plus lots of other useful and relevant materials such as all the EduCalc catalogs and Technical Notes, calculator conference proceedings from around the world, and more.

While other sources of enthusiast materials exist, the above 2 collections are the essential core every HP Enthusiast should own.

[Dave Frederickson]

(07-31-2019 12:57 AM)rprosperi Wrote:  I also recommend getting Jake Schwartz' PPC DVD as well. It has all the PPC and similar Journal content plus lots of other useful and relevant materials such as all the EduCalc catalogs and Technical Notes, calculator conference proceedings from around the world, and more.

There's also the HP41 DVD available for download for FREE.

https://www.hpcalc.org/torrents/

[rprosperi]

(07-31-2019 01:54 AM)Dave Frederickson Wrote:  There's also the HP41 DVD available for download for FREE.

https://www.hpcalc.org/torrents/

Yeah... Dave's right, I should have included this too. This site is focused on 41-related topics, manuals, etc. so not as widely appealing as the other 2 collections, but then again, which HP fan doesn't love the 41!

In fact this collection does include some non-41 materials such as Key Notes issues, HP-IL peripheral manuals, 67 stuff, etc.

[hth]

And the PPC DVD does not work for me, I got two different DVDs, none could be read.
Just to warn any potential buyer with a G5 Mac like me...

[Thott]

rprosperi, Dave, hth

Thank you for your answers and tips!

Greetings
Thomas

[Thott]

(07-31-2019 02:35 AM)rprosperi Wrote:  [.....]

but then again, which HP fan doesn't love the 41!

[.....]

Yes!
Programming is so simple with the HP41, so it’s my daily used calculator.
Beside it, the HP-48 programming with RPL is for me tterrible :-)

Greetings
Thomas

[rprosperi]

(07-31-2019 05:35 AM)hth Wrote:  And the PPC DVD does not work for me, I got two different DVDs, none could be read.
Just to warn any potential buyer with a G5 Mac like me...

Just a guess, but it's probably because the PPC DVD is distributed on Dual-Layer DVD media (it's over 7GB) and a older Mac like the G5 almost certainly has only a legacy Single-Layer DVD reader. Contact Jake and see if you could arrange to get a copy on USB instead.

[ijabbott]

(07-31-2019 12:34 PM)rprosperi Wrote:  

(07-31-2019 05:35 AM)hth Wrote:  And the PPC DVD does not work for me, I got two different DVDs, none could be read.
Just to warn any potential buyer with a G5 Mac like me...

Just a guess, but it's probably because the PPC DVD is distributed on Dual-Layer DVD media (it's over 7GB) and a older Mac like the G5 almost certainly has only a legacy Single-Layer DVD reader. Contact Jake and see if you could arrange to get a copy on USB instead.

Did SL (single-layer) DVD-ROM readers exist? I wouldn't have thought such things would comply with DVD specifications. More likely, the drive will handle DL (double-layer) DVD-ROM, but may be incompatible with DL DVD-R and/or DL DVD+R (whichever format the PPC DVD uses).

[rprosperi]

(07-31-2019 03:59 PM)ijabbott Wrote:  

(07-31-2019 12:34 PM)rprosperi Wrote:  Just a guess, but it's probably because the PPC DVD is distributed on Dual-Layer DVD media (it's over 7GB) and a older Mac like the G5 almost certainly has only a legacy Single-Layer DVD reader. Contact Jake and see if you could arrange to get a copy on USB instead.

Did SL (single-layer) DVD-ROM readers exist? I wouldn't have thought such things would comply with DVD specifications. More likely, the drive will handle DL (double-layer) DVD-ROM, but may be incompatible with DL DVD-R and/or DL DVD+R (whichever format the PPC DVD uses).

Heck yes, for many, many years. I truly doubt the G5 came with a DL drive, though the drive may have been replaced with a newer one along the way.

You comment about the media is a definite possibility as well. Modern (that is, recent until these too started to become extinct) DVD drives can read and write just about any kind of media, but many earlier drives definitely were limited to only -R or +R media.

[cdmackay]

My Mac doesn't even have a DVD drive in it, since it's a modern laptop.

I've had a couple of Jake's DVDs, and they read fine on the Mac via my cheapo USB DVD drive.

[Thomas Okken]

Sometimes the format may also be an issue. MacOS tends to be less forgiving than Windows or Linux when it comes to mounting filesystems. I don't know if that's the case here, but I have run into this with the MoHPC USB stick, which did not mount natively on my Mac, but did mount under Linux running in VirtualBox on the same machine.

[hth]

The second one I got was in UDF (Universal Disk Format), it did not work either. The machine is a G5 (PowerPC), VirtualBox does not work on it as far as I know. It reads the museum DVD without problems.

I have written it off, it was four years ago. I just wanted to give a small warning to anyone that consider ordering it.

[cdmackay]

(08-01-2019 02:37 AM)Thomas Okken Wrote:  Sometimes the format may also be an issue. MacOS tends to be less forgiving than Windows or Linux when it comes to mounting filesystems. I don't know if that's the case here, but I have run into this with the MoHPC USB stick, which did not mount natively on my Mac, but did mount under Linux running in VirtualBox on the same machine.

That's odd! I also had no problem at all reading the MoHPC stick on my Mac.

[Jake Schwartz]

(08-01-2019 06:07 AM)hth Wrote:  The second one I got was in UDF (Universal Disk Format), it did not work either. The machine is a G5 (PowerPC), VirtualBox does not work on it as far as I know. It reads the museum DVD without problems.

I have written it off, it was four years ago. I just wanted to give a small warning to anyone that consider ordering it.

I don't recall you telling about this at the time.....I would have offered an alternative right away. It is disconcerting to learn this years later, and your warning now seems to imply that you were somehow cheated. This is disappointing.

Jake

[Thomas Okken]

(08-01-2019 02:45 PM)cdmackay Wrote:  

(08-01-2019 02:37 AM)Thomas Okken Wrote:  Sometimes the format may also be an issue. MacOS tends to be less forgiving than Windows or Linux when it comes to mounting filesystems. I don't know if that's the case here, but I have run into this with the MoHPC USB stick, which did not mount natively on my Mac, but did mount under Linux running in VirtualBox on the same machine.

That's odd! I also had no problem at all reading the MoHPC stick on my Mac.

I may be mis-remembering, and it was actually the TOS collection, I'm not 100% sure. Either way, I communicated the problem to the seller, and they offered to send a replacement, which I declined, having found a workaround. But what I meant to illustrate is that Macs can be picky. Another example: another USB stick, formatted with a FAT32 filesystem. One time, I unplugged it from my Mac, without unmounting it first. After that, the Mac wouldn't mount it any more, until I inserted it into a PC. The PC, running Windows, mounted it without complaint, and after that, the Mac did too. Given that experience, I can easily imagine a Mac having a problem with a flipped bit in an ISO 9660 header somewhere; it might be worth a shot trying the disc in a PC, or, as Bob suggested, a later model Mac, or an external DVD drive.

[Sylvain Cote]

(08-01-2019 05:31 PM)Thomas Okken Wrote:  One time, I unplugged it from my Mac, without unmounting it first. After that, the Mac wouldn't mount it any more, until I inserted it into a PC.

Unix systems (Mac, BSD, Linux, Unix, etc) in general does not support well removing a mounted volume without un-mounting it first, the main reason is that volumes cache is enabled by default.
To my knowledge, macOS does not have a way to change that default behaviour. (other Unix systems can be configured through the /etc/fstab and /etc/mtab files)
If you use the command line, you can unmount the volume and remount it without the cache (activating synchronous I/O) and thus be more resilient.
Sylvain

[rprosperi]

(08-01-2019 06:31 PM)Sylvain Cote Wrote:  

(08-01-2019 05:31 PM)Thomas Okken Wrote:  One time, I unplugged it from my Mac, without unmounting it first. After that, the Mac wouldn't mount it any more, until I inserted it into a PC.

Unix systems (Mac, BSD, Linux, Unix, etc) in general does not support well removing a mounted volume without un-mounting it first, the main reason is that volumes cache is enabled by default.
To my knowledge, macOS does not have a way to change that default behaviour. (other Unix systems can be configured through the /etc/fstab and /etc/mtab files)
If you use the command line, you can unmount the volume and remount it without the cache (activating synchronous I/O) and thus be more resilient.
Sylvain

You know, convenient and easy to remember commands such as:

umount /dev/usb/0/first/left-side -i -nc -r -v -mr

Where:
-i means do it immediately
-nc means 'no cache' mode
-r means 'really, I mean it, please do it now'
-v means verbose output (include weather, biorythm and horoscope)
-mr means 'more resilient' mode

I love *nix - endless opportunities to poke fun. Unlike Windows where there really is only one - "you should be using *nix"