Threaded Mode | Linear Mode

JurgenRo · (This post was last modified: 03-19-2023 06:48 PM by JurgenRo.)

Hello everyone!
I have an HP-41C which shows a weird behaviour when it comes to programming with LBLs and GTOs. Running a program (by XEQ, R/S or SST) with a mumeric Label, LBL01 say, GTO01 will send the program pointer "anywhere" but not to the LBL01. Moreover, "anywhere" seems not to be a location in normal program memory but shows characters that indicates the program pointer to be into firmware area or something (reminds me to what I'm seeing when doing SP). Any thoughts?

Edit: typo

Thanks a lot
Juergen

**rprosperi** · (This post was last modified: 03-19-2023 08:25 PM by rprosperi.)

(03-19-2023 06:46 PM)JurgenRo Wrote: Hello everyone!
I have an HP-41C which shows a weird behaviour when it comes to programming with LBLs and GTOs. Running a program (by XEQ, R/S or SST) with a mumeric Label, LBL01 say, GTO01 will send the program pointer "anywhere" but not to the LBL01. Moreover, "anywhere" seems not to be a location in normal program memory but shows characters that indicates the program pointer to be into firmware area or something (reminds me to what I'm seeing when doing SP). Any thoughts?

Edit: typo

Thanks a lot
Juergen

There's not enough information here to give you useful suggestions; please list the program.

Are you using any synthetic instructions?

Are you using any exotic modules (e.g. CCD, ZENROM, HEPAX)?

Another easy thing to try is to replace the current LBL 01 instruction (delete it, then retype the same instruction) followed by a PACK and try again.

JurgenRo · 03-21-2023, 08:10 PM

(03-19-2023 08:24 PM)rprosperi Wrote:
(03-19-2023 06:46 PM)JurgenRo Wrote: Hello everyone!
I have an HP-41C which shows a weird behaviour when it comes to programming with LBLs and GTOs. Running a program (by XEQ, R/S or SST) with a mumeric Label, LBL01 say, GTO01 will send the program pointer "anywhere" but not to the LBL01. Moreover, "anywhere" seems not to be a location in normal program memory but shows characters that indicates the program pointer to be into firmware area or something (reminds me to what I'm seeing when doing SP). Any thoughts?

Edit: typo

Thanks a lot
Juergen

There's not enough information here to give you useful suggestions; please list the program.

Are you using any synthetic instructions?

Are you using any exotic modules (e.g. CCD, ZENROM, HEPAX)?

Another easy thing to try is to replace the current LBL 01 instruction (delete it, then retype the same instruction) followed by a PACK and try again.

Hi Bob,

no SP, no module.

LBL TST
LBL 01
1
+
GTO 01
RTN

JurgenRo · 03-21-2023, 08:27 PM

(03-19-2023 08:24 PM)rprosperi Wrote:
(03-19-2023 06:46 PM)JurgenRo Wrote: Hello everyone!
I have an HP-41C which shows a weird behaviour when it comes to programming with LBLs and GTOs. Running a program (by XEQ, R/S or SST) with a mumeric Label, LBL01 say, GTO01 will send the program pointer "anywhere" but not to the LBL01. Moreover, "anywhere" seems not to be a location in normal program memory but shows characters that indicates the program pointer to be into firmware area or something (reminds me to what I'm seeing when doing SP). Any thoughts?

Edit: typo

Thanks a lot
Juergen

There's not enough information here to give you useful suggestions; please list the program.

Are you using any synthetic instructions?

Are you using any exotic modules (e.g. CCD, ZENROM, HEPAX)?

Another easy thing to try is to replace the current LBL 01 instruction (delete it, then retype the same instruction) followed by a PACK and try again.

Hi Bob,

no SP, no module.

LBL TST
LBL 01
1
+
GTO 01
RTN

And, yes, I know it should run “forever“ but it quits with Data Error and PP in “nowhere land“. Tried re-type after memory lost several times w/o success.

**rprosperi** · 03-22-2023, 01:27 AM

If that program will not run, entered after a reset, then there is definitely some kind of hardware issue with the machine.

Remove the batteries
Short the outermost 2 battery contacts
Press [ON] and toggle a few times
Let it sit with no power for 24 hours

Then put batteries back in, do a RESET ([<-]+[ON]), enter only that program, [GTO] [ . ] [ . ] to pack and then run it. If the problem remains, you need some h/w repairs, and I'm afraid I am not the right guy to tell you what part(s) may be the cause.

Good luck and please report results.

JurgenRo · 03-22-2023, 08:23 PM

(03-22-2023 01:27 AM)rprosperi Wrote: If that program will not run, entered after a reset, then there is definitely some kind of hardware issue with the machine.

Remove the batteries
Short the outermost 2 battery contacts
Press [ON] and toggle a few times
Let it sit with no power for 24 hours

Then put batteries back in, do a RESET ([<-]+[ON]), enter only that program, [GTO] [ . ] [ . ] to pack and then run it. If the problem remains, you need some h/w repairs, and I'm afraid I am not the right guy to tell you what part(s) may be the cause.

Good luck and please report results.

Thanks again, Bob. Already tried everything except of "Let it sit with no power for 24 hours".

May I asked another question? I have another 41c that runs faultlessly. But after a couple of hours (> 12 or so) of inactivity it won't turn on again. Removing and re-installing batteries it would work sound again. After a couple of hours (> 12 or so) of inactivity it won't turn on again ... you guess how the story progresses ;-) Any ideas on this strange behaviour?

David Hayden · 04-04-2023, 09:15 PM

(03-21-2023 08:27 PM)JurgenRo Wrote: LBL TST
LBL 01
1
+
GTO 01
RTN

Try replacing RTN with END.

JurgenRo · 04-09-2023, 09:22 PM

(04-04-2023 09:15 PM)David Hayden Wrote:
(03-21-2023 08:27 PM)JurgenRo Wrote: LBL TST
LBL 01
1
+
GTO 01
RTN
Try replacing RTN with END.

Will do, thanks for your input! Although, I don't think that it makes a difference because the program pointer should never see neither the RTN nor the End, shouldn't it?

Vintage63 · 04-13-2023, 03:00 PM

I inputed exactly your code, while waiting for my MacBook to upgrade, and haven't even closed the program, i.e. no RTN nor END. It runs indefinitely.

**rprosperi** · 04-13-2023, 08:36 PM

(04-13-2023 03:00 PM)Vintage63 Wrote: I inputed exactly your code, while waiting for my MacBook to upgrade, and haven't even closed the program, i.e. no RTN nor END. It runs indefinitely.

This program (posted by JurgenRo) does not ever end, if the machine is running properly. It is intended to be used to run forever, adding 1 in each loop, so that when you run it for a specified amount of time and press [R/S] the display shows you how many loops were completed within that time-span. There actually is no RTN or END needed, since it will never get there, as the GTO 01 is not conditional, it always loops. JurgenRo was using this to help his testing of his 41, to give it a task to run for an extended period to see if the 41 would continue running or not.

Vintage63 · 04-13-2023, 09:35 PM

I ran it a couple of times and once the sum of the loops generated was in X another time was in Y. I thought 'this is strange' as I was expecting the sum to be in X

**rprosperi** · 04-13-2023, 10:27 PM

(04-13-2023 09:35 PM)Vintage63 Wrote: I ran it a couple of times and once the sum of the loops generated was in X another time was in Y. I thought 'this is strange' as I was expecting the sum to be in X

Before you run the program, fill the stack with the number 1:
[1] Enter Enter Enter, then [R/S]

AndiGer · 04-14-2023, 04:32 AM

… and leave out the 3rd program step ‚1’ between LBL01 and +

As it is if you find the loop count in Y you have 1 in X (prepared to be added)

ThomasF · (This post was last modified: 04-14-2023 06:40 AM by ThomasF.)

(04-09-2023 09:22 PM)JurgenRo Wrote:
(04-04-2023 09:15 PM)David Hayden Wrote: Try replacing RTN with END.

Will do, thanks for your input! Although, I don't think that it makes a difference because the program pointer should never see neither the RTN nor the End, shouldn't it?

It might.
What I think David tries to indicate is that if your program ends with END, we know that we see the whole complete program (assuming that LBL TST is at line 01), meaning that there could be no instructions after the GTO 01.

I don't think this is the case here, but you could have several programs after each other (i.e. as part of larger collection of smaller routines), separated by RTN but just listed the first part:

Code:

LBL TST

LBL 01

1

+

GTO 01

RTN

LBL TST2

LBL 01

2

+

GTO 01

RTN

END

And this would mess up things, as the first GTO 01 would jump to the LBL 01 after the LBL TST2, since GTO will search downwards looking for the first LBL 01 it can find before looping back to the start of the program.
But, if you end your program with END instead, you are guaranteed that the LBL 01 is unique and local (as there can't be any instructions following the END instruction):

Code:

01 LBL TST

02 LBL 01

03 1

04 +

05 GTO 01

06 END

Cheers,
Thomas

Didier Lachieze · 04-14-2023, 06:53 AM

(03-19-2023 06:46 PM)JurgenRo Wrote: Hello everyone!
I have an HP-41C which shows a weird behaviour when it comes to programming with LBLs and GTOs. Running a program (by XEQ, R/S or SST) with a mumeric Label, LBL01 say, GTO01 will send the program pointer "anywhere" but not to the LBL01. Moreover, "anywhere" seems not to be a location in normal program memory but shows characters that indicates the program pointer to be into firmware area or something (reminds me to what I'm seeing when doing SP). Any thoughts?

Does this also happen if you replace the numeric label (LBL 01) by a global alpha label such as LBL "01"?

Vintage63 · 04-19-2023, 09:01 PM

@AndiGer, thank you you are correct. Filling the stack with 1 and removing the 1 before the '+' symbol leaves the total in X.
Before it was in Y
Thank you so much :-)

JurgenRo · 04-20-2023, 08:07 PM

(04-14-2023 06:39 AM)ThomasF Wrote:
(04-09-2023 09:22 PM)JurgenRo Wrote: Will do, thanks for your input! Although, I don't think that it makes a difference because the program pointer should never see neither the RTN nor the End, shouldn't it?

It might.
What I think David tries to indicate is that if your program ends with END, we know that we see the whole complete program (assuming that LBL TST is at line 01), meaning that there could be no instructions after the GTO 01.

I don't think this is the case here, but you could have several programs after each other (i.e. as part of larger collection of smaller routines), separated by RTN but just listed the first part:

Code:

LBL TST LBL 01 1 + GTO 01 RTN LBL TST2 LBL 01 2 + GTO 01 RTN END

And this would mess up things, as the first GTO 01 would jump to the LBL 01 after the LBL TST2, since GTO will search downwards looking for the first LBL 01 it can find before looping back to the start of the program.
But, if you end your program with END instead, you are guaranteed that the LBL 01 is unique and local (as there can't be any instructions following the END instruction):

Code:

01 LBL TST 02 LBL 01 03 1 04 + 05 GTO 01 06 END

Cheers,
Thomas

I see what you mean, good approach. But the initial situation of the calc was MEMORY LOST. So, definitely no other code present in RAM.

JurgenRo · 04-20-2023, 08:10 PM

(04-14-2023 06:53 AM)Didier Lachieze Wrote:
(03-19-2023 06:46 PM)JurgenRo Wrote: Hello everyone!
I have an HP-41C which shows a weird behaviour when it comes to programming with LBLs and GTOs. Running a program (by XEQ, R/S or SST) with a mumeric Label, LBL01 say, GTO01 will send the program pointer "anywhere" but not to the LBL01. Moreover, "anywhere" seems not to be a location in normal program memory but shows characters that indicates the program pointer to be into firmware area or something (reminds me to what I'm seeing when doing SP). Any thoughts?

Does this also happen if you replace the numeric label (LBL 01) by a global alpha label such as LBL "01"?

No, I have not yet, good idea! I will try and report the result!

JurgenRo · 04-21-2023, 06:37 PM

(04-20-2023 08:10 PM)JurgenRo Wrote:
(04-14-2023 06:53 AM)Didier Lachieze Wrote: Does this also happen if you replace the numeric label (LBL 01) by a global alpha label such as LBL "01"?

No, I have not yet, good idea! I will try and report the result!

Does not work either, same behaviour as with numeric labels. Tanks for your input anyway!