HP-41 instruction print bug found

[hth]

At least with the HP82162A printer an XROM instruction with postfix argument is not printed properly when executed from the keyboard.

Say you have an XROM FOO instruction that has its header marked as taking a numeric postfix argument. In this case the instruction code is the 2-byte XROM code and the argument is passed on the side in register B.X. The PRT5 routine (in the HP-IL module) is supposed to print the executed instruction. However the actual printing of the argument picks the postfix operand from the second byte of the 2-byte XROM code, not the one that was passed in B.X.

If I invoke 'FOO 07' (where FOO is an XROM) and this instruction code is A3CC, it will print as "FOO IND 76", not "FOO 07". CC is 80 (IND), taking that away we have 4C which is 76 decimal.

Is it possible to alter the HP-IL module image on the 41CL somehow?

I imagine that the power on sequence could see if there is an HP-IL module inserted and then use the MMU to map an alternative (fixed) ROM image over it?

The offending code is:

Code:

   953 1454 PFK35   630 C=M                  PUT ARGUMENT
   954 1455         274 RCR    5              IN C[1:0]
   955 1456           1 GOLONG PRW930        PRINT NUMERICAL OPERAND
   955 1457           2                      *ILPRINTER:  PL2, @0156

Here it assumes the second byte has the postfix operand, but that is not true for XROMs (RCR 2 is needed for XROMs).

[Monte Dalrymple]

(11-04-2019 04:32 AM)hth Wrote:  Is it possible to alter the HP-IL module image on the 41CL somehow?

Physical images plugged into the 41CL always take precedence. So the only way to "patch" the physical HP-IL ROM would be to physically disable (ie remove) the ROM in the HP-IL module and then "PLUG" in a patched version in the 41CL.

[hth]

(11-04-2019 05:17 AM)Monte Dalrymple Wrote:  

(11-04-2019 04:32 AM)hth Wrote:  Is it possible to alter the HP-IL module image on the 41CL somehow?

Physical images plugged into the 41CL always take precedence. So the only way to "patch" the physical HP-IL ROM would be to physically disable (ie remove) the ROM in the HP-IL module and then "PLUG" in a patched version in the 41CL.

Then why do I get a conflict if I plug the HP-IL module into the 41CL without mapping the MMU? YFNZ is in page 7 by default, should it not be shadowed by the HP-IL module in that case?

[Ken S]

(11-04-2019 05:17 AM)Monte Dalrymple Wrote:  

(11-04-2019 04:32 AM)hth Wrote:  Is it possible to alter the HP-IL module image on the 41CL somehow?

Physical images plugged into the 41CL always take precedence. So the only way to "patch" the physical HP-IL ROM would be to physically disable (ie remove) the ROM in the HP-IL module and then "PLUG" in a patched version in the 41CL.

Couldn't you use the switch on the IL module to disable the printer and then load the patched rom? The reason for the switch was so you could plug in another printer while the module was in place without conflict. I thought the switch just disabled the power to the internal IL print Rom. Not sure if this would work but worth a shot.

[Monte Dalrymple]

(11-04-2019 05:52 AM)hth Wrote:  

(11-04-2019 05:17 AM)Monte Dalrymple Wrote:  Physical images plugged into the 41CL always take precedence. So the only way to "patch" the physical HP-IL ROM would be to physically disable (ie remove) the ROM in the HP-IL module and then "PLUG" in a patched version in the 41CL.

Then why do I get a conflict if I plug the HP-IL module into the 41CL without mapping the MMU? YFNZ is in page 7 by default, should it not be shadowed by the HP-IL module in that case?

When an image is plugged in internally the ROM contents (instructions) are driven onto the ISA bus so that anything on the bus can see the instruction stream. In a Turbo mode the ISA bus is driven with NOPs unless a 1X-tagged instruction is fetched on the bus. If a physical module is addressed at the same page it will also try to drive the ISA bus with instructions. This creates a bus fight and anything on the bus (including the CPU) will "see" garbage. This is why a MMU-disabled 41CL will have problems with an HP-IL module being plugged in.

In retrospect, I probably should have designed this differently, so that YFNZ was not driven on the bus while plugged in to Page 7. Oh well.

By the way, the 41CL does handle Page 5 this way, which is why a Time Module can be inserted without a conflict. The internal Page 5 access is recognized by the logic during the address phase on the ISA bus and the address driven on the bus is modified so that it isn't a Page 5 address. So the ROM in the Time Module is never accessed, but everything on the bus sees the instruction stream, just (apparently) at an address in a different page.

[hth]

(11-05-2019 01:00 AM)Ken S Wrote:  Couldn't you use the switch on the IL module to disable the printer and then load the patched rom? The reason for the switch was so you could plug in another printer while the module was in place without conflict. I thought the switch just disabled the power to the internal IL print Rom. Not sure if this would work but worth a shot.

That is a good idea in theory, but I do not think it will work. The problem I think is that the disable switch actually relocates the printer ROM from page 6 to page 4. Since there are page 4 modules, it will probably create page 4 conflicts.

[hth]

(11-05-2019 01:02 AM)Monte Dalrymple Wrote:  

(11-04-2019 05:52 AM)hth Wrote:  Then why do I get a conflict if I plug the HP-IL module into the 41CL without mapping the MMU? YFNZ is in page 7 by default, should it not be shadowed by the HP-IL module in that case?

When an image is plugged in internally the ROM contents (instructions) are driven onto the ISA bus so that anything on the bus can see the instruction stream. In a Turbo mode the ISA bus is driven with NOPs unless a 1X-tagged instruction is fetched on the bus. If a physical module is addressed at the same page it will also try to drive the ISA bus with instructions. This creates a bus fight and anything on the bus (including the CPU) will "see" garbage. This is why a MMU-disabled 41CL will have problems with an HP-IL module being plugged in.

In retrospect, I probably should have designed this differently, so that YFNZ was not driven on the bus while plugged in to Page 7. Oh well.

By the way, the 41CL does handle Page 5 this way, which is why a Time Module can be inserted without a conflict. The internal Page 5 access is recognized by the logic during the address phase on the ISA bus and the address driven on the bus is modified so that it isn't a Page 5 address. So the ROM in the Time Module is never accessed, but everything on the bus sees the instruction stream, just (apparently) at an address in a different page.

OK, then I understand. I suppose this goes pretty deep into the logic so it is not anything that can be changed in an easy way.
It is not a huge issue and saves me from spending time to fix it.

It is quite obvious that HP did not do an entirely good job of testing various aspects of advanced XROM handling, as I found three bugs so far (I think) related to it.

Unrelated, but I am curious. Why is it that the 41CL cannot be unlocked easily using ENTER-ON or BACKARROW-ON, like the ordinary HP-41 can? I always have to pull the batteries to reset it when I made one of my many mistakes.

[hth]

Now I just ran into the third XROM bug I talked about (again). It is actually mentioned briefly in MCODE for beginners on page 137. If you enter "FOO IND L", that is, a prompting XROM function with stack indirect, the postfix argument replaces the second byte of the XROM instruction code, which causes it to attempt to execute a completely different XROM instruction.

[Ángel Martin]

I've followed this discussion with interest, and if I understand well at the crux of it is the inability by the OS to handle some corner cases of prompting functions in plug-in ROMS, is that correct?

We know those are not supposed to be supported (HP dixit) , but I also use them profusely in my advanced modules, including the IND case, and have never encounter any glitches (ok, the printer case I have no experience with, I rarely use a printer in my system anyway).

For example in the WARP_Core module there are a dozen or so of functions used to access register's contents replacing the native RCL/STO. They can happily handle IND and IND ST, and that for all status registers as well.

You're right this is not done using the internal OS routines, which were not designed to do that (regardless of their apparent ability using the function's name characters to make them prompting) - and that's why the module handles all the prompting in dedicated subroutines (some stubs also in the Library#4 BTW), not using calls to the OS.

The upside is that the same prompting handling routines work for sub-functions as well not only for the main FAT, and that's a big plus.

[mfleming]

(11-05-2019 01:56 AM)hth Wrote:  

(11-05-2019 01:00 AM)Ken S Wrote:  Couldn't you use the switch on the IL module to disable the printer and then load the patched rom? The reason for the switch was so you could plug in another printer while the module was in place without conflict. I thought the switch just disabled the power to the internal IL print Rom. Not sure if this would work but worth a shot.

That is a good idea in theory, but I do not think it will work. The problem I think is that the disable switch actually relocates the printer ROM from page 6 to page 4. Since there are page 4 modules, it will probably create page 4 conflicts.

Tested, and works. The Mass Storage ROM shows up in 7, LIB#4 remains in 4, and the ROM plugged into page 6 (HEPAX) shows up in a CAT 1G and works fine. You'll have to test relocating a modified copy of the printer rom in RAM to page 6

[Ángel Martin]

(11-05-2019 03:36 PM)mfleming Wrote:  .... LIB#4 remains in 4, ......

Wow, that's surprising - and good to know, I always assumed Lib#4 would be incompatible with a disabled HP-IL setting.

[hth]

(11-05-2019 03:36 PM)mfleming Wrote:  

(11-05-2019 01:56 AM)hth Wrote:  That is a good idea in theory, but I do not think it will work. The problem I think is that the disable switch actually relocates the printer ROM from page 6 to page 4. Since there are page 4 modules, it will probably create page 4 conflicts.

Tested, and works. The Mass Storage ROM shows up in 7, LIB#4 remains in 4, and the ROM plugged into page 6 (HEPAX) shows up in a CAT 1G and works fine. You'll have to test relocating a modified copy of the printer rom in RAM to page 6

Interesting. Did you test by executing any code in LIB4 that access the LCD? In that case it should go out and re-run the instruction on the bus.

If that works, then it may be possible to replace both the HP-IL ROMs in place, but just running alternative modules on top of it? It may be that having YFNZ in page 7 causes problems with a printer in page 6 is that the printer makes call into page 7 assuming the IL ROM page is there.

[hth]

(11-05-2019 06:09 AM)Ángel Martin Wrote:  I've followed this discussion with interest, and if I understand well at the crux of it is the inability by the OS to handle some corner cases of prompting functions in plug-in ROMS, is that correct?

We know those are not supposed to be supported (HP dixit) , but I also use them profusely in my advanced modules, including the IND case, and have never encounter any glitches (ok, the printer case I have no experience with, I rarely use a printer in my system anyway).

For example in the WARP_Core module there are a dozen or so of functions used to access register's contents replacing the native RCL/STO. They can happily handle IND and IND ST, and that for all status registers as well.

You're right this is not done using the internal OS routines, which were not designed to do that (regardless of their apparent ability using the function's name characters to make them prompting) - and that's why the module handles all the prompting in dedicated subroutines (some stubs also in the Library#4 BTW), not using calls to the OS.

The upside is that the same prompting handling routines work for sub-functions as well not only for the main FAT, and that's a big plus.

Yes, all these problems comes from that built-in instructions are one byte with a second postfix byte for the register/numeric operand. This is not true for XROMs as they are two bytes and have to deal with the postfix operand on the side. Sometimes it will just execute code that was made for the one byte prefix and just do the wrong thing.

Prompting XROMs are limited by design. HP did not explore this feature so much. Alpha prompting PRP comes to my mind, and it would in retrospect have been better to take the input from the alpha register. That would have cost more code and time rather than just use the existing alpha prompt feature. The printer was written early, the Extended Functions module came out later with such code.

What I am working on is an extensible CAT function (as an XROM). It is not programmable, so it was easy to use the existing prompt functionality. When I fixed "CAT IND" I also tried "CAT IND L" and got NONEXISTENT. At that point I investigated it a bit further and found that it had put the postfix in the instruction and tried to do an XROM lookup of that malformed instruction. I then found the note in 'MCODE for beginners' about this and also remember running into this in the mid eighties when I experimented with prompting XROMs.

It is correct that you can get around it by doing your own prompt handling, but it feels a bit overkill for this situation. For the other prompting XROMs (programmable), I use a different technique. Maybe I should just switch to use that one instead, and perhaps make CAT programmable.

[mfleming]

(11-05-2019 05:08 PM)hth Wrote:  Interesting. Did you test by executing any code in LIB4 that access the LCD? In that case it should go out and re-run the instruction on the bus.

I initially just checked to see that LIB4 wasn't shadowed. SandMath was plugged in and it normally would complain about a missing library on power-up. Just tried again by plugging in 41Z which also didn't object to a missing library.

Trying the CROOT function from SandMath causes a hang when it tries to display a complex value in Alpha. So unfortunately there does seem to be a conflict at page 4 regardless of what a page cat reports.

[hth]

(11-05-2019 06:30 PM)mfleming Wrote:  

(11-05-2019 05:08 PM)hth Wrote:  Interesting. Did you test by executing any code in LIB4 that access the LCD? In that case it should go out and re-run the instruction on the bus.

I initially just checked to see that LIB4 wasn't shadowed. SandMath was plugged in and it normally would complain about a missing library on power-up. Just tried again by plugging in 41Z which also didn't object to a missing library.

Trying the CROOT function from SandMath causes a hang when it tries to display a complex value in Alpha. So unfortunately there does seem to be a conflict at page 4 regardless of what a page cat reports.

I see. The 41CL probably emits the address and instruction on the ISA line and the ROM that is there reacts to it and tries to present its ROM word too.

I have fixed the "FOO IND L" bug where mainframe clobbers the XROM instruction (not the printer bug), but I will let it sit for a while. I am not entirely sure it is worth the trouble.

[Monte Dalrymple]

(11-05-2019 02:07 AM)hth Wrote:  Unrelated, but I am curious. Why is it that the 41CL cannot be unlocked easily using ENTER-ON or BACKARROW-ON, like the ordinary HP-41 can? I always have to pull the batteries to reset it when I made one of my many mistakes.

Simple answer is that MEMORY LOST does not disable the MMU, so if that is the source of the conflict it will still be present. If the machine is functional enough to respond to a BACKSPACE-ON it should also be functional enough to respond to a YRES command, which will disable the MMU.

[hth]

(11-06-2019 04:14 PM)Monte Dalrymple Wrote:  

(11-05-2019 02:07 AM)hth Wrote:  Unrelated, but I am curious. Why is it that the 41CL cannot be unlocked easily using ENTER-ON or BACKARROW-ON, like the ordinary HP-41 can? I always have to pull the batteries to reset it when I made one of my many mistakes.

Simple answer is that MEMORY LOST does not disable the MMU, so if that is the source of the conflict it will still be present. If the machine is functional enough to respond to a BACKSPACE-ON it should also be functional enough to respond to a YRES command, which will disable the MMU.

Are you sure? I think the modified mainframe code disables the MMU on the cold start.

I am thinking of when you get the machine to lock up, pull the offending MLDL or HP-IL module and the only thing that seems to help to get control back is to briefly remove the batteries. The original HP-41 could usually be reset using ENTER-ON or BACKARROW-ON (without a memory lost if you press the ON key more than once while holding the other key). I think this causes the PC to be reset to zero somehow, but I have no idea how the hardware works. I believe very old HP-41s do not respond to ENTER-ON, my early 41CV did not when new. After I had the keyboard replaced by HP service a year or so down the road, it started to accept ENTER-ON. This particular unit is also the one I converted to 41CL a while back.