Bug in v41 and 41X emulation ?
04-19-2021, 12:30 PM (This post was last modified: 04-19-2021 12:46 PM by Ángel Martin.)
Post: #1
 Ángel Martin Senior Member Posts: 1,251 Joined: Dec 2013
Bug in v41 and 41X emulation ?
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.
04-19-2021, 01:39 PM
Post: #2
 MeindertKuipers Member Posts: 138 Joined: Dec 2013
RE: Bug in v41 and 41X emulation ?
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?

Regards, Meindert
04-19-2021, 03:30 PM
Post: #3
 rprosperi Senior Member Posts: 4,947 Joined: Dec 2013
RE: Bug in v41 and 41X emulation ?
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.

--Bob Prosperi
04-20-2021, 11:31 AM (This post was last modified: 04-20-2021 11:32 AM by Ángel Martin.)
Post: #4
 Ángel Martin Senior Member Posts: 1,251 Joined: Dec 2013
RE: Bug in v41 and 41X emulation ?
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.
04-20-2021, 12:37 PM
Post: #5
 J-F Garnier Senior Member Posts: 550 Joined: Dec 2013
RE: Bug in v41 and 41X emulation ?
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
04-24-2021, 04:25 PM (This post was last modified: 04-24-2021 04:36 PM by Ángel Martin.)
Post: #6
 Ángel Martin Senior Member Posts: 1,251 Joined: Dec 2013
RE: Bug in v41 and 41X emulation ?
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.

Attached File(s)
04-25-2021, 09:04 AM (This post was last modified: 04-25-2021 12:05 PM by J-F Garnier.)
Post: #7
 J-F Garnier Senior Member Posts: 550 Joined: Dec 2013
RE: Bug in v41 and 41X emulation ?
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
05-08-2021, 10:07 AM
Post: #8
 J-F Garnier Senior Member Posts: 550 Joined: Dec 2013
RE: Bug in v41 and 41X emulation ?
(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
05-10-2021, 03:28 PM
Post: #9
 Ángel Martin Senior Member Posts: 1,251 Joined: Dec 2013
RE: Bug in v41 and 41X emulation ?
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.
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)