After using the 34s (emulator) for a while, I would like to suggest some possible improvements of the 34s user interface. Most of this is not exactly new, but that does not make it less useful. ;-)

1. The menus keep the position of the last command used. The position within one single menu, that is. Switch to another and the last position of the previous menu is lost. Is there really no way to store the last positions of all menus?

2. Single-stepping through a program for debugging can be quite cumbersome if you come across a XEQ and you have to step through every single step of that subroutine. That's why many debuggers for VB, Pascal, C and the like offer a "step over" or "procedure step" function that allows to execute subroutines in one single step. AFAIK the 19C/29C could do something similar. I think that's an extremely useful feature. Do you think there is a chance it can be done on the 34s ?-)

3. There currently is no easy way to delete parts of a user program. The 41-series has a DEL command that deletes a certain number of lines. An even better solution would be a similar command that accepts a label, so that all lines between the current position and that label will be deleted. I assume this is not trivial, so I will not expect anything like this. But it's something I already missed 30 years ago on the '41.

4. I am not sure if this only affects the emulator or also the "real thing": There may be a problem with the way the program pointer is handled.
   
   Here are some examples:
   
   • Assume the 34s has a short program starting with LBL A. Press [RTN], switch to program mode and enter a few lines at the very beginning: LBL 99 RTN. Back in run mode, press the A-key to run the original program. This will work as expected. Now delete the two lines you just inserted. In run mode. pressing [A] now will execute Sigma+. Even an explicit XEQ A will throw an error: "No such LAbEL". Press [RTN] and the 34s will recognize there is actually is a label A and it will behave correctly again.
     
   • Set the program pointer to a line somewhere within a program, e.g. GTO . 020. Now execute that program from its beginning by pressing [A]...[D] or [XEQ](name). If the program has a RTN as its final instruction it should should end with the program pointer at the very top of program memory, so the BEG announciator should appear. But it doesn't. Now press [P/R] and see that the current position still is step 020, i.e. the line you manually set before. Obviously the program pointer is not updated when a program finishes.
     

Dieter

Hi Dieter, a short remark about your point 2)

Exactly the same request I've already posted quite some time ago, but then I removed my post again because I found that this is already possible with a little trick:

If you single-step through a program and come to a 'XEQ lbl' so that this XEQ is the last command executed with the DownArrow key, the program counter is set to the called label. If you want to execute this subroutine at once (without single-stepping through it), then just use the R/S key, which does exactly what you want: it runs the subroutine until the RTN or END, and the PC is back again, i.e. after this you can just continue to single-step through your main program again by the usual DnArrow.

(BTW, this R/S not only works immediately after the XEQ, you can also do it after the subroutine LBL or after any following command in the subroutine).

But I haven't yet tried if/how this works for nested XEQs, i.e. if the subroutine calls another one - but I guess such a R/S will always execute a _complete_ subroutine (incl. nested ones).

Franz

Edited: 19 Aug 2012, 11:32 a.m.

Dieter,

Thanks for sharing your thoughts. I refer to your suggestion numbers:

1. Yes. As usual, memory is the reason :-( AFAIK there is one free bit (!) left.
   
2. Good idea though I don't remember having seen something alike in any vintage HP. My bad memory probably. One challenge might be finding a proper keystroke for it. We will think about it.
   
3. We had DEL once and removed it (see p. 167). You can edit your programs using all the bells and whistles of your PC - then assemble and transfer them to your WP 34S (or to the emulator, if you prefer). Please also read App. H in this matter.
   
4. That goes to Pauli and/or Marcus. I remember some lengthy discussions about that topic many weeks ago, reaching a point I gave up trying to understand.
   

Quote:

---

2. Good idea though I don't remember having seen something alike in any vintage HP. My bad memory probably. One challenge might be finding a proper keystroke for it. We will think about it.

---

See my posting above - R/S is the 'key' (in both meanings) ... ;-)

Franz

Edited: 19 Aug 2012, 11:54 a.m.

Ah, yes, indeed this seems to work. Great. :-)

On the other hand this behaviour might be related to point 4., i.e. the program pointer not being updated after a program call from the keyboard. This way it stays where it was at the last line before the subroutine was called. Which turns a bug into a feature. :-) While it remains a bug in all other cases. #-\

Anyway, thank you for this information. BTW it does not seem to work with nested subroutines. In this case [R/S] seems to run through all the follwing subroutines until the return stack is empty, i.e. the top level is reached again.

Dieter

Quote:

---

Not necessary, this feature already exists. :-)

---

BTW, as far as I remember the 19C/29C also used the [R/S] key for their "procedure step" feature. ;-) Currently I cannot check this because since last year my 29C sits inoperably in a drawer. *sniff* :-(

Dieter

Quote:

---

Yes, it seems to work - in a limited way (see my other post). But I feel this just is a side-effect of a bug - or let's say, an unexpected feature - of the current 34s implementation. I do not know if this still works once this has been changed.

---

Also what you wrote in your other answer is quite logical for me: if you do a R/S while single-stepping then this is in manual mode, and if the subroutine is calling another nested subroutine, then this is done in run-mode and so it doesn't stop of course at a RTN but just returns to the outer routine - only this top-level routine is stopped because it is called in manual mode.

I would say everything is ok as it is. But of course editing a program by deleting a few lines is no 'usual' action to use a program, so you can't expect the PC to be exactly where you would like it (and a manual RTN after such an editing action is not really much work ;-)).

Franz

Edited: 19 Aug 2012, 1:46 p.m.

Quote:

---

Well, I won't call this a bug at all - IMO this is exactly as I expect it. If you do a R/S in manual mode then the program runs until reaching a RTN/END and this resets the PC to the value he had before executing R/S.

---

Classic HPs behave in two different ways if the program stops at a RTN statement (because there is no calling subroutine). They either stop and reset the program pointer to step 000 (e.g. the 34C and 35s behave this way), or they stop at the line number following the RTN, just as if it was a STOP statement (that's what the 41-series does). But I cannot find any sense in returning to the step where the calculator was positioned before the program was run.

Dieter

Hi.

About executing a subroutine with a single key while step-by-step running a program: the HP48S introduced a very closer feature with the [SSTv] (SST and a down-arrow). The [SSTv] works the same as the [SST] if a regular built-in object is evaluated. But if it is a user-defined object, [SSTv] evaluates it as a whole and returns the result after its evaluation. [SSTv] continues evaluating the next object in the main program.

I used this feature many times, wishing to find some equivalent in any RPN-based calculator, but only the RPL series had it. It allows faster debugging of the main program when you are sure the subroutines are OK, mostly if they are shared with other programs.

Of course, there is also the issue about the difference between what is a subroutine in both RPL- and RPN-based calculators.

Cheers.

Luiz (Brazil)

Edited: 19 Aug 2012, 4:32 p.m.

The behaviour in point 4 is intentional. We had a long and winding discussion about what the RTN at the end of a program should do. There were quite a few options -- leave the PC as is, move PC to address 0 which is start of RAM, move PC to start of the library, move PC to the beginning of the program, set PC to the address the subroutine was called from. Most have advantages and disadvantages.

- Pauli

Forgetting Label A exists is intentional?

When we added the 'sticky' catalogs we just didn't have enough RAM to store the position of each catalogue. With the advent of version 3 and its advanced memory handling, we can think about the feature again. (I don't promise we actually will!)

"LBL not found" is definitely a bug while the preservation of the program counter when a subroutine is executed manually from the keyboard (hotkey or XEQ) works as designed. One (internal) reason for this behavior is that many internal commands are just subroutines in XROM: The program counter must not be affected by such a command. We generalized this behavior to any subroutine called from the keyboard. The question is: What is the 'proper' position of the program counter after a subroutine call from the keyboard? Not affecting it at all seems the least surprising way of dealing with this.

No, not this one. I'll investigate.

Quote:

---

Not affecting it at all seems the least surprising way of dealing with this.

---

That's why I was so surprised that the 34s, a machine dedicated to the HP heritage of their glorious days, works completely different in this respect. In other words this is the most surprising way. ;-)

Dieter

Although I wasn't actually involved in the big discussion leading up to the decision on what the program counter should do, it was an observation of mine (I think) that started it off. (fhub had a lot to do with it as well!) Imagine a program that has stopped and is either displaying a result or waiting for input. I wanted to be able to call a second program from the keyboard and still be able to carry on with the first program when the second program was complete. So calling the second program would be like calling a built-in function such as SIN or SQRT: it wouldn't permanently change the position of the program counter.

I found that this didn't work, because when the second program RTNed the program counter didn't go back to where it had been and so the first program couldn't continue. The behaviour was changed (after a lot of interesting discussion!) so that a program called from the keyboard can now run without permanently changing the value of the program counter.

I can see that this behaviour would seem surprising if it isn't shared by other HP calculators, but I was surprised when RTN didn't seem to be doing what I felt it should! I hope that this helps explain why things are as they are.

Nigel (UK)