WP 34S programming question
#1

I know how to display an alpha string in the dot-matrix part of the display, and how to use this to prompt for numeric input. However, as soon as a number starts to be entered, the dot-matrix part of the display is cleared, removing the prompt.

My questions:

(a) Is there a way to "freeze" the dot-matrix part of the display, so that the message is preserved while a number is entered?

(b) If not, could there be?

Thanks in advance for any suggestions!

Nigel (UK)

PS The triangle-solving routine (included in calc_full.bin) is amazing!

#2

Quote:
(a) Is there a way to "freeze" the dot-matrix part of the display, so that the message is preserved while a number is entered?

No, the behaviour is intentional even if it might not be the best possible solution.
Quote:
(b) If not, could there be?

Not with the current software.
#3

Quote:
PS The triangle-solving routine (included in calc_full.bin) is amazing!

Hey, thanks Nigel, finally someone who likes one of my programs! :-)

(you should see my TRIGON version for the TI-92+, even much better!)

Franz

#4

Thanks for pointing me to it. I didn't even know it was there.

#5

It's a really nice example of what the WP 34S can do. The user interface works well and the code is very instructive. Thank you for providing it. I've started seeing triangles everywhere now!

Nigel (UK)

#6

Thank you for your answer. If I forget what I'm supposed to be entering (which seems to happen more often than it should!) I can always press Shift-alpha to redisplay the alpha register, and then ENTER to leave alpha mode. Executing VW[alpha]+X is even better, but takes too many keystrokes!

Regarding this last point, I have another question. I've written a short routine:

LBL 21
VW[alpha]+X
RTN

and put this after my main program's final RTN but before its END. When the main program pauses for input and I start entering a number, I call this via XEQ STO or XEQ 21. It re-displays the alpha register and the X register nicely, but afterwards the program pointer is left pointing to the LBL 21 step, rather than the step it was pointing to when I called XEQ 21. (I have version 2747 of the firmware.) Should this happen?

Nigel (UK)

#7

Quote:
I can always press Shift-alpha to redisplay the alpha register, and then ENTER to leave alpha mode.

Nigel,

When I want to re-display a prompt, I simply press up-arrow (back-step) and then down-arrow (single step). Up-arrow then R/S will also do the trick. (Admittedly, this is on v2.2, I presume it would work on v3.)

Edited: 5 Apr 2012, 9:10 a.m.

#8

Brilliant! Exactly what I wanted. I'm still curious about why my subroutine call doesn't return to where I expected, but this certainly solves my original problem. Thank you very much.

Nigel (UK)

#9

Quote:
I'm still curious about why my subroutine call doesn't return to where I expected

IIRC Marcus mentioned some time ago that any manually executed XEQ (among a few other instructions) destroys the program counter. So when a program stops (prompts for input) and you do any XEQ, you can't continue the program anymore.

Edited: 5 Apr 2012, 10:32 a.m.

#10

Quote:
I've started seeing triangles everywhere now!

Oops, that's indeed dangerous: that's the first sign of a serious disease! ;-)

Franz

#11

That's not quite intentional. XEQ STO is supposed to put the PC back to were it was when the call was placed. There have been some changes (not very recently) so I have to check this by looking at the sources. IIRC there was an internal discussion about this behaviour which I have to re-read.

#12

Quote:
That's not quite intentional. XEQ STO is supposed to put the PC back to were it was when the call was placed.

Well, maybe not intentional but this is in fact the current behaviour.

I've tried it with this short program:

LBL A
5
STOP
SQRT
RTN
LBL 21
x^2
RTN
Run it with [A], when it stops at STOP (with 5 in the display) then excute XEQ STO (or XEQ 21) manually, and you'll see that the program counter is at LBL 21 and not at SQRT.

Thus of course a R/S doesn't continue the main program (SQRT) but runs the subroutine LBL 21 again.

Edit: I've now tried exactly the same on the last V2.2 version, and there it works as expected: after the manual XEQ 21 the program counter is still in the main program at SQRT.

So it's definitely a bug introduced anywhere in V3.

Franz


Edited: 7 Apr 2012, 10:44 a.m.

#13

I've now tried this with a few of my SVN backups and the bug has been introduced between SVN 2318 (which is still ok) and SVN 2371 (where restoring the program counter doesn't work anymore).

I hope this makes it a bit easier to locate this bug ...

Edit1: looking at the SVN revisions I saw that from SVN 2350 to SVN 2351 (and also in SVN 2356) there have been made some changes to the RTN/SST handling - a good chance for the source of this bug. ;-)

Edit2: a few more trials and now it's clear: SVN 2351 is still working but SVN 2356 fails, and there were also changes to RTN: "Changed behaviour of unpaired RTN: Goto last label XEQted respectively program begin. Manual RTN still goes to 0."

Franz


Edited: 7 Apr 2012, 11:20 a.m.

#14

Franz, I've done something about it.

It was a deliberate change with the aim to place the PC within the scope of a program selected by XEQ'...' from the keyboard or the catalogue. I've now changed it to leave the PC alone when the call goes to a local label (no change of the current program). Will be committed soon...

#15

Quote:
I've now changed it to leave the PC alone when the call goes to a local label (no change of the current program).

Thanks Marcus, I've already downloaded your fix (but not yet tried it).

But "when the call goes to a local label" makes me curious: does it really only work with local labels? Why not for all (i.e. also global) labels?

I know this return stack is quite tricky, but if I make a XEQ to a global label from within a program, then the RTN (or END) of this global subroutine also returns to the calling main program, so why shouldn't the same work for a manual XEQ of a global label?

Imagine the following situation:

You have a program which prompts for any input, but the number you enter should first be manipulated in any way (by another global program/label). So you enter the number, execute this other (global!) routine with XEQ, and then press R/S to continue your main program. Would this work with your bugfix now or not?

I think it should work, and I see no reason what would be the problem with the return stack or program counter after XEQing a global label. Whenever you are WITHIN any program (i.e. the return stack is not empty), then a RTN in any executed program (whether called by a program or manually, and whether the label is local or global) should return to the last program counter, which is the location from where this label was executed.

Franz

Edited: 7 Apr 2012, 12:02 p.m.

#16

Franz, as already stated, it's intentional. From my point of view a global label points to an application, so calling it with XEQ shall leave the PC within the bounds of the program to make the local labels and hot keys accessible. You might argue that the program could use STOP instead of RTN but this will cost a return stack level which is undesirable.

I've changed the behaviour for local labels which now leave the PC where it was when accessed through the keyboard.

#17

Quote:
Franz, as already stated, it's intentional. From my point of view a global label points to an application, so calling it with XEQ shall leave the PC within the bounds of the program to make the local labels and hot keys accessible.

Well, I agree if this XEQ is called when you are NOT WITHIN a program (i.e. when the return stack is empty) - in this case it should behave as you described.

But if called while another program is pending (e.g. waiting for an input), it should indeed return to the pending program. As it is now you just can't make a collection of global routines which could be used in any situation (also while you run another program).

That's not a good design decision IMO - but I'm afraid I'll have to accept it ... :-(

Franz

#18

Quote:
But if called while another program is pending (e.g. waiting for an input), it should indeed return to the pending program. As it is now you just can't make a collection of global routines which could be used in any situation (also while you run another program).

Franz, that sounds to me like talking about a full fledge operating system controlling a number of user programs competing for CPU time. The WP 34S is far simpler - one user program takes the processor time exclusively. It will remain this way.

Edited: 7 Apr 2012, 1:10 p.m.

#19

When the return stack isn't empty and you do an XEQ something, the return stack is cleared, again for a reason: A manual XEQ is considered a 'start over' operation, voiding any subroutine calls pending so far. An application should never STOP in the middle of a subroutine to accept input. This is considered a task for the top level thread of execution.

#20

Quote:
Franz, that sounds to me like talking about a full fledge operating system controlling a number of user programs competing for CPU time. The WP 34S is far simpler - one user program takes the processor time exclusively. It will remain this way.

Come on, Walter, I'm not talking about a multi-tasking system for the WP34s! ;-)

All I want is being able to XEQ a simple math routine while I'm prompted for an input.
#21

Quote:
An application should never STOP in the middle of a subroutine to accept input. This is considered a task for the top level thread of execution.

This IS a task for the top level program!

What I mean is: if any program (top level!) makes a STOP or PROMPT, I want to do some simple calculations with my own routines (including XEQ a global label) with any value I want to enter, before the program should continue with this 'manipulated' value.

Example: I want to create my own library of special math functions, and of course I have to use global labels for each routine, else I couldn't call it from everywhere.

And now I want to use exactly these routines also while I'm entering anything in a prompting (main) program.

Is that really so hard to understand?

And I'm quite sure that I can do this with any other programmable (HP) calculator, too!

Franz

#22

I just tried it on my 15C LE with the following program:

001 LBL A
002 1/x
003 RTN
004 LBL B
005 STOP
006 RTN

Hitting f B results in the PC pointing to step 006 as expected. If I hit f A, the PC is returned to step 000 and not back to 006. f A and GSB A are treated the same. The behaviour of WP 34S is friendlier in this respect.

Edit: A similar test on the 42S positions the PC after the RTN statement that has returned the control to the user. Still not the behaviour you are asking for.

Edit again: The 21S and the 33S all behave like the 15C.


Edited: 7 Apr 2012, 4:09 p.m.

#23

Quote:
(a) Is there a way to "freeze" the dot-matrix part of the display, so that the message is preserved while a number is entered?

I just tried what the 42S does when executing AVIEW: It displays the alpha register in the top row and X int the bottom row. As soon as I press a key, the top row reverts to the normal display of Y. The WP 34S bahaviour is similar.
#24

Quote:
Still not the behaviour you are asking for.

Well, if that's true then it's definitely a serious flaw of these HP calcs.

But I always thought (at least until today) that the WP34s should (and would) be a power calculator, so being able to run another subroutine while the main program has (temporarily) stopped should indeed be possible (and certainly not difficult to implement). IMO it's no excuse at all that other (less powerful) HP calculators also can't do that correctly.

BTW, versions before SVN 2356 did behave exactly as I described it: they just returned to the current PC even after a XEQ to a global label.

Not being able to call a global subroutine during a program stop/prompt is almost the same for me, as if I would only be allowed to directly enter a number but not using any intrinsic functions (e.g. 3 SIN) - just like such a SIN doesn't throw you out of the program, any XEQ shouldn't do that, too.

Edited: 7 Apr 2012, 4:55 p.m.

#25

Quote:
As soon as I press a key, the top row reverts to the normal display of Y. The WP 34S bahaviour is similar.

Perhaps this is a question more suited to Pauli or Walter, but do you know whether any consideration was ever given to allowing a 34S display mode where the dot matrix would show the value of Y while the segment row showed X? I know how short the dot matrix is, but even the left end of it might even be somewhat useful.

Thanks,
Jake

#26

We did briefly consider this possibility way way back for complex number display. 42 pixels wide is a pretty nasty limitation. More so once you consider that we're putting various annunicators in the same region -- actually we've pretty much filled the dot matrix portion with annunicators.


- Pauli

#27

I concur but even 43 pixels are not enough ;-)

@Jake: Considering scientific notation, even the small font won't help. I hate to repeat: the display is the worst constraint of the 20b/30b.

#28

Quote:
When the return stack isn't empty and you do an XEQ something, the return stack is cleared, again for a reason: A manual XEQ is considered a 'start over' operation, voiding any subroutine calls pending so far.

Well, I think I should resurrect this topic, because I'm wondering why Pauli hasn't yet jumped into this thread and told us his opinion about it!?

Marcus, for 'jumping' into a subroutine or program (i.e. doing a 'start over' as you call it), we have 2 other ways:

1) selecting this subroutine with [h]CAT and then ENTER

2) going to this subroutine via [h]GTO'...'

But a XEQ'...' should indeed do what such a subroutine call does in EVERY programming language: execute this subroutine and then return to the position from where it was called (wherever this was).

Sorry, but that's my opinion,

Franz

Edited: 10 Apr 2012, 4:37 a.m.

#29

Quote:
Well, I think I should resurrect this topic, because I'm wondering why Pauli hasn't yet jumped into this thread and told us his opinion about it!?

I was on holiday away from the Internet for a few days -- out bush, very peaceful, quiet and relaxing.

The reason I didn't comment when I got back was simply that Marcus, Walter and I discussed this to death way back and the current setup was the best we could come up with back then. I do not believe that this has changed.

Is our solution perfect? I doubt it.

Is it better than what we had before (the same as the 15c -- the final RTN resets the PC to zero)? Yes, much.


- Pauli

#30

Quote:
Is our solution perfect? I doubt it.

Unfortunately I have to agree. ;-)
Quote:
Is it better than what we had before (the same as the 15c -- the final RTN resets the PC to zero)? Yes, much.

I also agree, the current method is indeed better than always resetting the PC to 0.

But I just don't understand why this PC reset (into the called program) is necessary at all? It's not done when the XEQ is used IN a program, so why is it done when called manually?

As I said: there are (at least) 2 other ways to set the PC to any program, but the current method simply prevents you from using any user-defined function/routine during a temporary program stop/prompt, because using XEQ now throws you out of this program.

Is this really a good design?

Franz

#31

Marcus has already explained why we do what we do. Without doing this the current way, we don't get stand alone applications with hot keys. Which is worth more here? This is a trade off, you can't have both.

Like I wrote before, the current situation is not perfect but it is the best we could come up with after considering everything we could. We're already doing something different to/better than existing HP calculators.

Consider this a quirk of the device rather than a bug. I apologise in advance if you don't consider this acceptable.


- Pauli

#32

Quote:
Without doing this the current way, we don't get stand alone applications with hot keys.

Well, that's not true at all!

I've never said that such a manual XEQ should NEVER reset the PC or clear the return stack - it should only avoid this if it is executed while a program is pending (i.e. waiting for an input after a STOP or PROMPT). And I'm quite sure that you can find out whether this is the case or not (probably from the PC or return stack).

For all other uses of XEQ (or [h]CAT or [h]GTO) it's of course the right thing to reset the PC into the global subroutine to allow using those loccal labels.
Quote:
Consider this a quirk of the device rather than a bug. I apologise in advance if you don't consider this acceptable.

No need to apologise - I'll give up now because I don't want to annoy you any further.

I got it now: you just don't want to consider (and think about) any other solutions if you think you've already found the best one, even if someone provides cases where this solution is not really a good choice (and even if someone makes alternative suggestions).

Anyway, thanks for your answer,

Franz

#33

Franz, many of your suggestions made it into the design, most notably END. So don't give up early but allow for an open discussion.

The question left is: When shall XEQ from the keyboard be treated the same as within a program and when shall it be treated as a 'start over' operation with the effect it has now: clearing the present return stack and/or repositioning the PC. I have an idea which might help: I don't think it is easy and safe to make assumptions about the present state of a program from the PC or return stack alone, but it might be possible to either check for local registers/flags or one of the available system flags X, Y, Z, T, L, I, J or K. If set, a manual XEQ behaves likea programmed one. A program waiting for input can then signal this unmistakenly and the user has the option to clean up with a manual RTN or by clearing a flag.

#34

Quote:
So don't give up early but allow for an open discussion.

I won't call it 'early' after more than 5 unsuccessful posts about this topic. ;-)

Your idea about local regs or flags would require that you would need to know already while writing the program whether you'll need to use any global subroutines or not when you run this program - not really comfortable IMO.

I would rather say there should be 3 states of the calculator: manual mode, running program and waiting for input.

IIRC you're using 'toplevel' (or was it 'running'?) to distinguish between the first 2 states (running or not), so we would just need any marker for this 3rd state ('pending' or waiting for input).

Are you using a bit or a byte for this 'toplevel'?

If it's a bit then we would need another bit ('pending' or 'waiting') for a STOP or PROMPT state, but if 'toplevel' is a byte then a 3rd value would of course be easier.

This 'waiting' state should be set whenever a STOP or PROMPT is executed in a program (maybe there's even any free announciator in the display for it?), and it should be reset when the program continues (with R/S).

That would be my idea for implementing this feature, but I still think there should be a better (and easier) method for it - I can't believe that there's no way for the calculator to know whether it has just excuted a STOP/PROMPT in a running program or if it's really at the toplevel (but of course only YOU know such details of your WP34s program).

Edit: Wait, I just had another idea:

Isn't one difference between running a program or not the return stack? If a program is running then the return stack shouldn't be empty, because when the program ends (with RTN or END) the PC is set back to the program's label LBL. And this must also be true for a STOP or PROMPT, i.e. if the return stack is not empty, then there's a program running or waiting for an input.

And that's exactly what a manual XEQ could check:

return stack empty ==> 'start over' the called program

return stack not empty ==> call the routine but don't clear the return stack (i.e. stay in the current program)

Franz

Edited: 10 Apr 2012, 12:00 p.m.

#35

The biggest problem I see here is there is no visual indication that the return stack is empty or not. Thus, a pair of devices that appear to be in exactly the same state will behave differently based on this invisible extra information. I believe this fails the "lets limit user surprises" test.


Quote:
Are you using a bit or a byte for this 'toplevel'?

We don't store even a single bit to indicate the top of the return stack. We know where that is and act accordingly based on the value in the stack pointer.


Quote:
This 'waiting' state should be set whenever a STOP or PROMPT is executed in a program (maybe there's even any free announciator in the display for it?), and it should be reset when the program continues (with R/S).

What happens if the executed subroutine itself executes STOP or PROMPT? Seems like one bit of state isn't sufficient. One per subroutine level is more realistic. We might be able to squeeze this into the return addresses but I'm not positive.

What commands would clear this setting? I don't believe that just R/S should -- keyboard RTN? Clear program? LOAD? The user will want to execute several subroutines after a STOP, so things like RTN and END can't naïvely clear it.

How to I escape this nest of recursive fun if I want to give up running the current program or switch to a separate application? e.g. I want to go use the TVM code during a program run and then continue the program execution....how?

How do we make it obvious to the user that XEQ will finish in an application versus returning back to where they are?


Once these questions are properly addressed, we can begin considering how to implement this suggestion. Until they are consider, there is no point looking hard at the implementation details. In other words, we need to transform your idea into a proper proposal.


An extra complication would be that many commands are user programs now and you'll have to be able to execute them without impacting this setting. I don't think this will be a major issue to support, but it will need consideration as well.


- Pauli

#36

To make it easy forget about my first ideas using a new 'state' for this - just look at the end of my posting after "Edit:".

It's that simple: whenever the return stack is NOT empty, there's either a program running or the program has stopped waiting for an input. And in exactly this situation a manual XEQ should execute the called routine and then return to the point where it has been executes - that means: it MUST NOT clear the return stack!

Of course it would be a good idea to let the user know that he's not at the toplevel, so why not use any display indicator for this?

In principle the user is responsible for which routines he is calling after a STOP/PROMPT, and even he's nesting such XEQ calls, it's his problem - I don't think the WP34s (or you) should forbid the user such behaviour.

And about 'starting over' again: well, EVERYTHING that already now initiates such a 'start over' (i.e. clear the return stack) should do it with ONE EXEPTION: a manual XEQ should NOT do it!

That means for example a manual RTN, a manual GTO, selecting a routine in the [h]CATalog and pressing ENTER (which is the same as a GTO) etc. etc. ...

You see: you won't have to change ANYthing except this 'clear return stack' behaviour of a manual XEQ!

(and maybe add a display indicator for 'being within a program' as I mentioned above).

Franz



Possibly Related Threads…
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 3,124 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 1,760 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 2,452 12-04-2013, 11:14 AM
Last Post: Barry Mead
  WP 34S/43 ?'s Richard Berler 3 1,997 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 2,089 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 2,584 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 2,837 11-08-2013, 01:28 PM
Last Post: Nick_S
  m.dy in display of WP-34S Harold A Climer 3 1,899 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin
  WP 34s : An old problem coming back Miguel Toro 2 1,693 11-05-2013, 03:00 AM
Last Post: Marcus von Cube, Germany
  [WP 34s] Pressure Conversion Factors Timothy Roche 8 3,081 11-04-2013, 07:17 PM
Last Post: Dave Shaffer (Arizona)

Forum Jump: