HP35s - Cause of Blank Screen Problem?



#33

The blank screen during a running program which is not interruptible seems to be caused by simply using an equation as a prompt to stop the program (i.e. without following the equation immediately by a PSE instruction) and wait for you to press R/S to proceed. Enter the following simple program (the label letter is unimportant):

X001 LABEL X
X002 SF 10
X003 eqn BLANKING DEMO
X004 100
X005 STO I
X006 DSE I
X007 GTO X006
X008 STOP
X009 1
X010 STOP
X011 2
X012 STOP
X013 3
X014 STOP
X015 4
X016 STOP
X017 5
X018 STOP
X019 6
X020 STOP
X021 7
X022 STOP
X023 8
X024 STOP
X025 9
X026 STOP
X027 10
X028 STOP
Now execute the program*. The program will display "BLANKING DEMO" and wait for you to press R/S. Press R/S, and the display will go blank, and it will not respond to R/S, C, or any other key. The program will stop after the DSE loop counts down from 100. If you press R/S while it is blank, it will execute the R/S commands from a buffer, which will execute the sequence of digit entry and STOP commands that start in line X009. (These are necessary to prevent the sequence of R/S commands that you entered from jumping into other programs.) If you press R/S less than 5 times, the x register will present the number of times you pressed it. If you press R/S 5 or more times, the x register will present a 5, as the buffer apparently holds up to five R/S commands. (The steps after line X019 are just there for insurance, I guess.)

As Seth and John reported, if you single-step once from the keyboard at the equation prompt, then press R/S, everything is fine. The program proceeds with the “RUNNING” display, and it can be interrupted with R/S or C.

So, if you use an equation as a prompt to display a message and wait for you to enter data and press R/S to proceed, and the program following the prompt does not terminate naturally, it will run with a blank display until the batteries run out or you press the reset through the hole in the back. For example, in the above program if instruction X008 was a GTO X004, the machine will be stuck in a loop from which you would will be unable to break it out of. (I did not try this as I don’t want to lock up my calculator and lose all programs.) I'm guessing that this is what happened in John W's original program; his rather complex, un-debugged program had such a loop.

Using equations as prompts to pause a program and give instructions or wait for data entry is a very handy feature. Just make sure the code that follows cannot enter an unending loop. A safe alternative is to put a STOP after the equation. The message will stay up until you press R/S once, then you will have to press it again to get going. Not ideal, but it beats locking up your calculator.

Hope this helps,

Best regards

Jeff

* - Enter and run at your own risk, as you may lock-up your calculator and lose all memory. It shouldn't if you enter it as listed, but....


edited to correct a typo and add a little clarification.

Edited: 19 Oct 2007, 11:24 a.m. after one or more responses were posted


#34

Brilliant! You've found it alright. This is a perfect test case.

For fun, I wrote the following program that I can guarantee will lock up your calculator until you do a hardware reset. It does not display "RUNNING" while it's working:

A001  LBL A
A002 SF 10
A003 LOCKUP DEMO
A004 0
A005 GTO A004

CAUTION: DO NOT RUN THIS PROGRAM ON ANY CALCULATOR THAT CONTAINS DATA YOU WISH TO KEEP. IT CAUSES A TOTALLY UNBREAKABLE INFINITE LOOP.

In contrast, here's a program that does NOT lock up, and displays 'RUNNING'.

B001  LBL B
B002 SF 10
B003 0
B004 GTO B003

The only difference is displaying an equation. The fact that Flag 10 is set seems not to matter.

Very interesting. Thank you so much for finding this, Jeff!

Edited: 18 Oct 2007, 10:54 p.m.


#35

OK, this is definitely it.

I've confirmed that if you run Program A, as above, and instead of pressing "R/S" after 'LOCKUP DEMO' is displayed, you press the down arrow to step to the next line, and THEN press "R/S", you can break out of the loop, and "RUNNING" is displayed.

Bingo, this is it. We have a good, small, repeatable test case we can send to HP. Thanks to all who helped!


#36

Very, very good work everyone.

Thank you all.

---

John

#37

Good job and great detective work!

FYI...HP now knows about the problem.

Gene


#38

Good news, Gene. Thanks for letting us know! If they need a small test case, the above programs should work. They take only a few seconds to key in.

Edited: 18 Oct 2007, 10:59 p.m.

#39

This bug is repeatable on the 33s. Nobody ever noticed.

On my 33s, I keyed in this program:

A0001  LBL A
A0002 SF 10
A0003 LOCKUP DEMO
B0001 LBL B
B0002 GTO B

To run, XEQ A, press R/S after "LOCKUP DEMO" is displayed. Just like on the 35s, the HP-33s goes into an infinite loop without displaying "RUNNING". There is no way to break out of it without pressing the reset button on the back.

Also just like the 35s, single-stepping past the EQN display, and then pressing R/S, results in normal behavior. "RUNNING" is displayed, and the loop can be broken by pressing R/S.

UNLIKE the 35s, however, pressing the reset button on the back for just a moment does not seem to erase my program memory. That's a key difference between the 33s and the 35s, apparently.

Edited: 19 Oct 2007, 12:07 a.m.

#40

Interesting additional information:

If I put a PSE instruction after X003 in the original program at the top of this thread, the behaviour changes as follows:

1) "RUNNING" does appear while the loop is executing.

2) But you still can't break out of it.

Stefan


#41

Hmmmm....

If I put the PSE instruction in, the program displays the message briefly, then continues, displaying "RUNNING". It responds immediately to a R/S or C keypress and stops as it should. It works fine on both of my units, which have CNA734 and CNA721 serial numbers.

Jeff


#42

Very odd (that it's different). I don't have the calc in front of me right now, so can't experiment further at the moment. However, for what it's worth, I also had a CF 10 instruction after the PSE.

Stefan


#43

If I put the CF 10 after the PSE, the program pauses to display the message, then continues with the "RUNNING" display, and can be interrupted with R/S or C. If I put the CF 10 before the PSE, the program stops to display the message, then you must press R/S, then it pauses briefly and then continues with the "RUNNING" display. It now behaves as you describe, it is unresponsive to R/S or C even though "RUNNING" is in the display. It also unresponsive to R/S or C during the brief pause after pressing R/S to proceed after the prompt.

Jeff


#44

Yes, you're right. I had the CF 10 instruction before the PSE. My intent wasn't to display the EQN in pause mode, but rather to just introduce a "speed bump" after the user pressed R/S in response to the prompt, in hopes that it would reset whatever silly state the calculator got into that made it uninterruptible (i.e. I was experimenting to find a workable workaround).

Apparently, I managed to reset the "don't-display-RUNNING" state, but not the "I-can't-hear-you!" state, which of course isn't much help. I wonder if resetting the calculator while RUNNING is in the display might be less destructive than when the screen is blank. I don't want to try this, because I don't want to wipe out the stuff I've got programmed.

Stefan

#45

With a PSE in it after the EQN I can break out with C or R/S. Without the PSE I'm stuck and have to do a hard reset. Serial is CNA 726...


EDIT: The User's Guide of the 35s shows a program for "Controlling the Fraction Display" (similar to the one with the same name in the 33s' guide, conveniently available as pdf). This program uses EQN for message display. And guess what?! There's a PSE -A N D- a STOP statement after every message.
I guess as I couldn't find any example encouraging John's creative usage of the EQN messages without PSE or R/S after it, the so induced unbreakable loop shouldn't be called a bug ;-)


Edited: 19 Oct 2007, 12:01 p.m.


#46

This is getting hard to follow!

Also, my unit has a large amount of code in it so I don't

want to take any risks with my own experimenting if possible.

Ideally I should like a prompt string to appear in StackY,

stopping the processor and inviting the user to enter data in
StackX of the display. If this can't be done then I want

a prompt string to appear in StackX, stopping the processor and
inviting the user to overwrite it with data entry.

I then want it to be safe to press R/S.

The reason why I want to do this is to prompt for

two data entry values, entered as data-ENTER-data-R/S.

Do we now know how to achieve this functionality?

Could someone summarise for me?

What is the latest advice on the sequence of

SF 10, CF 10, PSE, R/S steps that I should use

above and below an EQN PROMPT STRING, please?

----

John


#47

Quote:
Could someone summarise for me?

What is the latest advice on the sequence of

SF 10, CF 10, PSE, R/S steps that I should use

above and below an EQN PROMPT STRING, please?

----

John


As my understanding of the handbook goes, displaying an EQN after SF 10 is NOT a prompt, it's just and only a text message.



So my approach to show a message and have the user input data in x and y registers could be as follows:



LBL A

SF 10

EQN "Y= ENTER X= RS" \* or whatever you wish

PSE

STOP

STO X

R down

STO Y

VIEW X

PSE

VIEW Y

PSE

CF 10

RTN
#48

We don't know how to achieve this functionality.

SF 10 / EQN / CF 10 / PSE / ... will give you a "RUNNING" message, but you still can't interrupt it.

SF 10 / EQN / CF10 / ... will give you a blank screen after the user responds to the prompt, and you can't interrupt it.

SF 10 / EQN / PSE / CF 10 / ... works fine, but the program doesn't stop; it only pauses.

SF 10 / EQN / CF10 / R/S / ... will stop once more after the user enters the data. The user then has to press R/S a second time to continue, you'll get a "RUNNING" message, and you can interrupt it.


#49

Thanks Stefan. Clear and concise.

I note the point made by Menzeer in defence of the HP35s interpreter and he may be right that

SF 10 / EQN / CF10 / ...

..stops the calculator and displays a message but is is undocumented as a way of supplying a prompt. However, what is the use of a facility to display a message and stop the calculator if we cannot permit users to do stuff while it is stopped (like calculate a value then enter it), and is it not the case that using this method even to stop with a message in the display, and not actually enter data, produces an uninterruptible condition as soon as the user presses R/S ?

Menzeer, I am not happy with closing this as an issue, on the basis that it is the user's fault when the calculator locks up and he loses all his work. I know you are not saying exactly that but your point about this not being the 'proper' way to issue a prompt does nothing to encourage HP to eliminate the problem.

---
John


#50

John,

maybe I'm not to much of a programmer to understand your point.


I can only say that the programming languages I recall some bits of (FORTRAN 77, BASIC, C, C++) have two different statements for input and output. If you must, you can combine input and output in some way like:

Input "A=",A


But those are "higher" languages. The 35s also provides you with a separate method for each input and output, which will work properly to my present knowledge. Your way of prompting for an input is quite creative and works most of the times, saving even some bytes. But it's more kind of a hack and has its limitations. All I'm saying is that limitations of a hack shouldn't be called a bug.


#51

I disagree with you assessment that this is a hack. The manual clearly states that one can use EQN for displaying messages. Whether or not one uses this for input too, the program will become uninterruptible after such a message is displayed and the user press R/S to continue.

Every HP calculator ever made has let you do whatever you want while the program is stopped due to hitting a STOP instruction or a prompt on those calculators that have a prompting facility, and will then continue with whatever is in the stack when it is resumed using R/S.

Using EQN to prompt for input is the only mechanism the HP35s has if you want the prompt to be anything other than "V=?".

Stefan


#52

Stefan is right.

I have never programmed HP calculators before so I had no tricks borne of long experience up my sleeve, I simply interrogated teh manual to find out how to display an alpha string, and this was how I found FROM THE MANUAL that I had to do it.

HP DOES need to correct this, it IS a fault with the hardware.

Imagine the amount of stick the computer system manufacturer would get if there was an instruction code sequence used by a programmer somewhere on it a major computer network that could place it into a state where the processor could not be interrupted without deliberately crashing the system and erasing everything on the network. This is a micro equivalent of the same thing.


#53

And the only way the manual shows us to do it is with PSE and R/S right behind the EQN message.

BTW, if I want a nice user interface, I wouldn't do it on a keystroke programmable calculator. I'd just grab the 50G.


#54

Quote:
And the only way the manual shows us to do it is with PSE and R/S right behind the EQN message.

No, the manual shows us to do it with PSE if we want the message displayed only briefly, and without PSE if we want the program to stop until the user presses R/S.

So, the following program is perfectly valid, yet it crashes the calculator:

X001 LBL X
X002 SF 10
X003 EQN BYE BYE
X004 CF 10
X005 GTO X005

Stefan

Edited: 20 Oct 2007, 3:10 p.m.


#55

Would you refer me to where in the manual it says so? I can only find programming examples that use EQN for displaying a message not for having an input prompt.

As I pointed out above, it would be a nice thing to have the 35s combine output and input with one statement as in

INPUT "A=",A

but that is not the way the 35s does it.

As to your program, that has no input statement at all (and thus is no example that undermines my above statement): I concede that the manual does not explicitly say not to place an infinite loop directly behind an EQN message ;-)

But the program examples in the manual either use PSE and R/S or a VIEW after the EQN message (If you put a VIEW behind the EQN in your program, you can break out, I just tested that).

Which gives me the impression the HP programmers could not imagine someone wanting to do other than using EQN for commenting the output. To prevent creative programmers form falling in that "infinite loop trap" HP should either explicitly re-write the manual: "Only use EQN combind with PSE and R/S or VIEW" or give the user the means to break out of a program no matter if HP thought someone could want to program that way or not. (And if you want to call that a bug, it's OK with me!) ;-)


#56

Sorry, but I think you misunderstand. Even if you just use EQN to display a message, the calculator is uninterruptible after the user presses R/S to continue after the message. This whole input-vs-output thing is a red herring. No input is required to cause the calculator to hang.

Nowhere in the manual does it say that you have to follow an EQN message with a PSE or a VIEW. And nowhere in the manual is there an example where an EQN message is followed by an R/S (in the program).

It is true that my sample program has no input statement. But my sample program isn't requesting any input either, so it doesn't need an input statement. It is just displaying a message to the user, which is what EQN messages are for.

Consider the following made-up program:

... do a bunch of stuff ...
X123 EQN "1ST STUFF DONE"
... do a bunch of more stuff ...
X456 EQN "2ND STUFF DONE"
... do more stuff ...

Here EQN is being used purely for message purposes, to stop the program when some stuff has been done. The user can then press R/S to continue. But this makes the calculator uninterruptible. It would be ludicrous to suggest that this is a misuse of the EQN message functionality.

And finally, here's a program that uses EQN and VIEW precisely the way you insist it is intended to be used. It too is uninterruptible:

X001 LBL X
X002 SF 10
X003 EQN HERE COMES Y!
X004 CF 10
X005 VIEW Y
X006 PSE
X007 GTO X007

Note: the issue is not whether you should put an infinite loop after such a sequence. The issue is that infinite loops sometimes happen, whether due to a bug, a calculation that doesn't converge, or whatever. Replace line X007 with whatever code you like above. It will still be uninterruptible.

Stefan

PS. No matter how HP intended it to be used, it is simply unacceptable that it locks up the machine. Period. How would you feel if using the windshield wipers on your car when it wasn't raining would cause the brakes to fail?


#57

Quote:
And finally, here's a program that uses EQN and VIEW precisely the way you insist it is intended to be used. It too is uninterruptible:

X001 LBL X
X002 SF 10
X003 EQN HERE COMES Y!
X004 CF 10
X005 VIEW Y
X006 PSE
X007 GTO X007




Just tested it on my machine. It's most easily interrupted by pressing C.

EDIT: My bad! It locks it up, you're right!

BUT: if you do the program this way, omitting the CF 10 until the end, you can break out:


X001 LBL X

X002 SF 10

X003 EQN ABC

X004 VIEW Y

X005 GTO X005

X006 CF 10

Why is that????




Quote:
Nowhere in the manual does it say that you have to follow an EQN message with a PSE or a VIEW. And nowhere in the manual is there an example where an EQN message is followed by an R/S (in the program).




The program examples in the German manual of my 35s (which are identical to the examples in the pdf version of the 33s' manual) show either PSE and STOP (=R/S) or VIEW statements directly after the EQN message. But you're right, the manual doesn't say so ("Do it only this way!") explicitly.


Edited: 21 Oct 2007, 1:54 p.m.


#58

Quote:
BUT: if you do the program this way, omitting the CF 10 until the end, you can break out:

X001 LBL X
X002 SF 10
X003 EQN ABC
X004 VIEW Y
X005 GTO X005
X006 CF 10

Why is that????


Because you omitted the PSE after the VIEW Y.

Stefan

#59

A few more comments.

Quote:
Which gives me the impression the HP programmers could not imagine someone wanting to do other than using EQN for commenting the output. To prevent creative programmers form falling in that "infinite loop trap" HP should either explicitly re-write the manual: "Only use EQN combined with PSE and R/S or VIEW" or give the user the means to break out of a program no matter if HP thought someone could want to program that way or not. (And if you want to call that a bug, it's OK with me!) ;-)

Sorry, using a "message" facility to display a message is not what I would call "creative programming". I doubt that HP's programmers are that unimaginative.

Stefan


#60

Quote:
Sorry, using a "message" facility to display a message is not what I would call "creative programming". I doubt that HP's programmers are that unimaginative.

Stefan


No it isn't. Using the EQN message without any other statement as an input prompt, as John did, is what I called creative.


BTW I would be happy if it worked that way. I just have to see that the manual doesn't say it would and provides other means for input.


#61

Quote:
No it isn't. Using the EQN message without any other statement as an input prompt, as John did, is what I called creative.

But you said that the cause of the bug was that I was combining a prompt with input, and my point was that I wasn't. My programming is not expecting any input here. It's just stopping to display a message.

PS. Does anyone else seriously believe that the calculator locking up in these cases is (a) the programmer's fault, (b) a misuse of the EQN message facility, and (c) not a bug?!?!

Stefan


#62

Quote:
PS. Does anyone else seriously believe...

Now I know why I have the constant impression that we have a slight misunderstanding ;-) I was writing all this with - more or less - tongue in cheek - but obviously was not able to convey this. (Mental note to myself: must remember to use emoticons even more excessively ;-) I must admit I don't think about keystroke programming with the appropriate seriousness. As I wrote earlier (I think in the first post to John's original thread) I'd grab another calculator for this kind of program...I wouldn't bother debugging a 400 line program on the 35s and thus would never encounter this problem in real life ;-)


#63

I really thought my first "This is not a bug"-posting was unserious enough emoticonized... ;-)


Quote:
the so induced unbreakable loop shouldn't be called a bug ;-)

#64

Stefan,

I completely agree with everything you have stated. Use of an equation to stop a program and display a message prompting for input is entirely appropriate. You thought to do so, I thought to do, and John W thought to do so. I think the programmers at HP intended for it to be used this way. And as you say, even if it is used exactly as presented in the manual to only present a message, it results in a situation where the calculator can lock-up. It is most certainly a bug.

Jeff


Possibly Related Threads…
Thread Author Replies Views Last Post
  HP35s Program Four Slings Lift Calculation Jean-Marc Biram (Australia) 2 2,208 12-16-2013, 07:21 PM
Last Post: Jean-Marc Biram (Australia)
  HP35s Calculator Max Rope Tension Program Jean-Marc Biram (Australia) 10 4,377 12-12-2013, 12:03 AM
Last Post: Jean-Marc Biram (Australia)
  Prime screen scratches - Use a screen protector Eelco Rouw 11 3,336 11-19-2013, 10:16 PM
Last Post: Eddie W. Shore
  Stylus for Prime screen steindid 6 2,366 10-22-2013, 02:06 AM
Last Post: Alberto Candel
  Sending from graph to home or CAS screen Richard Berler 6 2,283 10-06-2013, 03:29 PM
Last Post: Tim Wessman
  HP48GX screen replacement Francisco Quiles 9 3,892 10-03-2013, 09:17 PM
Last Post: Francisco Quiles
  hp50g screen weird line Sok-khieng Chum Hun 2 1,617 09-10-2013, 08:11 AM
Last Post: Sok-khieng Chum Hun
  New screen on pictures of new Sharp EL-9950 Mic 4 2,082 06-10-2013, 10:40 AM
Last Post: Mic
  HP Prime should have higher resolution screen LHH 5 2,116 04-25-2013, 10:00 AM
Last Post: bhtooefr
  Creeping black pattern on HP-11C screen Larry Gagnon 6 2,103 04-12-2013, 10:09 AM
Last Post: Peter Murphy (Livermore)

Forum Jump: