WP34S: "Domain error" when running a program

[Cristian Arezzini]

I just entered a short program on my 34s, freshly updated. The program ends with a RTN and then an END.
After entering it, I went to the CAT, saw it there, and pressed XEQ to run it, and I got a "Domain error". I cleared the error, went to CAT again, pressed XEQ again and now it worked.

Now comes the weirder part. Executing it again, it returned the result "plus one". I tried single-stepping it, and in the single-stepping it got stuck in a loop: where it encountered the RTN, it skipped one step back, thus executing the previous command (which happened to be a INC X); after the INC it executed the RTN again, and so on, always adding 1 to the displayed number.

I have no idea why the single-stepping looped while normal execution only "skipped back" once, but I think neither is the intended behaviour... The manual says that RTN, if in a program and not a subroutine, should stop execution and set the pointer to 000.

The same happened in the emulator.

In case it matters, here's what is in the memory:

001   LBL'D'

002   DATE

003   YEAR

004   # 1

005   # 1

006   ->DATE

007   DATE

008   (Delta)DAYS

009   INC X

010   RTN

011   END

Cristian

Edited: 30 Jan 2012, 11:59 a.m.

[Marcus von Cube, Germany]

I think I can explain the SST issue: A top level RTN sets the PC back to where it was when the program was started. In the case of SST this is the step before the RTN. I agree that this is a little strange and worth reconsideration.

I can't reproduce the strange CAT behaviour. What is your version? I'm running 3.0/2347.

BTW, END serves as a RTN. So RTN is not needed in your case.

[Cristian Arezzini]

The version I'm using is 2347. It's reproducible here, I'm writing down a list of operations to do to show the problem. I'll report it here when I have it.

Cristian

[Walter B]

Can't reproduce the strange CAT behaviour either. Emulator V3.0/2348.

And I count the SST looping being a bug.

Edited: 30 Jan 2012, 1:48 p.m.

[Marcus von Cube, Germany]

Quote:

---

And I count the SST looping being a bug.

---

I concur. I've uploaded a new build.

[Cristian Arezzini]

I updated the emulator, and the loop bug is gone, but the "domain error" and hang-up are still there, as described in my post below...

I also have a .dat file from before the crash... with that dat file, you just go to program mode, move to step 008, exit program mode, and run the program, and here comes the crash. Do you want it to test it?

Cristian

Edited: 30 Jan 2012, 3:16 p.m.

[Marcus von Cube, Germany]

I was able to reproduce a loop in the error handler. Pauli has recently converted more stuff to XROM which made the error apparent. The "Domain Error" is thrown inside the [delta]DAYS routine by some bogus input.

I have not tested the weird CAT behaviour. There is most probably still something wrong.

[Cristian Arezzini]

I have problems here. I'm able to consistently get weird results (sometimes the program gives the correct result but also displays the day's name; sometimes I get totally wrong results like 735628; and so on) but I have problems in finding the exact order of commands to induce them. But it seems (though I can't believe it) that unexpected results are triggered when exiting the program edit mode at different locations. If when I exit program mode I was at location 000 I get different results than if I was at 001 or, say 008...
I have to experiment some more. I'll report back.

[Cristian Arezzini]

OK, the exact errors aren't exactly reproducible, but a weird behaviour is. Here are the exact steps I take (it seems that every individual keystroke counts...)

0) Hard reset, using the cable's "reset" button

1) Contrast- three times, to make display more readable

2) DATE (to verify reset) - it shows 1.012007

3) Back arrow twice to clear display

4) P/R (to enter program mode), it enters at step 000

5) Enter above program, without inserting the ending END because it's already there

6) Right after entering RTN, press P/R (to exit program mode)

7) CAT (it shows Lbl'D' RAM)

8) XEQ (it shows Monday 2007)

At this last step, sometimes it shows "Monday 2007", sometimes just 2007, sometimes "Monday 0", sometimes just 2, sometimes "Monday 732679" and so on... and doing CAT and XEQ again and again always gives different results (though sometimes you get the same result 3 or 4 times in a row). I have reflashed the calc, just in case, but it still does the same thing.

On the emulator instead, these following steps:

1) Total reset by removing wp34s.dat

2) DATE (shows today's date, taken from system clock)

3) P/R to enter program mode

4) Enter program as above, without ending END

5) Right after entering RTN, press P/R to exit program mode

6) CAT

7) XEQ (it seems to work right, even after several tries)

8) P/R

9) move to step 000

10) P/R

11) CAT

12) XEQ (it displays the correct result but also the weekday)

13) P/R

14) move to step 008

15) P/R

16) CAT

17) XEQ (it says Domain Error)

The emulator seems more consistent in that the results are always the same. I was wondering if maybe I had faulty hardware but the emulator does similar (though not identical) things...
After the Domain error, sometimes the emulator is left in a locked state. After forcing a quit, and reopening the emulator, it shows garbage on the screen. I have a .dat file from this state if needed...

Cristian

Edited: 30 Jan 2012, 2:35 p.m.

[Marcus von Cube, Germany]

I think I can explain why a message is shown: The date functions set an internal message to be shown on the next display event. This only occurs when the program has come to an end. I think it's better not to set the message when a program is running.

Can you try the latest build please? (It still sets the message.)

[Paul Dale]

Quote:

---

I think I can explain why a message is shown: The date functions set an internal message to be shown on the next display event. This only occurs when the program has come to an end. I think it's better not to set the message when a program is running.

---

The day of week command probably should set the message either way. I agree the rest can not. Or we should be clearing the message a bit more often than we do perhaps.

- Pauli

[Marcus von Cube, Germany]

I've made it dependent on the Running flag.

[Walter B]

On the emulator, I consistently get 30 if calling the program via CAT XEQ - and Monday 30 if calling it via XEQ'D' without using CAT.

[Cristian Arezzini]

Quote:

---

On the emulator, I consistently get 30 if calling the program via CAT XEQ - and Monday 30 if calling it via XEQ'D' without using CAT.

---

Walter, the emulator is more consistent, did you try on the real hardware? Also, did you try on the emulator to enter program mode, go to step 008, exit program mode without changing anything, then run the program wia the CAT? Doesn't it give you the Domain error if you do that?

Cristian

[Paul Dale]

I'm getting no stack change from the console build executing this via CAT when I start with the PC at step 008.

I suspect we might be executing stuff after we return or at least not quite executing properly from the CAT display.

- Pauli

Edited: 30 Jan 2012, 5:08 p.m.

[Paul Dale]

Quote:

---

A top level RTN sets the PC back to where it was when the program was started. In the case of SST this is the step before the RTN. I agree that this is a little strange and worth reconsideration.

---

I'm still in favor of resetting the PC to the start of the current program instead of leaving it where it was. I've been caught out by this behaviour more than a few times -- it is both unnatural and annoying.

- Pauli

[Marcus von Cube, Germany]

There was a bug which led to the repositioning of the PC to the INC X statement. There is a problem with resetting the PC to the begin of the current program when we hit a top level RTN: Technically, executing a command that is implemented as XROM is just an ordinary XEQ to a routine which ends in a RTN statement. This would affect the user's PC which is undesirable.

[Paul Dale]

if (top level and not xrom)

    pc = 0;

???

Okay not 0 but the start of the current program :-)

- Pauli

[Marcus von Cube, Germany]

All issues should be fixed by now. I've implemented something similar to what Pauli has suggested.

[Cristian Arezzini]

After preliminary testing, both on emulator and real calc, everything seems to be ok. Thank you! :)

Cristian