Sluggish behaviour whilst in USR mode (specific test case)

[jonmoore]

Over the last week I've been in communication with Ángel Martin in an attempt to track down a 'bug' that I've noticed whilst using SandMath. We've reduced the repeatable steps down to a minimal configuration and a simple set of repeatable steps. To sense-check the set up we've also verified the errant behaviour doesn't also exist on hardware 41CL units, i41cx on iOS and V41 on Windows.

We think we've isolated one specific test case. But it's now reached a point where we need confirmation cases from others on the beta so this will obviously involve others 'state saving' their custom configurations so as to match this minimal test case setup:

Install these modules alone,
- Library#4, R54 or R55 (the latest two versions)
- SandMath 44 4x4 Q
Then,
- Remove all USR key assignments
- Using the new CST menu, configure the E key to the clear stack command, CLST

The test routine itself is very simple (be sure to be in Fast mode, preferably with USB power):

1.) Make sure your 41x is in USR key mode
2.) Enter 7441 on the keyboard
3.) Press XEQ/Alpha and enter PFCT (Prime Factorisation).
4.)Press Backspace once to clear the Alpha display
5.) Use your CST E hotkey to clear the stack
6,)Enter 4, then 5 on the stack
7.) Ensuring you're still in USR mode trigger Y^X (Shift/B)

All things being equal, you should now experience a second of so delay in every stack interaction.

To get rid of the sluggish behaviour, perform a CAT 1 scan (Shift/Enter/1). After the scan, any interaction delays should now be gone.

It's my guess that the bug is something to do with the new CST functionality as following the exact same steps but clearing the stack manually via XEQ/Shift/CLST (or by filling the stack with zero's) no longer displays the errant behaviour. I don't think it's something specific to Ángel's modules but in the case of the prime factorisation routine PFCT, this is one of those FOCAL routines that are called by MCODE, that should clear immediately once the action has been performed so maybe there's something about the FOCAL code that means that it's interacting in an odd manner with CST triggered routines.

Thanks in advance,

jm

[Ángel Martin]

I see the same issue. Looking for possible causes I noticed that using the CST screen "assignments" sets the program pointer below the curtain, i.e. "lost out there" and possibly the local label search gets very confused when we press "Y^X" (looking for LBL b). You can see that by switching to PRGM mode and SSTíng the listings (really the status registers and I/O buffer contents shown as program steps). Be careful and do not delete anything in there or you'll get a ML or lock up the calculator.

ÁM

[jonmoore]

Thanks for the confirmation at your end Ángel. And, thanks for digging a little deeper into the specifics of the problem.

[rprosperi]

Thanks for the report and details guys.

@jonmoore - I can't follow the steps exactly

In your step 3 "Press XEQ/Alpha and enter PFCT (Prime Factorisation)" do I press alpha again after spelling out PFCT, which would then execute that function?

From step 4, I guess PCFT result does an AVIEW which needs to be cleared (I have not tried it yet). Is this an essential step as it would seem to be unrelated to the flow?

If PFCT is not run (i.e. 2nd alpha is not pressed), then it seems PCFT was never executed and so would not be relevant?

Please clarify and I'll be able to try this later today.

@angel - if CST always left the curtain in the wrong place, then chaos should ensue whenever using it, no?

Thanks

[jonmoore]

In your step 3 "Press XEQ/Alpha and enter PFCT (Prime Factorisation)" do I press alpha again after spelling out PFCT, which would then execute that function?

Sorry Bob, I should have been more specific that you're meant to execute PFCT by pressing Alpha once more.

Clearing Alpha in step 4 refers to clearing the alpha overlay. In the case of the prime factorisation of 7441 the alpha overlay displays:

7441 = 7 * 1063

You're not actually deleting Alpha data, Backspace simply removes the Alpha overlay leaving the stack display of:

T - 7
Z - 7
Y - 1063
X - 7441

Does this clarify things?

[Ángel Martin]

@angel - if CST always left the curtain in the wrong place, then chaos should ensue whenever using it, no?

Certainly. I didn't say (or at least I didn't mean to say) this happens every time CST assignments are used, but it does occur when following this specific sequence of events is executed. Dunno why but this case triggers some limitations in the design.

[rprosperi]

Thanks both for your comments.

@jonmoore - yes this explains it exactly. I will try this shortly...

@angel - Do I understand correctly that this issue only occurs on the 41X following this sequence and only with Sandmath, however the same exact sequence with the same exact modules has no similar problem (e.g. being behind the curtain) on 41CL or CLONIX/NoV ?

If so, a truly bizarre circumstance, but these detailed notes should help.

What about this Sandmath function is atypical that may lead to odd mangling if followed by CST ?

Also, is the noted verison of Sandmath the same as the version in the .zip file on the support area? That file makes no mention of "Q", it shows version 8.8. Is that the correct file?

[rprosperi]

Using LIB #55 and the Sandmath module in the .zip file, I can confirm the reported issue.

Some additional questions:

@jon - Why is step 4 (clear Alpha) included? Since it appears to be unrelated, I tried both with and without this step and indeed the results are the same.

@angel - Can you describe steps you follow to see that we're under the curtain? After completing the reported steps, and seeing the long pause before seeing the 1024.0000 result, I go into PRGM mode and in my case, I am at line 00 of the empty program (I started the reported steps from MEM LOST).

[jonmoore]

Using LIB #55 and the Sandmath module in the .zip file, I can confirm the reported issue.

@jon - Why is step 4 (clear Alpha) included? Since it appears to be unrelated, I tried both with and without this step and indeed the results are the same.

Sure, you could execute CLST without first clearing the Alpha overlay. I added the extra step so as to provide clarity in respect to the execution step of Y^X that follows - simply habit on my part, but I think it's a good to clear the stack of clutter as you work (unless you need stack register data for further manipulation).

Not sure why I'm such a neat freak with regards to the stack, my studio workspace is anything but neat!

[rprosperi]

No problem at all, I am a habitual over-presser of [<-] myself (which is why RPL annoyed me so much initially...).

I simply thought that it was germain to the problem since it was in the noted procedure.

Thx