+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: Not HP Calculators (/forum-7.html)
+--- Forum: Not quite HP Calculators - but related (/forum-8.html)
+--- Thread: Bug in v41 and 41X emulation ? (/thread-16691.html)
Bug in v41 and 41X emulation ? - Ángel Martin - 04-19-2021 12:30 PM
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.
RE: Bug in v41 and 41X emulation ? - MeindertKuipers - 04-19-2021 01:39 PM
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?
RE: Bug in v41 and 41X emulation ? - rprosperi - 04-19-2021 03:30 PM
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.
RE: Bug in v41 and 41X emulation ? - Ángel Martin - 04-20-2021 11:31 AM
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.
RE: Bug in v41 and 41X emulation ? - J-F Garnier - 04-20-2021 12:37 PM
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
RE: Bug in v41 and 41X emulation ? - Ángel Martin - 04-24-2021 04:25 PM
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.
RE: Bug in v41 and 41X emulation ? - J-F Garnier - 04-25-2021 09:04 AM
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
RE: Bug in v41 and 41X emulation ? - J-F Garnier - 05-08-2021 10:07 AM
(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
RE: Bug in v41 and 41X emulation ? - Ángel Martin - 05-10-2021 03:28 PM
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.