Sluggish behaviour whilst in USR mode (specific test case)

Please report issues with the DM41X Beta Firmware in this sub-forum
jonmoore
Posts: 106
Joined: Mon Apr 13, 2020 4:18 pm

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by jonmoore »

It's worth adding that I tested with both the Library#4/SandMath modules that Ángel provides in his zip and also with those published at hp41.org. The result was the same in each case.

In my offline conversations with Ángel I did ask whether recent changes to Library#4 could be responsible, but he assured that was very unlikely.

It's my suspicion that the bug isn't isolated to chains of events involving PFCT and CST triggered CLST executions, but it seems a good place to start as the errant behaviour is repeatable 100% of the time.
rprosperi
Posts: 1029
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by rprosperi »

I agree, having a reliable failure mode is the best way to track it down.

You mentioned this function is FOCAL, called my MCODE. From the CAT-2 listing, it appears PFCT is an MCODE function. Can you elaborate, as it could be relevant?
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
jonmoore
Posts: 106
Joined: Mon Apr 13, 2020 4:18 pm

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by jonmoore »

rprosperi wrote:
Mon May 18, 2020 9:19 pm
I agree, having a reliable failure mode is the best way to track it down.

You mentioned this function is FOCAL, called my MCODE. From the CAT-2 listing, it appears PFCT is an MCODE function. Can you elaborate, as it could be relevant?
My bad, this was an early guess of mine and Ángel didn't correct it, so I presumed I guessed right.
EM41
Posts: 151
Joined: Mon Mar 30, 2020 12:10 am
Location: Overijssel Netherlands

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by EM41 »

I can reproduce it perfectly.
Wnen you go to PRGM mode and press arrow down the behaviour disappears.
Like Angel sais CST puts the program pointer in an undefined area as the result of some previous function.
HP41C (2x), HP41CV, HP41CX, DM41X β, DM41X, DM42, HP11C, HP48G, HP97
User avatar
akaTB
Posts: 548
Joined: Tue May 02, 2017 1:56 pm
Location: Milan, Italy

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by akaTB »

rprosperi wrote:
Mon May 18, 2020 8:51 pm
No problem at all, I am a habitual over-presser of [<-] myself (which is why RPL annoyed me so much initially...).
Holy words.
Greetings,
    Massimo
ajcaton
-+×÷ left is right and right is wrong :twisted: Casted in gold
rprosperi
Posts: 1029
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by rprosperi »

EM41 wrote:
Mon May 18, 2020 9:49 pm
I can reproduce it perfectly.
Wnen you go to PRGM mode and press arrow down the behaviour disappears.
Like Angel sais CST puts the program pointer in an undefined area as the result of some previous function.
I understand what he wrote, but I can't see that; can you?

I know what PRGM mode looks like under the curtain, but I am not seeing that, so looking for some steps that will let me see that.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
rprosperi
Posts: 1029
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by rprosperi »

akaTB wrote:
Mon May 18, 2020 9:58 pm
rprosperi wrote:
Mon May 18, 2020 8:51 pm
No problem at all, I am a habitual over-presser of [<-] myself (which is why RPL annoyed me so much initially...).
Holy words.
LOL. Really! Out Loud!! :lol: :lol:
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
User avatar
PierreMengisen
Posts: 127
Joined: Wed Nov 29, 2017 1:38 pm
Location: Neuchâtel CH

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by PierreMengisen »

rprosperi wrote:
Mon May 18, 2020 9:19 pm
I agree, having a reliable failure mode is the best way to track it down.

You mentioned this function is FOCAL, called my MCODE. From the CAT-2 listing, it appears PFCT is an MCODE function. Can you elaborate, as it could be relevant?
By using the function HCI (Hyperbolic Cosine Integral), we have the same behaviour. (same module but from JM Baillard)
Pierre
[TI59 with PC100C; TI-84 Plus CE-T; HP41CV with HP IL loop & 2*82161A DCD & 82162 TP; HP15C; HP28S; DM41; DM41L; DM42; DM41X]
EM41
Posts: 151
Joined: Mon Mar 30, 2020 12:10 am
Location: Overijssel Netherlands

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by EM41 »

It doesn't only happen with the modules described.
I used the CK (clear keys) function from the PPC rom.

put the calculator in user mode
put the calculator on any program in memory
run CK
execute CST and the assigned clst function
now the stack is sluggish

if you go to PRGM mode the first line of the program reads 00 REG 271 (or other number)
arrow down, this 00 line disappears and also the sluggish behaviour.
And the more programs in memory the slower the reaction.
HP41C (2x), HP41CV, HP41CX, DM41X β, DM41X, DM42, HP11C, HP48G, HP97
rprosperi
Posts: 1029
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: Sluggish behaviour whilst in USR mode (specific test case)

Post by rprosperi »

Thanks for this other example EM41.

For me, I do not get sluggish behavior, but that could be because I have only a 4-step program in User RAM.

[UPDATE] - When not connected to USB, the sluggishness (is that a word?) can be felt.

But your example gives me a hint. Using CK in the PPC ROM leaves the program counter in ROM, which could be the common issue here. Seeing the PC in ROM could be why Angel was thinking it was below the curtain? Perhaps the Sandmath module does this as well (which is not a problem, but could be something which was not assumed.)

But I think the results might be the same if you followed those same steps but used XEQ "CLST". Since the PC is in ROM, pressing keys in upper rows will be sluggish (in USER MODE) as the OS is searching for LBL-b (in the case of Y^X).

But this is a good hint as to a possible cause.

Thanks!
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Post Reply