(Almost) amusing WP34s bug(?)

[Neil Hamilton (Ottawa)]

Either interesting or (maybe) a battery killer...

The rate that the 'WHO' program zips through the messages is dependent on what base you are operating in.

All of the main bases (octal, decimal, and hex) run very fast -- can't quite make out the messages.

Binary stalls at the very first message -- I had to remove the batteries to get it back again. :-)

I haven't tried the all other bases but something tells me that a similar pattern will emerge.

Does this mean that PSE is base/mode dependent? I'll investigate some more.

Cheers...

[Walter B]

Neil,

Thanks for your observation. I could reproduce and extend your findings. Bases 7 and 4 work as fast as bases 8, 10, and 16. Base 3 leads to the same stall you observed with base 2. I consider this being a bug. We will look into that.

Walter

P.S.: A paper clip reset does it - no need to remove the batteries 8-)

Edited: 10 July 2011, 5:16 p.m.

[Marcus von Cube, Germany]

I'm wondering why a reset is necessary. Shouldn't any keyboard entry end a PSE? Might have to do with XROM.

Edit: I found it. Pauli's "Verschlimmbesserung":

#ifdef REALBUILD

DIG(5)

EEX

DIG(3)

DSZ(st(X))

BACK(1)

#else

PAUSE(8)

#endif

Edited: 10 July 2011, 6:01 p.m. after one or more responses were posted

[Paul Dale]

That conditional is the problem but removing it will introduce a different bug.

Now to figure out how to make this work in integer mode as well as real. Or do we just switch to real on entry like some of the other xrom routines...

- Pauli

Edited: 10 July 2011, 5:56 p.m.

[Neil Hamilton (Ottawa)]

Quote:

---

P.S.: A paper clip reset does it - no need to remove the batteries 8-)

---

Doh! I can always claim I didn't have a paper clip :-)

Anyway, it stopped what I assumed was large battery consumption...