INPUT and weird stack behaviour

Please report all incorrect calculation results, meaning mathematically incorrect or inconsistent with the HP-32Sii (excluding the superior precision in the DM32), crashes, data-loss events, or other clearly wrong behavior. For complex situations, please be ready to submit a State File for analysis.
Post Reply
RaulLion
Posts: 93
Joined: Thu Apr 13, 2023 5:48 pm
Location: Spain
Contact:

INPUT and weird stack behaviour

Post by RaulLion »

Several of my 32SII programs that play with stack registers (Rup or down, ENTER, etc) are failing if I don't change the value showed by INPUT comand .
I've made this test:
- Put numbers 1, 2, 3 and 4 in stack: X, Y, Z and T; store 5 in register A
- Run this program:
LBL X
INPUT A
RTN

XEQ X and R/S without change value 5 in A register

My hp32SII ends with this stack:

T: 3
Z: 2
Y: 1
X: 5

but DM32 ends:

T: 2
Z: 1
Y: 5
X: 5

If I key a new value when INPUT is prompted, then DM32 ends with the same stack registers than hp32SII
hp41cv-hp15c-hp42s-hp32sii-hp48gx(2)-hp33s(pre-release)-hp35s-DM32

[hp48 + Metakernel + Erable + Alg48 + 20 years of stuff running on Emu48 for Android since 2019]
rprosperi
Posts: 1703
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: INPUT and weird stack behaviour

Post by rprosperi »

Thanks for this report, but I cannot duplicate this different result on a DM32.

Both (DM32 and 32Sii) behave as you describe for the 32Sii.

Possibly a key sequence error?
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
RaulLion
Posts: 93
Joined: Thu Apr 13, 2023 5:48 pm
Location: Spain
Contact:

Re: INPUT and weird stack behaviour

Post by RaulLion »

I've just taken this video:

https://photos.app.goo.gl/wFMENYp1qLdtcbGPA

Both from a "Memory clear".
hp41cv-hp15c-hp42s-hp32sii-hp48gx(2)-hp33s(pre-release)-hp35s-DM32

[hp48 + Metakernel + Erable + Alg48 + 20 years of stuff running on Emu48 for Android since 2019]
rprosperi
Posts: 1703
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: INPUT and weird stack behaviour

Post by rprosperi »

Thanks for confirming this.

I realized I was testing with a newer (not yet released) f/w build in which this has been corrected.

The fix for this will be in the next f/w release (which is not yet scheduled folks, for those about to ask...)

Thank you!
--bob p

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