HP Forums

I'm trying to work out exactly how all of these things interact. Here's a short example program:


The DELAY 8,8 (equivalent to INF,INF) keeps the displayed text on screen until you press a key. Pressing END LINE to dismiss the "TEST 1" display moves on to displaying "TEST 2". So far so good. Pressing END LINE again to dismiss "TEST 2" causes the END LINE keystroke to "fall through" to the INPUT, and you get an error message about numeric input being required.

Adding line 35 to empty the keyboard buffer prevents this from happening, but is there a more elegant way to handle this?


Also, it's somewhat disconcerting to press a key to dismiss DISP and have nothing on the display change indicating that the keystroke was accepted and the program has continued. For example:


What I'd like is a simple, clean way to make DISP behave like this:

1. Clear the keyboard buffer
2. Display its argument(s) and wait for a keystroke
3. Either display an indication that it's waiting for a keystroke, or clear the display after a key is pressed and the program continues (Sharp pocket computers opt for clearing the display after PRINT is dismissed)
4. Clear the keyboard buffer

Just to be clear, you want DISP to wait for a keystroke? Normally INPUT is used for this sort of thing.
Line 40 can be shortened to INPUT T.

Yeah, display something on the screen, then stop and wait until a key is pressed before continuing. DELAY 8,8 makes DISP work that way, but you have to manually clear the keyboard buffer with KEY$ afterward, or whatever key you pressed will perform its normal function as soon as you get to something like INPUT which reads the keyboard.

Run example 1 and press END LINE twice and you'll see what I mean.

Here's a little mockup that behaves the way I'd like it to work.


As you can see, it's a lot of code, so I'm wondering if there's a more elegant way to do this. Maybe a LEX file with a DISP replacement that behaves this way?

In other words, this process flow:

1. Display something on screen.
2. Stop and wait for a keystroke before continuing (don't care which key is pressed - any results from using KEY$ or KEYWAIT$ for this purpose can be discarded).
3. Clear the display to indicate that the program has resumed running.
4. Clear out the keyboard buffer so whatever key was pressed to continue after the pause isn't seen by any subsequent INPUT, or the command line, etc.

.
Hi, Dave:

(04-23-2021 12:24 AM)Dave Britten Wrote: [ -> ]Yeah, display something on the screen, then stop and wait until a key is pressed before continuing. DELAY 8,8 makes DISP work that way, but you have to manually clear the keyboard buffer with KEY$ afterward, or whatever key you pressed will perform its normal function as soon as you get to something like INPUT which reads the keyboard.

I've found myself in this exact situation oftentimes, when wanting to pause long outputs to be able to read/write them down, and the best solution I've found so far is:

- set DELAY INF
- when something gets displayed, the DELAY will stop the program allowing you to read the output for as long as you want
- press the Space key, [SPC], *not* [END LINE], the program will continue
- proceed to do the same for all other output lines, always pressing [SPC] to continue program execution

- if an INPUT then executes, a *single* space will appear as the first character, not multiple spaces

This causes no harm for numeric input, because the INPUT statement trims leading and trailing spaces, so just key in your number or numbers and press [END LINE] as usual to accept them.

If INPUT is asking for a string variable, the space appears as well as the first character but this doesn't cause any harm either, just key in the characters of your string and the initial space *won't* be added to them.

Examples:

1 DELAY INF @ DISP "TEST 1" @ DISP "TEST 2" @ INPUT X @ DELAY 0,0

or

1 DELAY INF @ DISP "TEST 1" @ DISP "TEST 2" @ INPUT X$ @ DELAY 0,0

Try them and see that your two presses of the [SPC] key result in just one single space as the first character in both inputs, which is irrelevant for the numeric input and doesn't get stored as part of the string variable for the string input.

The bottom line: using [SPC] instead of [END LINE] or any other key will mostly achieve what you want.

One caveat: should you use LINPUT instead of INPUT to enter a verbatim string into a string variable, then the space *will* be added as the first character in the string. However LINPUT is very rarely used and you can always add a TRIM afterwards.

V.

That's good to know that SPACE is a safer way to resume when dealing with the default pause behavior of DISP. Thanks.

I have to imagine there's a better way to clear the screen than saving the current DELAY settings, changing to DELAY 0,0, calling DISP with no arguments, and restoring the previously saved DELAY. I'm open to LEX files here.

(04-23-2021 01:18 AM)Dave Britten Wrote: [ -> ]I have to imagine there's a better way to clear the screen than saving the current DELAY settings, changing to DELAY 0,0, calling DISP with no arguments, and restoring the previously saved DELAY. I'm open to LEX files here.

To clear the display, you can use the GDISP trick: GDISP "".
However, the display buffer is not really cleared, just the LCD screen.

J-F

(04-23-2021 11:26 AM)J-F Garnier Wrote: [ -> ]

(04-23-2021 01:18 AM)Dave Britten Wrote: [ -> ]I have to imagine there's a better way to clear the screen than saving the current DELAY settings, changing to DELAY 0,0, calling DISP with no arguments, and restoring the previously saved DELAY. I'm open to LEX files here.

To clear the display, you can use the GDISP trick: GDISP "".
However, the display buffer is not really cleared, just the LCD screen.

J-F

Ah, I was wondering if that might work! Wasn't sure if that command would only set the specified columns starting from the left, and since it was time for bed I didn't experiment with it last night. This should work fine since I just want a simple way to blank the screen to indicate that the program has resumed crunching numbers.

So it seems like the simplest way to make DISP behave like PRINT on Sharp/Casio pocket computers is to first set DELAY 8,8, then follow DISP with K$=KEY$ @ GDISP "". And throwing away KEY$ is only really necessary if you know that DISP will be followed by something that will accept keyboard input (e.g. INPUT, or the program ending and returning to the command line).

(04-22-2021 12:39 PM)Dave Britten Wrote: [ -> ]Adding line 35 to empty the keyboard buffer prevents this from happening, but is there a more elegant way to handle this?

Only slightly more elegant, replace KEY$ with KEYWAIT$.
http://holyjoe.net/HP71/lexlist.htm

(04-23-2021 03:57 PM)Dave Frederickson Wrote: [ -> ]

(04-22-2021 12:39 PM)Dave Britten Wrote: [ -> ]Adding line 35 to empty the keyboard buffer prevents this from happening, but is there a more elegant way to handle this?

Only slightly more elegant, replace KEY$ with KEYWAIT$.
http://holyjoe.net/HP71/lexlist.htm

But that would add another pause on top of DISP pausing due to DELAY 8,8. You could set DELAY 0,0 instead to have KEYWAIT$ handle the pause instead of DISP, but then you can't scroll long outputs horizontally.

(04-23-2021 04:52 PM)Dave Britten Wrote: [ -> ]You could set DELAY 0,0 instead to have KEYWAIT$ handle the pause instead of DISP, but then you can't scroll long outputs horizontally.

Ah, the SCROLL statement is made exactly for this purpose: following a DISP it pauses execution, lets the user scroll the line if needed, and resumes execution after a key different from the left/right arrows is pressed.
SCROLL lets you specify the starting position, and doesn't eat the terminating key (you may still need a KEY$).

SCROLL is available is the FORTH/Assembler module, or in various LEX files (CUSTUTIL, STRUTIL, USERLIBA, ULIB52, ...).

Many solutions now...

J-F

(04-23-2021 06:25 PM)J-F Garnier Wrote: [ -> ]Ah, the SCROLL statement is made exactly for this purpose: following a DISP it pauses execution, lets the user scroll the line if needed, and resumes execution after a key different from the left/right arrows is pressed.
SCROLL lets you specify the starting position, and doesn't eat the terminating key (you may still need a KEY$).

SCROLL is available is the FORTH/Assembler module, or in various LEX files (CUSTUTIL, STRUTIL, USERLIBA, ULIB52, ...).

Many solutions now...

J-F

Cool, I'll have to check out those LEX files and see what other goodies they might hold.

I think my approach will be something like this:

GDISP "" after a DISP (or other pause) that's followed by lengthy processing, just to indicate that something is happening and the computer isn't still waiting for a keystroke.

K$=KEY$ to "eat" the keystroke that was used to continue after DISP when it's followed by something that accepts user input. I noticed it's sometimes useful to actually act on that keystroke so you can detect the up arrow and back up to the previous DISP, for example.

I do kind of wish the 71B had a pair of commands like Sharp computers' PRINT and PAUSE, or HP calculators' R/S and PSE, i.e. one that means "display and wait for a key before continuing", and one that means "display briefly and then continue", but the options it does have are workable enough I think.

Since the intended use is to ultimately resume execution after a long wait, you should strongly re-consider replacing KEY$ with KEYWAIT$, which puts the 71B into a sleep-like, low-power mode until a key is hit. KEY$ does appear to similarly just wait, but it's really running a near full program execution level inside (probably just looping and checking the key buffer), so if the calculations run for 30 secs and then you don't notice it has been waiting for another 30 secs, it's about the same as if the calculations ran for the full minute. KEY$ eats batteries for sure.

(04-23-2021 09:28 PM)rprosperi Wrote: [ -> ]Since the intended use is to ultimately resume execution after a long wait, you should strongly re-consider replacing KEY$ with KEYWAIT$, which puts the 71B into a sleep-like, low-power mode until a key is hit. KEY$ does appear to similarly just wait, but it's really running a near full program execution level inside (probably just looping and checking the key buffer), so if the calculations run for 30 secs and then you don't notice it has been waiting for another 30 secs, it's about the same as if the calculations ran for the full minute. KEY$ eats batteries for sure.

I'm not using KEY$ to implement the pause though, it's just there to clear the keyboard buffer after the pause. The DELAY 8,8 @ DISP ... does the pause. I simply don't want the key that was pressed "falling through" to later instructions that accept keyboard input, so gobbling it up with a single call to KEY$ gets rid of it before moving on.

(04-23-2021 09:33 PM)Dave Britten Wrote: [ -> ]

(04-23-2021 09:28 PM)rprosperi Wrote: [ -> ]Since the intended use is to ultimately resume execution after a long wait, you should strongly re-consider replacing KEY$ with KEYWAIT$, which puts the 71B into a sleep-like, low-power mode until a key is hit. KEY$ does appear to similarly just wait, but it's really running a near full program execution level inside (probably just looping and checking the key buffer), so if the calculations run for 30 secs and then you don't notice it has been waiting for another 30 secs, it's about the same as if the calculations ran for the full minute. KEY$ eats batteries for sure.

I'm not using KEY$ to implement the pause though, it's just there to clear the keyboard buffer after the pause. The DELAY 8,8 @ DISP ... does the pause. I simply don't want the key that was pressed "falling through" to later instructions that accept keyboard input, so gobbling it up with a single call to KEY$ gets rid of it before moving on.

Ok, then, ignore that. I really am not following this and why using DELAY INF to pause things - is this used to allow some static message to be scrolled left/right? I'd just use abbreviations...

Nah, just so I can stop the output and read it leisurely, then continue the program when I'm done reading. No different from putting an R/S in the middle of an RPN program, really. Sometimes you want an R/S (DELAY 8,8), sometimes you want a PSE (DELAY .85,.125 or whatever your preference). Makes it easier to read multiple outputs without the computer getting ahead of you.

(04-23-2021 10:16 PM)Dave Britten Wrote: [ -> ]No different from putting an R/S in the middle of an RPN program...

The exact 71B equivalent to RPN R/S is PAUSE and CONT or [f][+].

(04-24-2021 12:09 AM)Sylvain Cote Wrote: [ -> ]

(04-23-2021 10:16 PM)Dave Britten Wrote: [ -> ]No different from putting an R/S in the middle of an RPN program...

The exact 71B equivalent to RPN R/S is PAUSE and CONT or [f][+].

Code:

41C              71B
01 LBL "RS"      
02 "BEFORE"      
03 AVIEW         10 DISP "BEFORE"
04 STOP          20 PAUSE
05 "AFTER"
06 AVIEW         30 DISP "AFTER"
07 END

Yup, but that takes two keys to get the program running again. I wonder why HP didn't make the RUN key act like CONT when the SUSP annunciator is on. Anybody got a LEX file that does that?

Can you make a key assignment for it, on the RUN key? I assigned my own RUN key to be a destructive backspace and put it in "insert" mode (taking it out of "replace" mode).