HP15C LE Pause Operation not as expected

[Russell Dobson]

Hi,
I just got my new 15C LE yesterday, its my 9th HP so I am farily familiar with programming these calcs. When using a very simple loop programme the PSE instruction only allows you to see the x register result on the first iteration, then you just see a blank screen until you stop execution with R/S
Eg:

LBL 1
1
STO+1
RCL1
PSE
GTO 1

It seems like the PSE instruction on each subsequent iteration is in sync with a blank display because after several seconds if I stop execution, the x register might be say 10 or so.
All similar previous calcs 29C, 11C, 41C, 32S2 etc all pause and display the x register for about 1 second. (which is what the manual says for the 15C LE as well)
Any explanations would help.
Thanks

PS: without the PSE those iterations are nice and fast ~485 loops/sec!

[Katie Wasserman]

This is very old news. See the list of known bugs here.

There's been no word as to if/when HP will fix any of these bugs, but their silence on the issue is not encouraging.

[Howard Owen]

What if the recent price rise is making the way clear for a new HP-15C? That is, a "non-LE" version, with a MSRP similar to the old 15CLE price? Perhaps the bugs would be fixed in a new model. We might even hope that new bugs wouldn't have been introduced.

The obvious success of the 15CLE makes this more plausible in my mind. That would leave the LE, bugs and all, as a mildy popular collectors item with a truly limited supply. HP would then sell a workaday 15C priced more reasonably.

Quote:

---

You may say that I'm a dreamer

But I'm not the only one.

John Lennon

---

[Kees Bouw]

What puzzles me is why this was not noticed by anyone at HP, prior to releasing the product. I mean, it is a pretty obvious problem. It is not like you have to do anything unlikely or complicated. Just use a PSE in any program and bingo, it does not work. It makes one wonder if this product was ever tested at all.

[Russell Dobson]

Thanks Katie and Kees, I am new to the HP forums and didn't try a search first. I think these calcs have only just arrived here is Australia.
Amazing that some of these weren't picked up, the pse function was the first thing I tried!

[Thomas Chrapkiewicz]

This bug does not exist in the preproduction 15c+ machine (the prototypes from the HHC2010).
(Has this been reported here?)
...and of course this bug does not exist on the original 15c.

Has anyone compared the advantages/disadvantages of the 15c+ code with the 15CLE code?

Perhaps it would be worth transplanting the 15c+ code to a 15CLE machine.(?)

TomC

[Sylvain Louboutin]

Now, may be am I imagining things, I'll have to double check when I go home, but I am pretty sure that the PSE bug can also be observed on the emulator (the one on the CD that comes with the 15C LE); dunno if this makes a difference but I am running it using CrossOver (a commercial version of Wine) on Mac OS X.

[Michael de Estrada]

It doesn't matter. The PC emulator works exactly the same way as the hardware. I ran the program on page 114 of the manual on emulator on my PC running Windows 7, and the calculator initially pauses for 1 second, displaying 9.000000000, and then goes blank for the remainder of the program, until displaying 0. when it terminates. So, it's a coding problem, not a processor speed or operating system problem.

Edited: 31 Jan 2012, 10:10 p.m.

[Mike Morrow]

I'm sure they must have fixed it on the new $180 models. :-)

[Michael de Estrada]

LOL

[Kees Bouw]

Quote:

---

I'm sure they must have fixed it on the new $180 models. :-)

---

Yeah... maybe if we all donate another $ 80 to HP, they will fix ours as well!

[Jeff O.]

Quote:

---

This bug does not exist in the preproduction 15c+ machine (the prototypes from the HHC2010). (Has this been reported here?)

---

Yes, see this post for example.

Quote:

---

Has anyone compared the advantages/disadvantages of the 15c+ code with the 15CLE code?

Perhaps it would be worth transplanting the 15c+ code to a 15CLE machine.(?)

---

The firmware that came on the 15C+ units presented to HHC 2010 attendees is dated 2009-08-03. While it may not exhibit the so-called PSE bug, there are issues with it, as follows:

At the conference, we were told (if I recall correctly) that integration was “slow” with 15C+. The sample program that was presented with the 15C+ included an integration. The documentation that I have from the meeting states that the program ran on the original 15C in 123 seconds and on the 15C+ in 7.5 seconds. I went ahead and entered the program onto machines running both the 2009-08-03 firmware and the 2011-04-15 firmware of the current production units. On the machine running the 2009-08-03 firmware, it indeed ran in 7 to 8 seconds. With the 2011-04-15 firmware, it ran in about 1.4 seconds, so I can confirm that integration was indeed slow with the 2009-08-03 firmware.

Also found at the conference was a bug in the display of program line numbers. For example, enter 62 steps in program memory, then go to step "000" and back-step. The program counter will show "05o", "05-", then "05r" before showing the correct "059" step number. If you enter 63 steps and back-step, it will start at "057", then "056", etc., all the way down to "000". Continuing to back-step shows step “999”, “998” “997”, “996”, “995” and “994” before cycling back to “057”.

Like the 2011-04-15 firmware of the production units, the 2009-08-03 firmware does not like combinations and permutations in programs. Enter the following program from the 15c LE bug reports article:

LBL A

STO 0

LBL 9

8

ENTER

3

Cy,x

DSE 0

GTO 9

RTN

Now enter a small number, 1, 2, 3, etc. and run the program. It will come back quickly with the expected answer of 56. Now enter a larger number, like 56, and run the program. The display will briefly show “running” once, then go blank. Despite the blank display, the program continues to run, executes the loops, and then stops. Now alter the program like this:

LBL A

STO 0

LBL 9

8

ENTER

3

Cy,x

DSE 0

PSE

GTO 9

RTN

Note that I put the PSE in the wrong place if I want to see each iteration then stop. Enter a small number like 5 and run the program. It dutifully stops at each pause and displays 56. Then the display goes blank, but the program is still running. Wait a while and press a key to stop it, then recall register 0. It will have a large negative number in it, indicating that the calculator continued to run after counting down to zero. This is proper execution of the program as entered, except there was no “running” display to tell you that the calculator was still running to indicate that you made an error in the program. If you replace the Cy,x with Py,x, you get the same behavior. If replaced by another function, say y^x, it works fine. So using Cy,x or Py,x in a program blanks the display while the program is running. If you somehow got into an endless loop, you might think the calculator was off while it continued to run with a blank display.

Another anomaly is if you set flag 9, either manually or in a program. With proper operation, the display starts flashing when you set flag 9, and stops if you clear it with g-CF-9, or press the back-arrow key. This is what happens with the 2011-04-15 firmware. With the 2009-08-03 firmware, setting flag 9 causes the display to go blank. If you press a key, there is a momentary display, then it goes blank again. It appears that keystrokes and functions work normally, the display just blanks out after each key-press. Normal display is returned by pressing the back-arrow key, or g-CF-9, i.e. the standard way to clear flag 9.

The above behavior also occurs for overflow conditions which would normally cause a flashing display.

Finally, the 2009-08-03 firmware also exhibits items 3, 4, 5, 6 and 10 from the 15c LE Bug Report Article.

Based on the above, I do not consider the 2009-08-03 firmware to necessarily be a good alternative to the 2011-04-15 firmware.

Edited: 3 Feb 2012, 1:23 p.m. after one or more responses were posted

[uhmgawa]

Quote:

---

Also found at the conference was a bug in the display of program line numbers. For example, enter 62 steps in program memory, then go to step "000" and back-step. The program counter will show "05o", "05-", then "05r" before showing the correct "059" step number. If you enter 63 steps and back-step, it will start at "057", then "056", etc., all the way down to "000". Continuing to back-step shows step “999”, “998” “997”, “996”, “995” and “994” before cycling back to “057”.

---

That's quite bizarre and I'd wager a sympton of an instruction
emulation bug. Otherwise such behavior is outside the scope
of functional impact by the emulator to firmware execution.

Quote:

---

The display will briefly show “running” once, then go blank. Despite the blank display, the program continues to run..

---

This and similar quirks including those surrounding display
flash are likely related. Voyager firmware emits an excess of
writes to the display registers which if strictly emulated
can consume substantial cpu time to no benefit. I encountered
this rendering to a graphic display which is expected. It
isn't immediately obvious to me the sam7 lcd controller presents
such overhead however it does appear to require updates to synchronize with its blink timebase. So that may be the root of
the problem depending how the emulator was designed to interact
with it. It appears all of the above could be addressed by
allowing firmware display updates to hit the controller
asynchronously. But admittedly speculation on my part as I
haven't had to interact with the sam7 segment controller thus far.

[Marcus von Cube, Germany]

The LCD controller memory in the SAM7 can be updated without caring about the display refresh. But if you want to have it blink you need to wait for at least to update cycles (you can have an interrupt generated on each refresh) before you program the controller to blink. It will then autonomously alternate between the previous and the current images. This requires some software infrastructure but isn't overly complicated.