Little challenge for HP-15C experts...

[J-F Garnier]

This challenge is basically for users of the genuine HP-15C, not the clones, but there are some implications to these clones especially the 15c CE that I may discuss later.

Reminder: When a key is pressed on the 15C, the display is blanked until the processing of the key is finished. For long processing (solve, integrate, matrix operations, and of course program runs) the blank display is replaced by the flashing 'running' message.
Example:
2 SIN -> blank display for about one second.
but 100 ENTER 50 Cx,y -> 'running' message for about 10s.

The challenge: find a regular, allowed condition (i.e. an operation with a defined argument) that produces a long blank display.
During that long blank state, the HP-15C looks inoperative: the operation can't be interrupted and the 15C can't be turned off/on.

I found a condition with a blank state of more than 15s .

J-F

[Gerson W. Barbosa]

(07-26-2024 03:35 PM)J-F Garnier Wrote:  I found a condition with a blank state of more than 15s .

I’m away from home and don’t have any of mine at hand, but I remember 69.5 CHS x! takes rather long to return the answer.

Gerson.

[J-F Garnier]

(07-27-2024 01:47 AM)Gerson W. Barbosa Wrote:  I’m away from home and don’t have any of mine at hand, but I remember 69.5 CHS x! takes rather long to return the answer.

You have good memory !

Indeed, computing x! (gamma) of large negative (non integer) numbers can take a lot of time, and there is no 'running' message in these cases.

The largest computing time (thus blank display time) is with -99.5, with a result of zero after more than 15s !
Computing gamma of non-integer numbers less than -100 is immediate with null result.


Now, why was I seeking for long blank states, that lead me to (apparently) rediscover the x! case ?
As I reported it before, we can't see this brief blank display during key processing with the 15c CE, contrary to the 15C and even the 15c LE, and this is IMHO a small inconvenience of this model, because we have no visual feedback of keystrokes that don't change the display content.

BUT, we can detect a very brief blank state with -99.5 x! on the 15c CE.
This is a bit hard to see, but is clear when we compare the effect of -99.5 x! with -100.5 x! (the later immediately returns 0)
This proves that blank states are not completely filtered out by the firmware, and so it should be possible to have this blank state feedback for all key processing.

J-F

[J-F Garnier]

Further analysis of the 'bank display' behaviour:

Manually doing -99.5 x! on the 15c LE (instead of the 15c CE) very clearly shows the blank display during the x! calculation on the LE.

Looping 100 times this short program with initial X=-99.5

01 LBL A
02 x!
03 LSTx
04 DSE I
05 GTO A
06 RTN

takes about the same 16-17s on both the 15c LE and CE, so the difference of blank display is not caused by a speed difference.

Explanation (attempt):

At the 15C microcode level, the display on/off state is managed by the DISOFF and DISTOG opcodes (resp. "display off" and "display toggle") as on the 41C.
There is no "display on" opcode, if the display state is unknown, the sequence DISOFF, DISTOG ensures that the display will be on.

My interpretation is that the blank display is filtered out by the 15c CE simulation firmware (that is, the X display is maintained even after the DISOFF opcode) to some extend, around 0.1s:

                key pressed                  end of key processing
                  DISOFF                        DISTOG
                  v                                 v
15C, 15c LE: |<---      dsp off      --->|
15c CE:        |<- 0.1s ->|<- dsp off ->|

Very likely, this has been done to help solving the issue of interaction between the blank display state and the blinking display in the 15c LE.
The two states are managed by different means: the blank display is managed by the 15C software with the DISOFF and DISTOG opcodes, whereas the blinking display is managed by hardware and just triggered by the DISBLK opcode (a Voyager-specific opcode).

Unfortunately the used solution completely masks the brief blank display used for keystroke visual feedback.

J-F

[Edit: replaced "15C-specific" with "Voyager-specific" regarding the DISBLK opcode - Thanks Mike! ]