## DM41X V2.1

Firmware announcements will be posted in this sub-forum
rprosperi
Posts: 1049
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

### Re: DM41X V2.1

cdmackay wrote:
Mon Nov 16, 2020 10:44 pm
excellent release, thanks!
grsbanks wrote:
Fri Nov 13, 2020 8:38 pm
[*]The XROM ID of a plugged-in module now shows on the "ROM Map" and "Module Page Info" pages.
I notice that the XROM# for LIBRARY4 (35) is not shown at either of the above.

PWRX's ROMLST, PG? & ROM? functions all show it, however.
All of those functions are in one of Angel's modules, author of LIB4, so it should be no surprise. Angel pointed this out as well.

However since 35 is not a valid XROM ID and therefore no conflict can occur, and LIB4 routines are not called that way anyhow, we opted to not show it. I think the total population of people that understand this discussion is now 4.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
pcscote
Posts: 140
Joined: Tue May 02, 2017 12:12 pm

### Re: DM41X V2.1

Just as a recap, a complete XROM entry is a 16 bits value
XROM module ID are between 1 and 31 (included, 5 bits used)
XROM function ID are between 0 and 63 (included, 6 bits used)
XROM prefix is 10100 so encoding is → 10100MMM MMFFFFFF

Code: Select all

XROM: 1: 1 → 10100:00001:000001 → 10100000 01000001 → 0xA041
XROM: 1:63 → 10100:00001:111111 → 10100000 01111111 → 0xA07F
XROM:31: 1 → 10100:11111:000001 → 10100111 11000001 → 0xA7C1
XROM:31:63 → 10100:11111:111111 → 10100111 11111111 → 0xA7FF

The first word in a 4K ROM page contains the XROM module ID.
To my knowledge, the value can be higher than 31 but the functions in it will not be callable by a FOCAL program.

Edit: removed invalid values and added the first word comment after reading Ángel post.
Last edited by pcscote on Wed Nov 18, 2020 5:19 am, edited 1 time in total.
[DM1x/DM1xL/DM41/DM41L/DM41X/DM42]
Ángel Martin
Posts: 109
Joined: Mon Apr 24, 2017 8:19 pm

### Re: DM41X V2.1

rprosperi wrote:
Tue Nov 17, 2020 1:43 am
cdmackay wrote:
Mon Nov 16, 2020 10:44 pm
excellent release, thanks!
grsbanks wrote:
Fri Nov 13, 2020 8:38 pm
[*]The XROM ID of a plugged-in module now shows on the "ROM Map" and "Module Page Info" pages.
I notice that the XROM# for LIBRARY4 (35) is not shown at either of the above.

PWRX's ROMLST, PG? & ROM? functions all show it, however.
All of those functions are in one of Angel's modules, author of LIB4, so it should be no surprise. Angel pointed this out as well.

However since 35 is not a valid XROM ID and therefore no conflict can occur, and LIB4 routines are not called that way anyhow, we opted to not show it. I think the total population of people that understand this discussion is now 4.
For the record: I think this is not the right call. Besides diagnostics purposes, the Library#4 has an XROM value of 35 for good reasons. If it's there by design, then why not show it?, and besides how would you tell if somehow it has been corrupt?

Using the argument not to show it because there can't be function calls conflicts with other modules is an artificial restriction, simply not applicable. Using the same rationale you could argue that it cannot be any module in page #4 except the HP diagnostics.
akaTB
Posts: 563
Joined: Tue May 02, 2017 1:56 pm
Location: Milan, Italy

### Re: DM41X V2.1

Ángel Martin wrote:
Tue Nov 17, 2020 7:33 am
For the record: I think this is not the right call. Besides diagnostics purposes, the Library#4 has an XROM value of 35 for good reasons. If it's there by design, then why not show it?, and besides how would you tell if somehow it has been corrupt?

Using the argument not to show it because there can't be function calls conflicts with other modules is an artificial restriction, simply not applicable. Using the same rationale you could argue that it cannot be any module in page #4 except the HP diagnostics.
I concur: it's there, just show it. Why not?
Greetings,
Massimo
ajcaton
-+×÷ left is right and right is wrong Casted in gold
cdmackay
Posts: 161
Joined: Fri Oct 05, 2018 8:33 pm
Location: Cambridge, UK
Contact:

### Re: DM41X V2.1

Cambridge, UK
41CL/DM41X 12/15C/16C DM15/16 71B 17B/BII/bII+ 28S 42S/DM42 32SII 48GX 50g 35s 30b/WP34S Prime G2
& Casios, Rockwell 18R
Dave Britten
Posts: 117
Joined: Wed Jun 14, 2017 9:27 pm

### Re: DM41X V2.1

The update installed just fine. However, two-key rollover appears to still be not working correctly (same behavior as the previous version). e.g. hold 1, press 2, release 1, release 2, and you get 122 on the stack.
rprosperi
Posts: 1049
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

### Re: DM41X V2.1

Dave Britten wrote:
Thu Nov 19, 2020 9:51 pm
The update installed just fine. However, two-key rollover appears to still be not working correctly (same behavior as the previous version). e.g. hold 1, press 2, release 1, release 2, and you get 122 on the stack.
This is unlikely to be changed any time soon; most likely never. Emulating precise 41 key rollover behavior would require dramatic changes needing a lot of work in the 41X and DMCP and that would also mess with the DM42 and DM43's current behavior, none of which are desirable or justified. Exactly emulating behavior which isn't particularly useful or dependable anyhow isn't a sensible way to use limited development resources.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Dave Britten
Posts: 117
Joined: Wed Jun 14, 2017 9:27 pm

### Re: DM41X V2.1

rprosperi wrote:
Fri Nov 20, 2020 2:57 am
Exactly emulating behavior which isn't particularly useful...
I'd wager you could find plenty of disagreement on this point, particularly from fast typers.
pcscote
Posts: 140
Joined: Tue May 02, 2017 12:12 pm

### Re: DM41X V2.1

Dave Britten wrote:
Fri Nov 20, 2020 3:05 am
rprosperi wrote:
Fri Nov 20, 2020 2:57 am
Exactly emulating behavior which isn't particularly useful...
I'd wager you could find plenty of disagreement on this point, particularly from fast typers.
Hand raised!
[DM1x/DM1xL/DM41/DM41L/DM41X/DM42]
Mark Hardman
Posts: 116
Joined: Wed May 03, 2017 3:26 am
Location: Houston, TX

### Re: DM41X V2.1

pcscote wrote:
Fri Nov 20, 2020 3:08 am
Dave Britten wrote:
Fri Nov 20, 2020 3:05 am
rprosperi wrote:
Fri Nov 20, 2020 2:57 am
Exactly emulating behavior which isn't particularly useful...
I'd wager you could find plenty of disagreement on this point, particularly from fast typers.
Hand raised!
Both hands raised--if you get my drift... ;-)

So you're saying that accurate digit entry isn't important? SM goes to the effort and expense of reworking the keyboard for that very same reason, but ignores a keyboard accuracy problem in the OS? Bob, this is one of the rare times I vehemently disagree with you.
DM42: β00043, β00065, 00357 / DM41X: β00054, 00445
DM10L: 017/100, DM11L: 00121, DM12L: 02005, DM15L: 00523, DM16L: 00008, DM41L: 00111