Another bug hidden for over 40 years ... ?

[ThomasF]

Hi all,

While working on the Blinky emulation, I have once again started to read the VASM listings, not only for the mainframe, but also the printers and time module.

To be compatible with other printers, the Blinky ROM must maintain all global entry points used.
Not only is there a entry point jump table in the end of the module, but there are also direct entry points into the ROM code, e.g. from the Time module (82182A) into the printer ROM, so these addresses must be kept between the printers (82143, the IL printer 82162 and the Blinky 82242 IR module).

When I was reading the Timer VASM looking for calls to the printer I found what I consider is a new bug (at least I can't remember any notes about it), but I have problems verifying this with real hardware since I'm lacking the 82182 Timer module myself.

In the Timer VASM the following code snippet was found, it is in the code for the function ALMCAT, printing any alarms on the printer. This code prints the time & date, the reset interval, and then calls the printer to check status and report any errors (BECHK).

Code:

 73 40           1 GOSUB TMSG        PRINT ALARM TIME & DATE
 73 41           0                   *TIMER ROM: TM2, @0431
 74 42        1340 DISOFF            TURN DISPLAY OFF
 75 43         510 S6= 1             (P+2) OK TO PRINT
 76 44           1 GOSUB INTVAL      DISPLAY RESET INTERVAL
 76 45           0                   *TIMER ROM: TM2, @1234
 77 46          53 GOTO ACT135 ( 53) (P+1) NO RESET INTERVAL
 78 47           1 GOSUB TMSG        (P+2) PRINT RESET INTERVAL
 78 50           0                   *TIMER ROM: TM2, @0431
 79 51           1 GOSUB WAITK6      WAIT 0.6 SECONDS
 79 52           0                   *TIMER ROM: TM2, @0420
 80 53 ACT135  615 CON @615          GOSUB TO BECHK & PECHK
 81 54        1474 CON @1474         *ILPRINTER: PL0, @1737
 82                                  (DISPLAY ANY PRTR ERRORS)

In normal cases, when the code calls a global entry point, the actual label is used, and the linker fills in the address for the subroutine call (like the GOSUB's above), but in this case there is no label so the address is entered manually (line 80 and 81 above).
This should result in a call to 01737 (octal) in quad 0 of the printer ROM (PL0, @1737 corresponding to 0x63DF).

And at the corresponding place in the printer (82162 in this case) it says:

Code:

************************************************************************
* OUTPCT IS CALLED BY TIMER ROM ALSO. *
* USES ONLY A, C, N, S[7:0], S9 AND +2 SUBROUTINE LEVELS. *
************************************************************************
 1028 1735 OUTPCT    1 GOSUB EOLL    SEND EOLL LEFT-JUSTIFIED
 1028 1736           0               *ILPRINTER: PL1, @1756
 1029 1737           1 GOSUB BECHK   WAIT FOR PRINTER
 1029 1740           0               *ILPRINTER: PL0, @1743

Notice that the address 1737 does not have a label, like OUTPCT two lines above.
This corresponds to address 0x63DD (OUTPCT) and 0x63DF (OUTPCT + 2).

This confused me, since the opcode in the Timer ROM (615,1474) which is 0x18D,0x33C and corresponds to "?NC XQ CF63" - since this is not in the printer ROM at page 6 - but could be 0x63CF if read backwards ... !?!?

Code:

 0615 -> 0 110 001 101 -> 0110 0011 01 --> 6 3 Opcode class 1
 1474 -> 1 100 111 100 -> 1100 1111 00 --> C F (00 -> ?NC XQ)

The comment says that we should call 1737 in printer rom 0 (PL0) = 0x6000 + 0x0000 + 0x3DF = 0x63DF - (this is the correct address to OUTPCT + 2 which calls the routine BECHK.
0x63CF is close to 0x63DF but not right - and absolutely not backwards ...

And all other calls to e.g. OUTPCT are using the normal linkage using the global label, with an empty instruction for the linker to resolve it, but this one is handcoded - and obviously very wrong ...

So, my interpretation of this is that if ALMCAT is executed with a printer attached, it would fail if there is some module in page C (port 3) at the same time!

This has been confirmed by Mike using his powerful NutEM/PC emulator, but since I don't have a timer module myself I can't verify this on real hardware.
The HP-41CX also has the Timer module, but this code is updated and corrected, and works when tested.

Could someone who owns a 82182 Timer module check if the following is a correct description of the error?
With timer module and a printer attached, but port 3 empty:

1. Enter some alarm, e.g.:

Code:

     [ALPHA] TEST [ALPHA]
     .15 [ENTER^]
     0 [ENTER^]
     11 [XEQ] XYZALM

2. Set the printer in TRACE mode
3. [XEQ] ALMCAT

This should result in that the alarm is printed, and this works since port 3 is empty so the call to 0xCF63 just returns and execution continues without any problem.

If we now insert a module in port 3, we probably introduce code at address 0xCF63 (we have tested this with a PPC-ROM in port 3), and execute ALMCAT again.

But be warned that this might result in a "MEMORY LOST", since my interpretation is that we would start executing code at 0xCF63 which might result in a corrupt state leading to "MEMORY LOST".

Someone made some mistakes when writing this code back in the days, first the wrong address was used (0x63CF (01717) instead of 0x63DF (01737)), but also swapped the two instructions, resulting in a call to 0xCF63.
This caused no harm as long as port 3 was empty (or if e.g. the Time module, a printer or HPIL was inserted there since they all are hardwired to other pages).
Nor is the call to BECHK really needed, there might be timing issues if a lot of alarms or big load on the printer before calling ALMCAT, but BECHK just wait for output to be printed and then checks for any errors (so normally just returns).

Even if the system is over 40 years old, it still amazes me with all bits and pieces that are still to be uncovered and understood so many years after the introduction!

Would be great if anyone could confirm this using a real 41C/CV, a printer and the 82182 Time module!

Have a nice Xmas season and a great New Year!

Cheers,
Thomas