WP 34S: GTO.. behaviour

[RMollov]

I often want to able to use the top row keys (A-D) with their default function while there is a program in RAM using labels A-D. I expected that GTO.. will leave any programs (as in HP-41) and make those keys "free". This works only if switching to program mode and move the program counter to step 000 and until R/S is hit. I know there is no permanent ".END." in WP34S but having something with similar effect would be nice. Am I missing something?

Cheers,

[walter b]

(08-12-2014 07:06 AM)RMollov Wrote:  I often want to able to use the top row keys (A-D) with their default function while there is a program in RAM using labels A-D. I expected that GTO.. will leave any programs (as in HP-41) and make those keys "free".

Following the manual the shortcuts work unless the hotkey labels are used for something else. See e.g. p. 184 of 370 about y^x:

Quote:[C] may be used as long as label C is not defined.

Nothing else is advertized. So I understand your expectation, but alas ...

d:-I

P.S.: Since the cens... emmh ... moderator is blocking my posts right now (14.8.14), just a little information on this way:
I've updated the manual with respect to the matter you addressed since we decided to leave the features of GTO. as they are. Thus the release note for the next print batch reads so far now:

Quote:Refined explanation of addressing special registers. Corrected the descriptions of BEG, RTN, RTN+1, and a wrong display of a floating point number. Added XEQ., a remark to ⎙DLAY, and one case to the Troubleshooting Guide. Refined page formatting. Made the hotkey descriptions equal and unambiguous. Refined the beginning of Section 3.

d:-)

[Paul Dale]

I don't think you are missing anything. GTO . . puts you at step 0 of the current program. Labels for A - D are still active.

The four functions on A - D are available elsewhere on the keyboard, so you aren't losing any functionality.


- Pauli

[Didier Lachieze]

(08-12-2014 07:42 AM)Paul Dale Wrote:  GTO . . puts you at step 0 of the current program.

Well, at least in the latest revision V3.3 rev 3678, GTO . . puts the program counter on the last END of the last program in the RAM (which is different from what's documented in the manual).

So if you have a first program using labels A, B, C or D and another one not using any of the A,B,C,D labels (for example: LBL "END" END) as the last one, then with GTO . . you will go at the END of the program "END" and the default functions of the keys A, B, C and D will be active:

Code:

LBL "XYZ"
LBL A
...
LBL B
...
END
LBL "END"
END                   <= GTO . . will go there

This works also without the LBL "END", with just two consecutive END at the end of the RAM.

[Paul Dale]

(08-12-2014 09:06 AM)Didier Lachieze Wrote:  Well, at least in the latest revision V3.3 rev 3678, GTO . . puts the program counter on the last END of the last program in the RAM.

Oops, me misremembering again


- Pauli

[Didier Lachieze]

(08-12-2014 09:24 AM)Paul Dale Wrote:  

(08-12-2014 09:06 AM)Didier Lachieze Wrote:  Well, at least in the latest revision V3.3 rev 3678, GTO . . puts the program counter on the last END of the last program in the RAM.

Oops, me misremembering again


- Pauli

Anyway, if GTO . . was working as documented in the manual* ("Positions the program pointer to step 000, i.e. top of RAM.") it would be similar to switching to program mode and moving the program counter to step 000 with GTO .000 and it would automatically activate the default functions of the keys A, B, C and D without requiring an additional END at the end of the RAM.

*Note: I have only the old pdf version of the manual on hand right now, I don't know if the new 3.3 paper manual has been updated regarding GTO . .

[RMollov]

(08-12-2014 09:06 AM)Didier Lachieze Wrote:  This works also without the LBL "END", with just two consecutive END at the end of the RAM.

Thanks Didier, this looks like a workaround. Will use it.
BTW GTO.000 when not in PRGM mode doesn't seem to have the same effect as if it were.

Cheers,

[Didier Lachieze]

(08-12-2014 09:34 AM)Didier Lachieze Wrote:  *Note: I have only the old pdf version of the manual on hand right now, I don't know if the new 3.3 paper manual has been updated regarding GTO . .

I've checked with my v3.3 manual and found no real change , just some wording difference with "top of RAM" being replaced by "BEGinning of program memory" to emphasize the fact that after a GTO . . the BEG indicator should be ON to indicate that the program counter is at step 000.

So, there are some discrepancies between the 3.3 manual and the 3.3 software:

1. GTO . . doesn't put the program pointer to step 000 as documented, but at the last END of the last program in the RAM
2. out of PRGM mode, GTO .000 doesn't put the program counter at step 000, outside of any program (as it does in PRGM mode) but at step 001 inside the first program
3. the BEG indicator is ON when the program counter is at step 000 as documented in the manual, but also at step 001

For the first item I've found some references in message #5 of this thread and in message #12 of this other thread. Initially GTO . . was designed to behave differently in PRGM mode (go to last END) and out of PRGM mode (go to step 000).
And btw I've learned a new trick not documented in the manual as far as I can see: no need to press h before GTO . as XEQ . will do the same.

The second and third items look to be some minor bugs for me as I can't see why the software would not follow the manual on these points.

[RMollov]

(08-12-2014 11:45 PM)Didier Lachieze Wrote:  And btw I've learned a new trick not documented in the manual as far as I can see: no need to press h before GTO . as XEQ . will do the same.

Thanks again Didier, great find! Now I've got exactly what I wanted for the price of one extra END at the end of program memory and XEQ .. do the job perfectly!

Cheers,

[Marcus von Cube]

(08-12-2014 11:45 PM)Didier Lachieze Wrote:  The second and third items look to be some minor bugs for me as I can't see why the software would not follow the manual on these points.

It's more of the kind "the manual does not follow the software". The GTO. behavior hasn't changed since I have programmed it.

GTO. and XEQ. are equivalent because it's unambiguous, h-shift is optional.

In program mode, GTO.. is intended to enter a new program at the end of program memory. The program counter is positioned at the last END. Positioning to the END is necessary because a new step will be entered after the displayed step. The END still belongs to the last program and thus its labels are still active.

The behavior of GTO.. out of program mode is the same. If you want to go to the beginning of the first program you can enter RTN from the keyboard.

Edit: The BEG annunciator is lit when the program counter is either at step 000 or at step 001. Step 000 doesn't actually exist, it's just a dummy to enable entering something at step 001 in program mode. From the point of view of running a program both are equivalent.

[RMollov]

(08-13-2014 05:07 PM)Marcus von Cube Wrote:  GTO. and XEQ. are equivalent because it's unambiguous, h-shift is optional.

In program mode, GTO.. is intended to enter a new program at the end of program memory. The program counter is positioned at the last END. Positioning to the END is necessary because a new step will be entered after the displayed step. The END still belongs to the last program and thus its labels are still active.

The behavior of GTO.. out of program mode is the same. If you want to go to the beginning of the first program you can enter RTN from the keyboard.

Edit: The BEG annunciator is lit when the program counter is either at step 000 or at step 001. Step 000 doesn't actually exist, it's just a dummy to enable entering something at step 001 in program mode. From the point of view of running a program both are equivalent.

Well, wouldn't be better if we had a permanent .END. at the end of the program memory and GTO .. positioned the program counter on it so no program in RAM is active anymore and BEG annunciator turns on? Thus we'd know that soft keys aren't active and default functionality is in force just by looking at the display?
Just thinking.

Regards,

[walter b]

FYI, I posted an update here in the meantime.

d:-)

[Didier Lachieze]

(08-12-2014 07:31 AM)walter b Wrote:  I've updated the manual with respect to the matter you addressed since we decided to leave the features of GTO. as they are. Thus the release note for the next print batch reads so far now:

Quote:Refined explanation of addressing special registers. Corrected the descriptions of BEG, RTN, RTN+1, and a wrong display of a floating point number. Added XEQ., a remark to ⎙DLAY, and one case to the Troubleshooting Guide. Refined page formatting. Made the hotkey descriptions equal and unambiguous. Refined the beginning of Section 3.

What about GTO.000 going to step 000 if executed in program mode with default functions active for keys A, B, C & D and going to step 001 in run mode with XEQ A, B, C or D active on the keys A, B, C or D if local labels A, B, C or D are defined in the first program in RAM ?

[walter b]

(08-15-2014 06:50 PM)Didier Lachieze Wrote:  What about GTO.000 going to step 000 if executed in program mode with default functions active for keys A, B, C & D and going to step 001 in run mode with XEQ A, B, C or D active on the keys A, B, C or D if local labels A, B, C or D are defined in the first program in RAM ?

I'm sorry that sentence is too complicated for my little brain. Please rephrase.

d:-?

[Didier Lachieze]

(08-16-2014 07:49 AM)walter b Wrote:  

(08-15-2014 06:50 PM)Didier Lachieze Wrote:  What about GTO.000 going to step 000 if executed in program mode with default functions active for keys A, B, C & D and going to step 001 in run mode with XEQ A, B, C or D active on the keys A, B, C or D if local labels A, B, C or D are defined in the first program in RAM ?

I'm sorry that sentence is too complicated for my little brain. Please rephrase.

d:-?

Ok. Let see if I can do that without adding confusion ... ;-)

The point is that GTO.000 doesn't do the same thing if it is executed in program mode or in run mode:

1. in program mode, GTO.000 goes to step 000 as expected (the manual says that GTO.n goes to step n). With the program counter set at step 000 we are outside of any program and the keys A, B, C & D have their default function active.
2. in run mode, GTO.000 goes to step 001 (not step 000). As the program counter is set at the first step of the first program in RAM, any local label A, B, C or D in this program will activate the related XEQ A, B, C or D replacing the default function for the A, B, C or D keys.
   

[walter b]

Merci bien, Didier!

Additional observation: In programming mode GTO.000 goes to step 000,

• then pressing [P/R] [P/R] moves the program pointer to step 001;
• pressing [EXIT] [P/R] instead leaves the program pointer at step 000.
  

Strange.

d:-/

[Paul Dale]

(08-16-2014 08:43 AM)Didier Lachieze Wrote:  Ok. Let see if I can do that without adding confusion ... ;-)

The difference in behaviour for the hot keys depends on being in program mode or not, not on the step number you are at. In program mode, A - D always provide their default function. In run mode, they do if the corresponding label isn't defined. From keys.c:

Code:

static int check_f_key(int n, const int dflt) {
    const int code = 100 + n;
    unsigned int pc = state_pc();

    if (State2.runmode) {
        if (isXROM(pc))
            pc = 1;
        if (find_label_from(pc, code, FIND_OP_ENDS))
            return RARG(RARG_XEQ, code);
    }
    return dflt;
}

The important bit is about being in run mode as opposed to program mode.


As for step 000 vs step 001 -- go to step 000 in program mode, switch to run mode and back. You're at step 001. Step 000 is a program mode only fake step to allow you to input something before step 001.

In xeq.c:

Code:

void update_program_bounds(const int force) {
    unsigned int pc = state_pc();
    if (pc == 0 && State2.runmode)
        State.pc = pc = 1;
...

So if we're in run mode, the program counter can never be zero.


- Pauli

[walter b]

(08-16-2014 09:08 AM)Paul Dale Wrote:  So if we're in run mode, the program counter can never be zero.

Hmmh, please see my observation above. Seems the program counter doesn't know that ...

d:-?

[RMollov]

(08-16-2014 08:43 AM)Didier Lachieze Wrote:  The point is that GTO.000 doesn't do the same thing if it is executed in program mode or in run mode:

1. in program mode, GTO.000 goes to step 000 as expected (the manual says that GTO.n goes to step n). With the program counter set at step 000 we are outside of any program and the keys A, B, C & D have their default function active.
2. in run mode, GTO.000 goes to step 001 (not step 000). As the program counter is set at the first step of the first program in RAM, any local label A, B, C or D in this program will activate the related XEQ A, B, C or D replacing the default function for the A, B, C or D keys.
   

I guess the above would fix the written manual problem.

But there is a room for improvement in my view.
What is currently the use of the "BEG" indicator? I see it as none.
What if GTO .. GTO .000 and their XEQ equivalents did set the program counter to the 000 step and "BEG" indicator lit? That in a way would visualize the status of "user" mode in other HP calcs. It's not only a matter of A-D keys but all the others through XEQ numeric_label convention as we all know. For example I have 2 labels for my most used program and the second one is 41

Regards,

[Didier Lachieze]

(08-16-2014 09:08 AM)Paul Dale Wrote:  So if we're in run mode, the program counter can never be zero.

Well, it seems it depends how you get out of program mode.
If you do the following:

Code:

h P/R
GTO.000
LBL A
RTN
GTO.000

You are now at step 000 in program mode.
Press [EXIT], you are back to run mode and the key A has its default function active, not XEQ A.
Press [h] [P/R] to go in program mode: you're still at step 000.
Press twice [h] [P/R], you are again in program mode but now at step 001.

EDIT: This was already mentioned by Walter above ...