Posts: 255
Threads: 22
Joined: May 2011
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...
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
Posts: 3,283
Threads: 104
Joined: Jul 2005
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
Posts: 3,229
Threads: 42
Joined: Jul 2006
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.
Posts: 255
Threads: 22
Joined: May 2011
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...
