## Display test ... not 100% correct?

Discussion about the new DM41X calculator
Ángel Martin
Posts: 109
Joined: Mon Apr 24, 2017 8:19 pm

### Re: Display test ... not 100% correct?

mmmm... that's a good one. Just to be clear, this is not a bug - but a byproduct of the lower case character support. The patch in routine [MASK] in ROM2 does that trick. To my knowledge, the collateral effects reported here have no consequences to the normal operation of the system. The benefit of this patch is that your ALPHA text (and ASCII file content) can show all lower character letters directly, such as:

20201101-14321003.bmp (12.31 KiB) Viewed 243 times
BTW you're misinterpreting the number of characters placed in ALPHA, counting the colons on the right of the character as additional chars, and not as part of the same character. Yes I know it's confusing and misleading due to the behavior of the back arrow in ALPHA, which sometimes only removes the colon part of the character.

Yes this is funny, but not a new artifact: if you type the string ", , , ," ( that is the seven-character sequence comma-blank-comma-blank-comma-blank-comma) and now you use back arrow that also removes unexpectedly the blank character *together* with the comma at each pressing of the back arrow key... so ALPHA is empty with four BA strokes - not seven.. but wait, is that really so? Not quite, turn ALPHA off, and then ON again and what do you see? Or if you prefer it, try ALENG on those strings and see if it matches your own count.

And this also happens on V41 and the CL when the same modification is made in the O/S. If anything the bug is in the character deletion routine...

Yes it'd be possible to revert to the original mainframe ROMS - but will you give up the lower case capability to reconcile those fringe cases?

ÁM
toml_12953
Posts: 683
Joined: Wed May 03, 2017 7:46 pm
Location: Malone, NY USA

### Re: Display test ... not 100% correct?

Ángel Martin wrote:
Mon Nov 02, 2020 1:38 pm

Yes it'd be possible to revert to the original mainframe ROMS - but will you give up the lower case capability to reconcile those fringe cases?

ÁM
I would give up lowercase. Compatibility is more important to me than new features.
Tom L

If I buy someone a drink to congratulate them, is it a Mazel Tov cocktail?

DM10L SN: 059/100
DM41X SN: 00023 (Beta)
DM41X SN: 00506 (Shipping)
DM42 SN: 00025 (Beta)
DM42 SN: 00221 (Shipping)
akaTB
Posts: 548
Joined: Tue May 02, 2017 1:56 pm
Location: Milan, Italy

### Re: Display test ... not 100% correct?

Ángel Martin wrote:
Mon Nov 02, 2020 1:38 pm

Yes it'd be possible to revert to the original mainframe ROMS - but will you give up the lower case capability to reconcile those fringe cases?

ÁM
No.
Greetings,
Massimo
ajcaton
-+×÷ left is right and right is wrong Casted in gold
ecsfang
Posts: 26
Joined: Sun Jan 26, 2020 5:21 pm
Location: Lund/Sweden

### Re: Display test ... not 100% correct?

Hi Ángel,

Thanks for your reply - and explanation!

No, I don't want to roll back to not having lower case alphabet
(Sorry for messing thing up - since the original questions was not related to lower case characters.)

My question is why all characters in range 128-255 shows as two (a character followed by a colon) on the DM41X (or go41) when in alpha register (but not on the HP41 or v41 where it always is a single full segment character).

Eg. "96 XTOA" gives lower case A, ie. 'a', but "129 XTOA" gives lower case A followed by a colon, ie. 'a:'.
And if byte 129 is part of a text in a program line (line 06 below), then in multi line prgm mode it shows as 'Ä' (full man symbol, code 1), but in SI+AR the same line shows up as "a:".
20201102-14560812.bmp (12.31 KiB) Viewed 208 times
20201102-14553377.bmp (12.31 KiB) Viewed 208 times
I also noticed that some new characters in the range 128-255 are available, eg. "145 XTOA" shows a small delta character (followed by a colon ...).
(Note that these characters are not available in program mode, there all characters are shown as characters in the range 0-127, eg. code 129 (0x81) is shown as code 1 (0x01) as shown above).

I totally agree with you that this is not a bug, but the calculator doesn't show what I expected it to show, I had hoped that character 128-255 would show up as a single character in all places (alpha, program etc) which could be used in normal programs (ie. lower case characters etc), but it doesn't ...

Well, not all true, one could eg. have a prompt that shows the result as a delta value, "d:0,4236" but not "d=0,4236"
20201102-16095345.bmp (12.31 KiB) Viewed 208 times
Best regards,
Thomas
[35/45/65/67/25/29C/31E/33E/41C|CV|CX/71B/10C/11C/15C/16C/32SII/42S/28S/48GX/49G/35S/DM41X(#00456)]
(7397)[134]
Ángel Martin
Posts: 109
Joined: Mon Apr 24, 2017 8:19 pm

### Re: Display test ... not 100% correct?

toml_12953 wrote:
Mon Nov 02, 2020 3:11 pm
Ángel Martin wrote:
Mon Nov 02, 2020 1:38 pm

Yes it'd be possible to revert to the original mainframe ROMS - but will you give up the lower case capability to reconcile those fringe cases?

ÁM
I would give up lowercase. Compatibility is more important to me than new features.
With all due respect that's absurd, in my humble and totally ignore-able opinion.
Also Lower case chars are available on the Half-Nut, so here's fidelity to the original for you.
Ángel Martin
Posts: 109
Joined: Mon Apr 24, 2017 8:19 pm

### Re: Display test ... not 100% correct?

ecsfang wrote:
Mon Nov 02, 2020 4:13 pm
Hi Ángel,

Thanks for your reply - and explanation!

No, I don't want to roll back to not having lower case alphabet
(Sorry for messing thing up - since the original questions was not related to lower case characters.)
Glad to hear that!

ecsfang wrote:
Mon Nov 02, 2020 4:13 pm
My question is why all characters in range 128-255 shows as two (a character followed by a colon) on the DM41X (or go41) when in alpha register (but not on the HP41 or v41 where it always is a single full segment character).
In binary, 127 = 01111111 but adding one more (128=10000000) requires bit(7) to be up, which is the trigger to the OS to show a colon next to the char,

Not sure you're comparing the same circumstances in both cases. For instance, here's the way four character 128 look like on V41 when the O/S has the same patch:
Capture.PNG (19.82 KiB) Viewed 189 times
looks familiar, right? it's exactly the same as the 41X rendering.

The colon appears there because digit C<1> in the [S&X] field of the char$value triggers it, This is all due to the way colon, comma and decimal point are handled on the LCD, not as separate characters but by applying a mask to the "previous" char. Note I said "on the LCD", which is different from "in the ALPHA registers" - and therein lies all the dichotomy that manifests when using the back-arrow in the examples mentioned before. ecsfang wrote: Mon Nov 02, 2020 4:13 pm Eg. "96 XTOA" gives lower case A, ie. 'a', but "129 XTOA" gives lower case A followed by a colon, ie. 'a:'. And if byte 129 is part of a text in a program line (line 06 below), then in multi line prgm mode it shows as 'Ä' (full man symbol, code 1), but in SI+AR the same line shows up as "a:". 20201102-14560812.bmp 20201102-14553377.bmp I also noticed that some new characters in the range 128-255 are available, eg. "145 XTOA" shows a small delta character (followed by a colon ...). (Note that these characters are not available in program mode, there all characters are shown as characters in the range 0-127, eg. code 129 (0x81) is shown as code 1 (0x01) as shown above). I totally agree with you that this is not a bug, but the calculator doesn't show what I expected it to show, I had hoped that character 128-255 would show up as a single character in all places (alpha, program etc) which could be used in normal programs (ie. lower case characters etc), but it doesn't ... Well, not all true, one could eg. have a prompt that shows the result as a delta value, "d:0,4236" but not "d=0,4236" 20201102-16095345.bmp The patch used in the [MASK] routine in ROM2 needs to be in-place, what I mean is it cannot call another subroutine where - potentially - we could add more finesse to the selectivity of the algorithm. If we added that call the RTN stack will overflow! So in summary, the starburst chars in the original machine are a way to "declare defeat", i.e. the OS is not capable to show any of those chars so it always uses startburst as a surrogate. There's no information as to which character it is, so the "colon-byproduct" at least tells them apart, which in my book is preferable. AND it correctly shows all the lower-case alphabet of course... Cheers, ÁM Last edited by Ángel Martin on Mon Nov 02, 2020 6:31 pm, edited 4 times in total. toml_12953 Posts: 683 Joined: Wed May 03, 2017 7:46 pm Location: Malone, NY USA ### Re: Display test ... not 100% correct? Ángel Martin wrote: Mon Nov 02, 2020 5:19 pm toml_12953 wrote: Mon Nov 02, 2020 3:11 pm Ángel Martin wrote: Mon Nov 02, 2020 1:38 pm Yes it'd be possible to revert to the original mainframe ROMS - but will you give up the lower case capability to reconcile those fringe cases? ÁM I would give up lowercase. Compatibility is more important to me than new features. With all due respect that's absurd, in my humble and totally ignore-able opinion. Also Lower case chars are available on the Half-Nut, so here's fidelity to the original for you. Can the half-nut run the test OK? If not then I have no objection to the current situation since the 41X is compatible with it. If the half-nut has lowercase and can run the test without flaws, then I would like the 41X to be 100% compatible with that. My main goal is to run programs exactly the way an original 41 did. If there's a difference between half-nut and full-nut, then I'd like compatibility with the one that gives more features (e.g. lowercase) Tom L If I buy someone a drink to congratulate them, is it a Mazel Tov cocktail? DM10L SN: 059/100 DM41X SN: 00023 (Beta) DM41X SN: 00506 (Shipping) DM42 SN: 00025 (Beta) DM42 SN: 00221 (Shipping) toml_12953 Posts: 683 Joined: Wed May 03, 2017 7:46 pm Location: Malone, NY USA ### Re: Display test ... not 100% correct? toml_12953 wrote: Mon Nov 02, 2020 5:44 pm Ángel Martin wrote: Mon Nov 02, 2020 5:19 pm toml_12953 wrote: Mon Nov 02, 2020 3:11 pm I would give up lowercase. Compatibility is more important to me than new features. With all due respect that's absurd, in my humble and totally ignore-able opinion. Also Lower case chars are available on the Half-Nut, so here's fidelity to the original for you. Can the half-nut run the test OK? If not then I have no objection to the current situation since the 41X is compatible with it. If the half-nut has lowercase and can run the test without flaws, then I would like the 41X to be 100% compatible with that. My main goal is to run programs exactly the way an original 41 did. If there's a difference between half-nut and full-nut, then I'd like compatibility with the one that gives more features (e.g. lowercase) BTW, no one's opinion should be ignorable. Tom L If I buy someone a drink to congratulate them, is it a Mazel Tov cocktail? DM10L SN: 059/100 DM41X SN: 00023 (Beta) DM41X SN: 00506 (Shipping) DM42 SN: 00025 (Beta) DM42 SN: 00221 (Shipping) Ángel Martin Posts: 109 Joined: Mon Apr 24, 2017 8:19 pm ### Re: Display test ... not 100% correct? toml_12953 wrote: Mon Nov 02, 2020 5:44 pm Can the half-nut run the test OK? If not then I have no objection to the current situation since the 41X is compatible with it. If the half-nut has lowercase and can run the test without flaws, then I would like the 41X to be 100% compatible with that. Which test, the FOCAL implementation on the PPC ROM(DT) or the MCODE version in the OS/X (DTST)? And why does running the PPC DT version become such an imperative to jettison such an useful feature as showing lower-case characters? It beats me. toml_12953 wrote: Mon Nov 02, 2020 3:11 pm My main goal is to run programs exactly the way an original 41 did. If there's a difference between half-nut and full-nut, then I'd like compatibility with the one that gives more features (e.g. lowercase) I can understand that, but have you found an example where such compatibility is lost? So far we're only discussing why the starburst don't show like starburst anymore...' Last edited by Ángel Martin on Mon Nov 02, 2020 6:09 pm, edited 2 times in total. dlachieze Posts: 257 Joined: Thu May 04, 2017 12:20 pm Location: France ### Re: Display test ... not 100% correct? Ángel Martin wrote: Mon Nov 02, 2020 5:36 pm The colon appears there because digit C<1> in the [S&X] field of the char$ value triggers it, This is all due to the way colon, comma and decimal point are handled on the LCD, not as separate characters but by applying a mask to the "previous" char. Note I said "on the LCD", which is different from "in the ALPHA registers" - and therein lies all the dichotomy that manifests when using the back-arrow in the examples mentioned before.
To illustrate that and bring some background on the 41C LCD display, lets look to the service manual:
The display is a 12-character, liquid crystal display (LCD). Each character position has 14 digit segments, 3 punctuation marks, and 1 annunciator space which are defined by three row lines (common to all characters) and six column lines. (See figure 2-2.) The entire display constitutes a 3-row by 72-column matrix which is activated by the display driver.

So in addition to the punctuation marks, each character position includes also one of the 12 annunciators: BAT USER G RAD SHIFT 0 1 2 3 4 PRGM ALPHA
DM42: 00425 - DM41X: β00066