Bug in v41 and 41X emulation ?

[Ángel Martin]

I've been looking at a problem dealing with the support of upper-score characters (hex 106) by both V41 and the DM-41X. After some tiring troubleshooting I *think* I've narrowed it down to an issue with the SLSABC instruction (op code 0x3E8), which is supposed to write the 9-bit character in C.X to the rightmost position in the LCD.

The problem appears to occur when there's already one (or many) upper-score character in the rightmost position. In such an instance the real machine overwrites the upper-score(s) with the new char, effectively deleting all to its left.

However on V41 and the 41X the new char is placed to the right of the upper-score(s) instead, which - albeit may seem to be more logical - is not how the real machine does it.

You could argue that the real machine had a bug and the emulators don't; but herein lies the problem. Why does this matter? Even if the upper-scores are infrequently used they play an essential role in the HP-IL Devel and other functions with advanced use of the LCD. Not having the exact emulation (whether you like the way it worked) is a problem.

BTW the 41CL behaves exactly like the original machine, so 100% match right there. So that makes me wonder how that was achieved, considering it's the only system that got it "right"... It's probably due to the fact that it uses the Fullnut LCD, unlike the other two cases which emulate the Halfnut one.

[MeindertKuipers]

Interesting find.
The display instructions are implemented inside the display controller, so the 41CL does not emulate the display, it has a real one, so it is correct behavior by design. Did you check if both fullnut and halfnut displays behave the same on a real HP41?

[rprosperi]

Indeed, interesting! And subtle.

Looking forward to seeing results as Meindert suggested, and I agree it should behave as a genuine 41CX behaves. I'm curious to see if the HN made the same mistake.

Thanks Angel, and Meindert.

[Ángel Martin]

ok, this seems to be relevant: I tested the functionality in a HalfNut machine (via Clonix) and sure enough the issue is also there. At this point the question is twofold:

1. apparently the LCD driver of the HN has a different behavior compared to the FN. Did HP do this to correct a problem in the earlier version, or is this derived from the extended char set support?

2. This explains why it works on the CL - always FN models - and probably also explains why it fails on V41/41X since they both emulate the HN display. Question here is where is that particular feature emulation coded, and could it be possible to revert it to use the FN mode... assuming that was desired of course.

[J-F Garnier]

Angel, this is confusing for me: when you say
"I tested the functionality in a HalfNut machine (via Clonix) and sure enough the issue is also there"
and then
"the HN has a different behavior compared to the FN. Did HP do this to correct a problem in the earlier version"
it's not clear if the problem (for you) is the HN clearing the display, or rather the HN not clearing it (and so is not compatible with the FN)?
If HP fixed something related to the 0x106 code, then it means there was a problem :-)

Code 0x106, the upper-score character, is the user character 0 that has indeed a special meaning in the HP-41 in many ways.
As you said, the zero character is frequently used when working on HP-IL with the HP-IL Dev and X-IO ROMs, and I never observed such difference between the real FullNut and emulators (including my Emu41).
Can you indicate a simple procedure (not using esoteric modules :-) to reproduce the problem (meaning: the upperscore characters are cleared)?

J-F

[Ángel Martin]

Hi J-F, I'm still trying to find an easy combination showing this issue because the only examples I have are using "esoteric" modules as you say.

I agree it's very unlikely that there was a bug in the FN display driver, but then: why the MCODE only fails in HN machines? It's quite a mystery...

Here's the best example I have. This routine is taken from the NFR ROM and it shows a "splash" screen where each character is scrolled from the right to its final position, until the whole message is completed (in this case the text reads "-LIB#4 R58*", the last char being hex 0x1E2. It's quite a nice effect and surely a brainy code. It works flawlessly on the CL and standard FN machines, but it hangs the machine up on HN models. You may want to test how it fares on your emulators.

Code:

1E2    "**"      
038    "8"    
035    "5"    
012    "R"    Revision Name
020    " "    function name is shown
034    "4"    in the Page_Catalog
023    "#"    
002    "B"    
009    "I"    
00C    "L"    
35D    ?NC XQ         
000    ->00D7    [PCTOC]
27A    C=C-1   M    to beginning of string
0EE    B<>C   ALL    save it in B[M]
3C1    ?NC XQ        Enable and Clear Display
0B0    ->2CF0    [CLLCDE]
130    LDI S&X    
107    "t"    little "T"
31C    PT=  1    
3A8    WRIT 14(d)    Places Long LEFT: rotates right
3B8    READ 14(d)    Fetch Right Long: rotates right
0CE    C=B  ALL    
27A    C=C-1  M    previous address
0EE    B<>C  ALL    update repository
0CE    C=B ALL    keep it in C
330    FETCH S&X    read byte value
358    ST=C  XP    place it in ST
28C    ?FSET 7    is it > "0FF"?
023    JNC  +04           no, skip to A0A8
284    CLRF  7    clear it
398    C=ST  XP    restore byte to C[S&X]
288    SETF 7    flag this fact
3E8    WRIT 15(e)    write it to RIGHT and rotate left
28C    ?FSET 7    was it last one?
10F    JC   +33 d        yes, we're done -> A0CB
130    LDI S&X    
100    CON:    
266    C=C-1  S&X    count until 100(hex)
3FB    JNC  -01           A0AD
130    LDI S&X    
020    " "    blank space
106    A=C  S&X    store in A[S&X]
3B8    READ  14(d)    read right chr and move it to left
366    ?A#C  S&X    is it a space?
3F3    JNC  -02        yes, read next chr.  -> A0B2
158    M=C  ALL    no, save chr1 in M
3B8    READ 14(d)    read next cand move to left
366    ?A#C  S&X    is it a space?
05F    JC   +11       no, jump over to A0C3
198    C=M ALL    yes, recall chr1
3E8    WRIT 15(e)    write it to RIGHT end
130    LDI S&X    
020    " "    blank space
3E8    WRIT 15(e)    write it to RIGHT end
3F8    READ 15(e)    Fetch Left Long, rotate Left
2E2    ?C#0 @PT    ???? WTF, PT= 1 ~~
3F7    JC   -02          no, keep at it -> A0BE
3A8    WRIT 14(d)    yes, write cntl chr to LEFT, rotate right
34B    JNC  -23 d     [SCROLL]
3E8    WRIT 15(e)    write it to RIGHT end
198    C=M  ALL    recall chr1 for real
3E8    WRIT 15(e)    write it to RIGHT end
3F8    READ 15(e)    Fetch Left Long
366    ?A#C  S&X    is it space?
3F3    JNC  -02          no, get next chr -> A0C6
3A8    WRIT 14(d)    write cntl$ to LEFT, rotate right
29B    JNC  -45d    next character, A09D
149    ?NC XQ    Enables Chip0
024    ->0952    [ENCP00]
1F9    ?NC GO    Set MSG Flag
00E    ->-037E    [STMSGF]

For your testing convenience, see the example module attached. It accesses the code above when you execute the SPLASH function. Make sure both the XROM and LIBRARY4 are plugged-in.

[J-F Garnier]

I don't see the code 106 upperscore character in your code.
I see the code 1E2, you cleared bit 7 so it becomes 162, that is character 122 with a dot punctuation.
Character 122 is 'b' but on a HN only, it is non-existent on the FN.
Did I understand correctly?

It would not so surprising that the FN and HN behave differently on the new HN characters.
But your code hangs even before sending the code 122 HN character, it hangs at the # character so it is something else.
I have the feeling that the splashing effect code works for characters A-O only, due to the ?C#0 @PT test.
Unfortunately I don't understand your code well enough to test it further.
My suspicion is that the bug is in the code itself. If it works on a FN, it may be due to a flaw in the FN driver design, but it's not something you could rely on.

It was a long time since I played with the 41 mcode, but it's still fun !

J-F

[J-F Garnier]

(04-25-2021 09:04 AM)J-F Garnier Wrote:  My suspicion is that the bug is in the code itself. If it works on a FN, it may be due to a flaw in the FN driver design, but it's not something you could rely on.

Well, it's still intriguing. Although I'm no more a HP41 power user, I take this enigma as a programming challenge. How a program can behave differently on a FN and on a HN machine?

Observation 1: the program (the SPLASH function) doesn't work in emulators and falls in a endless loop. An analysis of the program reveals that it can't work, and I even know a simple fix to make it work.

Observation 2: the emulators I know are implementing the display register behaviour as they are specified in various HP documents, user publications and reference books (such as the "MCODE for Beginners" from Ken Emery). No special treatment, no special cases, no difference between FN/HN. In this respect, the emulators are all right to fail with SPLASH.

So how SPLASH can work on a full nut machine?

Can some HP41 power users with the relevant hardware confirm the SPLASH behaviour, using the very files Angel posted above on these configurations:
- a genuine 41CV/CX (not CL!) with full nut display,
- a genuine 41CV/CX (not CL!) with half nut display,
- a 41CL (so with full nut display),
and report the results?

Next, what abnormal register behaviour could explain the "correct" execution of SPLASH on a full nut? I didn't find any.

J-F

[Ángel Martin]

Your observations are spot-on J-F, indeed it's not likely to be attributable to a different behavior of the display drivers between FN and HN machines,

You're also right the code had a wrong jump distance, and after correcting it it now runs flawlessly in all platforms. Finally the scrolling message on V41, 41X, etc...

It's still quite curious and suspicious that on the CL the execution was always uneventful even with the wrong jump distance in the code. That can only mean that there's something unique in way the CL emulates the display, something that made it more resilient to this problem. It could well be a coincidence but I'll try to do some further testing to identify the exact point of divergence..

Thanks much for researching this issue.