HP 15C-LE Pause (PSE) Command Bug



#69

I tried out the PSE command on the 15C-LE to see if there were timing problems with it. I found a surprising and unhappy result.

The following simple loop counts down from 10 to 1, pausing to display before each decrement. That's what happens in the original 15C, but not the 15C-LE.

001 LBL E

002 1

003 0

004 STO 0

005 LBL 9

006 RCL 0

007 PSE

008 DSE 0

009 GTO 9

010 RTN

On the 15C-LE, the program pauses for the first time and displays 10.0000. For the remainder of the program, the display blanks completely, the program pauses each time the PSE is executed (determined by long program run time), but nothing is shown in the display until execution terminates.

This is a firmware bug that could be very inconvenient. Essentially the PSE command is non-functional on the 15C-LE.

Edited with some additional observations below.

I added a 1000-iteration sub-loop to see what the display looks like when a great number of other steps are taking place between PSE commands:

001 LBL E

002 1

003 0

004 STO 0

005 LBL 9

006 RCL 0

007 PSE

008 1

009 0

010 0

011 0

012 STO 8

013 LBL 8

014 DSE 8

015 GTO 8

016 DSE 0

017 GTO 9

018 RTN

In FIX 4 display, after starting the program with f E, I see 10.0000 paused in display, then a couple of seconds of blinking "running" displays, then simply a "runn" in mid-LCD that blinks every few seconds, presumably when the next PSE command is encountered, until program terminates and normal display appears.

In FIX 9 display, the same occurs, except that "runn00000" instead of "runn" appears in the display until the program terminates and normal display appears.


Edited: 10 Sept 2011, 7:24 p.m. after one or more responses were posted


#70

I guess you found bug ONE!!! Kinda reminds me of the "bug one" on the HP-41C (of course it was of a different nature).

A pause command that does not work right is very irritating!

Let's hope that HP can provide us with an updated firmware at HHC2011.

Namir

Edited: 10 Sept 2011, 12:54 p.m.


#71

Bug 2.

Bug 1 was the self-tests that don't work, and that also corrupt program memory.


#72

Isn't that more an un-wrong-documented feature rather than a bug?

Quibbling ...


#73

I think the old self test issue fully qualifies as a bug because:

1. It is a feature that is described in the manual that does not work.

2. If the "ON plus *" or the "ON plus +" tests are attempted by an unwary user following the manual instructions, program memory will likely be corrupted (something the self tests should never do).

If the issue is addressed only by a change to manual appendix F, and firmware remains unaltered, program corruption can take place through indavertent initiation of the old self tests.

Since firmware changes are required to correct this, it more than qualifies as a bug and not a documentation issue.

#74

Does no one test before releasing? I hope HP provide a new firmware...


#75

Quote:
Does no one test before releasing?

You've got to be kidding. I assure you that there was lots of testing on this machine. Just because something got missed doesn't mean that testing was not done. In addition, just because one hasn't been found yet does not guarantee that any HP calculator model is completely bug free.

Jake


#76

Quote:

I assure you that there was lots of testing on this machine.


Did none of the 2010 conference recipients of the HP 15C LE ever try a program with PSE in it? Or does PSE work in some cases and just doesn't in this one?

I'm seriously thinking about canceling my order of two units. Or is it likely that a fixed firmware will be released and also be flashable with the HP 30b cable (that I already have!)?


#77

Quote:
Did none of the 2010 conference recipients of the HP 15C LE ever try a program with PSE in it? Or does PSE work in some cases and just doesn't in this one?

The PAUSE worked fine in my Towers of Hanoi program on my HHC2010 15C+, so I had no cause to report a bug.

#78

I agree. Even old firmware technology is complex and nothing is ever perfect (except the Apollo Lunar Modules!). I'm happy with my two 15C-LE units...though this PSE problem does need correction.

I think it's worth repeating that the 15C-LE is only about one-quarter the cost of the original in terms of real dollars. I believe it offers a very good value.

#79

Well, I also find it odd that this hasn't been tested. If anything can fail in an emulation that seems to work otherwise, it is likely based on timing. Guess that's what Mike was looking for when testing PSE.

@Alexander, I'm sure there will be an update. I wouldn't cancel my order now. Even if this bug remains, I bet the 15C LE can be sold on TAS anytime for more than the 100 Euros we'll likely have to pay for it.

#80

You're right. I really spoke too harshly and it was offensive to the testers and developers. I've ordered three units and had unrealistic expectations.

#81

what happens if you insert more than one pse at each pause? Will this slow it down enough to work?

What happens if you insert R/S instead of pse? Does it work correctly?


#82

Adding a second PSE only increases the execution time in which a blank display appears. The program above takes 11 second to end with one PSE, and 22 seconds with two PSE. The PSE is in fact pausing execution. But the LCD is completely blanked...there isn't even a "running" display after the first PSE.

Of course, R/S will stop everything.

#83

Quote:
On the 15C-LE, the program pauses for the first time and displays 10.0000. For the remainder of the program, the display blanks completely, the program pauses each time the PSE is executed (determined by long program run time), but nothing is shown in the display until execution terminates.

This is a firmware bug that could be very inconvenient. Essentially the PSE command is non-functional on the 15C-LE.


Sounds like there may be a problem with the logic used to
simulate the display blink mode (which in NUT voyagers is a
hardware function) along with normal rendering to the sam7l
display.

I'm unsure what approach would cause that to occur unless the
emulator is attempting to factor out the spurious/partial
display updates
emitted by the voyager firmware. KEMU rendering to a graphic
display when running on the AVR needed to factor out
these updates which although themselves are generally
imperceptible to the user, also occur when a user is
entering key strokes and
cause an objectionable lag in interactivity.

The display rendering correctly at the termination of the
program would seem to support this theory as when coalescing
display updates a push out of pending data needs to happen
when the firmware pauses with a POWOFF instruction.


#84

It should be fixable. I imagine 15C LEs are reflashable, because as Tim Wessman has repeatedly told us, they're the same hardware as the 12C+. HP may have to do something like have people send their calculators back to be reflashed (for dealing with folks who don't have access to reprogramming cables), but I can't imagine they would leave this unfixed, especially since it sounds like the 12C/15C code was developed in-house unlike the 35S.


#85

I don't understand why this has any bugs at all, there's no reason for them. The 2009-11-19 version of the emulator in the 12C+ has PSE working fine as well as the self tests. I helped debug this with Cyrille, publicly on this forum after it's release. Didn't HP learn from developing that how to get these things right?

-Katie


#86

Quote:
I don't understand why this has any bugs at all, there's no reason for them. The 2009-11-19 version of the emulator in the 12C+ has PSE working fine as well as the self tests. I helped debug this with Cyrille, publicly on this forum after it's release. Didn't HP learn from developing that how to get these things right?

Again the 15c firmware has additional emulation requirements
to successfully pass the native firmware self test. And in
general HP is either patching the firmware, or adapting
emulator behavior on a firmware specific basis. So none of
this seems surprising except for the fact it hadn't been
caught in alpha/beta testing.


#87

I understand that the specific patches to the firmware might be different for the 12c and the 15c while the emulator changes should be pretty similar if not identical. I was more questioning not learning from past mistakes of having the same self test issues on the 12C+.

#88

Simple solution, don't use it. :-)

Thomas


#89

Hmmh, PSE isn't something so arcane you won't need it. So IMHO this must be fixed.

#90

I found something different. I pulled out the 15C+ we got last year at HHC and out of curosity, I typed in Mike's program and it counts and displays the countdown 10 to 0 just fine. It appears that this bug could be the result of firmware changes made after last October. I don't have my 15c LEs yet so please confirm this result.

Thanks,
Gerry


#91

...And the good news is that HP can release a new firmware version and these units can be reflashed. Hopefully, it will be considered important enough to fix and there will be a new file to download in a reasonable amount of time.

Jake


#92

Now we really need reliable and easy to use software and USB cables to update the firmware easily in Windows 7.

#93

This should be fine for those of use who read this forum and have cables (or can get them from Gene) and SAMBA. But what about the non-HP calculator fanatic who just wants to buy a calculator that works correctly and won't corrupt memory when running the self tests documented in the manual?


#94

Quote:
This should be fine for those of use who read this forum and have cables (or can get them from Gene) and SAMBA. But what about the non-HP calculator fanatic who just wants to buy a calculator that works correctly and won't corrupt memory when running the self tests documented in the manual?

Exactly. What about those who read this forum but do not have cables or SAMBA (whatever that is) because we don't do 34s.
#95

Excellent point. Still whoever bought the LE would be HP calc fanatic and they would know.

That explains the "LE" in a way, after they are sold, a fixed non-LE edition will be emitted.

#96

Just curious, does this bug also occur in the windows emulator that comes with the 15C LE?

#97

Compared with Casio's FX-502P, FX-602P and FX-603P, the classic HP-15C's implementation of the pause command is quite limited. The pause command of Casio's calculators can display something and accept keyboard input temporarily. Some games were developed using this feature. However, HP-15C only allows values to be displayed.

Edited: 11 Sept 2011, 12:21 a.m.


#98

Agreed. Being able to input values during a pause is great for games.


- Pauli


#99

Yes, that's where the 41's workaround using flag 22 and flag 23 was mainly used - does the 15C have something similar perhaps?


Quote:
Yes, that's where the 41's workaround using flag 22 and flag 23 was mainly used - does the 15C have something similar perhaps?

Unfortunately, there's no such workaround for HP-15C! :(

Just to add that "input during PAUSE" started with the 67/97 and certainly was most useful on the 41. Note that the 42S PAUSE works differently, IIRC.

No, it hasn't, just as it predecessor, the 34C. The 15C cannot be compared to top-of-the-line devices like the 67/97, let alone the 41. These not only allowed keyboard data entry during the PSE instruction, even magnetic cards could be read. In either case the calculator could check whether data had been entered or not.

The 34C, as well as its successor 15C, and even the current 35s cannot do that. Like some other things that are/were possible on the higher-end models. I think it's fine that way.

Dieter

Mike:

In your first program, could you replace 10 with 10.00001 and run it again?

I would like to see whether the PSE command works after specifying explicitly the yy value to 01.

To be honest, it surprises me that such obvious bug hasn't been noticed during beta testing because PSE isn't some obscure used-once-in-a-year feature. Something like LBL 01 1 + PSE GTO 01 is the first thing I was checking while developing all my emulators ...


Pfffffffffff.

I ordered an HP15C-LE, because I want a new and working RPN calculator. My HP-35s is unusable because of too many bugs. So HP it seems that you have spoiled it again.

How does that firmware update work? Do you have to take the calculator apart? Will HP provide free cables?

I have noticed that many people must have known about this new calculator for more than a year. Wouldn't it have been wiser to imply more people from the community for serious debugging? That keep it top secret stuff is pure nonsense. What's the use op HHC when the final product is C*R*A*P?

No longer want that calculator.

Edited: 11 Sept 2011, 4:59 a.m.


Connector is accessible from within the battery compartement, if I identified it correctly in Katies pictures. Gene Wright offers appropriate cables for shipping costs only. You'll need a serial port and some patience for the new firmware to be written ;-).


Can I make the reprogramming cable easily? In Japan, Nihon-Hewlett-Packard decided to stop selling their calculators and outsource their customer service to Sykes Co, Ltd(China) several years ago. I don't think they provide firmware flashing service. So I may have to fix the problem myself.


Sorry, I don't know the internals of this cable. Thus far, people got them for free, some just paying shipping costs (it isn't much, even for oversea shipment). Wait some time for HP to present a solution, a new firmware won't be out tomorrow anyway ;-).


Thank you for giving me a information. Okay, I've wait more than 5 years and I'll wait for a while. :)

As was pointed out, this bug is not present in the firmware on machines given out at last year's HHC conference.


Quote:
As was pointed out, this bug is not present in the firmware on machines given out at last year's HHC conference.

Might it be possible to extract said firmware from these machines, make it available for download and flash it to the ones that are now sold?


What if it was replaced for a reason? It might contain different bugs :-(. The calculator folks should sort it out and offer one _working_ firmware when it's ready and tested.

@Gene,
BTW., do the stock of cables last for a few thousand customers? I imagine also it is asked a little too much to have them send out by just one person.

Edited: 11 Sept 2011, 8:21 a.m.


Quote:
What if it was replaced for a reason? It might contain different bugs


Oh my...I hadn't thought of that... :-(

But, considering the fact that no bugs in this earlier firmware have been reported by HHC testers, my question remains: would that be doable?


Edited: 11 Sept 2011, 9:33 a.m.

I would like to get a cable from Gene, hoping I will be able to flash my 15CLE when I get it (should be sent next Tuesday).

But, IMHO, HP has to manage that bug, and maybe some others that will appear, crossing my fingers the number is limited.

First, as said, Gene has probably not enough cables for thousands of people, and sending them would be a huge job.

Second, HP has to fix that and it is pretty easy to work with resellers who have lists of buyers and the organisation for managing large shippings of cable + CD with software and image. This is also probably cheaper for HP rather than to have users sending their calcs somewhere, flashing them and returning them to their owners, especially in case of bugs appearing later...

Jeff


Are the reprogramming cables manufactured in China, or are they homemade by Gene and / or a group of volunteers?

If they are made in China, why not let ER sell them on his site? If they are free to those who ask (by HP?), I will gladly pay USPS cost to have one.

If they are homemade can we get a diagram or schematic so we can make our own??

If they are homemade and the cable diagram is already on the internet, could someone provide a link. I will go searching in the meantime..

Thanks!


Edited: 11 Sept 2011, 9:56 a.m.


Here are the details needed to make your own cable. I'm pretty sure that these cables are made in China but are not available for purchase, only free from Gene.

I think that the main problem is making them more available is that they are really quite difficult to use. I've reprogrammed of all the ARM-based machines many times and still have a hard time using them. The cables themselves are not at fault, the SAMBA software and the ARM chip are -- they're very temperamental.

-Katie

Edited: 11 Sept 2011, 11:36 a.m.


Quote:
Here are the details needed to make your own cable.

I sketched a configuration for a
flat profile connector
before Tim was kind enough to send a full cable my way.

I've built a
similar configuration (left hand board)
to reflash a KINOMI module although the
pitch here was 0.8mm rather than the sam7l's 2.0mm grid.
So the task is relaxed considerably.

But unless you are doing quite a bit of reflashing such a jig is
likely overkill. A more simple approach would be to scrounge
phosphor bronze music wire (0.4~0.5mm should be fine) which
has both suitable spring temper and is solderable.

I've even used paper clips, hot glue and popsicle sticks
in a pinch as the steel has enough temper to maintain sufficient tension and can be soldered directly with a little ambition.
In any case be sure to grind/sand/wire_brush the tips of the
probes to a smooth convex surface so they don't excessively
scuff up the gold plating on the sam7l PCB.

Well, I don't have thousands of cables now, but I'm sure HP will be taking a look at this and talking about it this next week. Remember, this wasn't found until after close of business on Friday. :-)

The firmware from HHC contained a few bugs related to timing of the display flashing (errors, etc) and these were fixed in an update. I don't believe the PSE error was present then, but another update was done that appears to have re-introduced them.

Patience, please. I'm not happy that the 15c LE has these minor issues, and it shouldn't have had any. However, I'm confident a fix will be forthcoming and something will be done to fix it.

Remember, HP did not have to redo this machine *at all*. It was done as a bow to those who really wanted this machine brought back. It won't budge HP's bottom line at all. It is and was a labor of love of many people. Those same people are *also* not happy with these two issues either, I'm sure.

Just my thoughts. Patience. :-)


Quote:
Patience, please. I'm not happy that the 15c LE has these minor issues, and it shouldn't have had any. However, I'm confident a fix will be forthcoming and something will be done to fix it.

Like how the 35s was fixed? I would like to have such confidence...

The 15c LE can be flashed through a firmware update.

The 35s cannot.

Several orders of a magnitude difference between correcting one and not the other. One requires creating firmware and distributing it over the internet with no change to production lines, manufacturing processes, inventory, blah blah blah. The other requires a great deal more.

Your statement also shows a lack of awareness of firmware updates already created for the 49g, 49g+, 50g, 12c+, etc.

So, please give us all a break. No one will force you to buy a 15c LE...until they are all sold and you can buy one off ebay at > original cost. :-)


Not to mention the numbers. Despite the real and perceived flaws celebrated here, the 35s has stayed in HP's catalog for years. I'd guess there are high six figures in circulation, at least.

You guys are a tough audience. :)

Quote:
Your statement also shows a lack of awareness of firmware updates already created for the 49g, 49g+, 50g, 12c+, etc.

I have read some references to firmware updates on this forum. I should point out that the four you listed above are regular production calculators, not "Limited Edition" offerings.
Quote:
So, please give us all a break.

Who are you including in "all"?
Quote:
No one will force you to buy a 15c LE...

What does that have to do with this discussion?

Yes, they were regular production calculators that could take a firmware update.

You seem to have missed that point for the second time now.

Say this out loud...

The HP 35s is not firmware upgradable, but every calculator HP has made that CAN be firmware upgradable has had a bug fix.

Sigh.

And, now to your questions:

2) All includes me, myself and I. Three.

3) If you feel that HP will never fix anything ala your view of the HP 35s, then don't ever buy a 15c LE and you won't have to worry about it. Just a suggestion.


Quote:
Yes, they were regular production calculators that could take a firmware update.

You seem to have missed that point for the second time now.


Rather, I made that point (that the others were regular production, and the 15cLE presumably isn't).
Quote:
The HP 35s is not firmware upgradable, but every calculator HP has made that CAN be firmware upgradable has had a bug fix.

I never said anything contrary to that. You're missing my point, which was, that HP has not shown much interest in fixing one-off models with problems.
Quote:
3) If you feel that HP will never fix anything ala your view of the HP 35s, then don't ever buy a 15c LE and you won't have to worry about it. Just a suggestion.

I never made that statement, you have assumed that. See above.

Quote:
Like how the 35s was fixed? I would like to have such confidence...

This isn't intended as any sort of excuse, but the 35S cannot be re-flashed, and thus had a ROM revision been made available, you'd have to obtain a new unit one way or another. I can only imagine the cost to the company if they offered a no-cost swap of an old one for a new one....that would have to be at least an order of magnitude more than simply putting a firmware revision on their web site for downloading. But I agree that there should have appeared a ROM revision in the sales pipeline at some point in the past four years.

Jake

Man with free horse: "Gee, that left molar looks suspicious!"

Patrick,

Apparently the prototypes that got handed out at HHC last year didn't contain this bug. I'm not sure if any members of the community got to test the firmware version that shipped on the production 15C LEs. I do think that HP will fix this though, for the simple reason that this firmware was in-house as opposed to the 35S that was developed entirely by a 3rd party.

As a programmer I have, on a few occasions, created unforeseen new bugs by doing last minute tweaks to my code. And yes it was embarrassing if the code went to someone else. My guess is that this is what happened with the HP-15C LE. From what I read the beta version given at HHC2010 had the PSE command working properly. So, drawing from my own experience, a last minute tweak of the 15C LE code is the culprit.

Namir


It was probably the fix that was put in to speed up integration. The HHC version from last year had serious speed issues during integration due to the display updating so frequently. It was around 15x the speed of the original instead of the current speed.

Cyrille fixed this in the last version that was given to beta testers in April. Nobody reported any issues with it so. . . :-(

TW

Edited: 11 Sept 2011, 2:20 p.m.

Oh dear!

I fear what other more obscure but more harmful bugs may have escaped detection given that PSE is itself such a common programming instruction for debugging programs.

Reports like this make me mistrust the accuracy and reliability of the LE, and I hate that feeling.


All the algorithms are exactly the same as in the original 15C. What you see here (the PSE bug) is in the emulation layer that mimics the original hardware. It's just a display glitch and does not affect the accuracy of the results in any way.

Nonetheless, the bug needs to be fixed. I assume Cyrille and Tim had some bad nights recently.


More like past few months of nights. . .

TW

Quote:
In FIX 4 display, after starting the program with f E, I see 10.0000 paused in display, then a couple of seconds of blinking "running" displays, then simply a "runn" in mid-LCD that blinks every few seconds, presumably when the next PSE command is encountered, until program terminates and normal display appears.

In FIX 9 display, the same occurs, except that "runn00000" instead of "runn" appears in the display until the program terminates and normal display appears.


That sounds quite familiar.
Communication with the LCD controller residing in the r2d2 is via
two 56-bit registers located in the address map. The voyager
firmware can only modify these registers serially but in the case
of an r2d2 sniffing the ISA bus, modifications are realized immediately which masks the gratuitous updates made by
the firmware. Under emulation it is possible (and potentially
necessary) to factor out these excessive updates. But in doing
so you'd need to synchronize the display register state to the
display device after the firmware has set fully coherent
display data in the corresponding registers.

From the above description it is possible the emulator isn't
getting this quite right as it appears to be rendering at a
transition point before the firmware has coherently modified both
display registers. At least that is one explanation for the
half-updated half-stale LCD display cited above and admittedly
a scenario I needed to address in KEMU when driving a display
other than the ISA r2d2.


I use the same cable and Samba for the 34S as I do for the 15C.

My pause display was tested with the latest firmware but not in an interative loop. Only for pause between two separate answers.

As far as firmware updates go, I have flashed through 3 of them so far with Samba and the cable with no problems at all.

I ordered one 15C+ from SC and have one 15C+ Beta unit. Nice thing is the Beta has a different bezel and harser colours diffentiating it from the 15C+ sales unit. Thus it will always be a stand alone 'collectable' unit.

I currently have 10 programs loaded for aviation and have not found any bugs on the latest version of software. The calc is unbelievably fast, compared especially to the 15C of course, but favourably to the 42S and 41CL for the same routine using similar code.

Fits in the pocket and is used as backup to the 41CL which I carry with me to work.

I think you will all enjoy it, and with cable, Samba and updates hopefully available, it will make a great package.

Cheers, Geoff


Quote:
I use the same cable and Samba for the 34S as I do for the 15C.

As far as firmware updates go, I have flashed through 3 of them so far with Samba and the cable with no problems at all.


Thanks for stating this with such clarity! This might have been obvious for you beta testers, but I needed this assurance to calmly go to sleep tonight and happily await the delivery, hopefully in a week or two!

Quote:
That sounds quite familiar...

From the above description it is possible the emulator isn't
getting this quite right as it appears to be rendering at a
transition point before the firmware has coherently modified both
display registers.


Not to beat this to death, but here's another short program for the 15C-LE that demonstrates display oddities following PSE:

001 LBL E

002 5

003 0

004 0

005 0

006 STO 0

007 PSE

008 R/S

009 PSE

010 LBL 9

011 DSE 0

012 GTO 9

013 RTN

With a FIX 9 display, when this is executed (f E), the 15C-LE can be seen pausing (step 7) with 5000.000000 in display, then halting (step 8) with 5000.000000 in display. So far, so good.

When R/S then is pushed to restart execution at step 9, within a fraction of a second the display shows alternating 5000.000000 followed by runn00000 images (with less than 1 second period), until execution ends about ten seconds later and the display returns to normal.

If the R/S (step 8) and second PSE (step 9) are deleted, then all appears normal...5000.000000 is shown in display by the PSE (step 7), followed by blinking "running" in display until execution ends.

It appears that two or more PSE commands must be executed during a program's runtime for problems to be observed afterwards. The PSE commands do not have to be consecutive.

Edited: 11 Sept 2011, 3:21 p.m.


Possibly Related Threads...
Thread Author Replies Views Last Post
  [HP-Prime CAS] "Warning, ^ (Command) Is ambiguous on non square matrices"?? CompSystems 1 716 12-07-2013, 07:15 PM
Last Post: CompSystems
  HP Prime graphing bug BruceH 1 513 11-19-2013, 08:14 AM
Last Post: Joe Horn
  HP Prime - another cosmetic bug BruceH 3 640 11-12-2013, 02:18 PM
Last Post: Ken Shaw
  HP Prime - most favorite command bluesun08 2 596 11-12-2013, 11:29 AM
Last Post: bluesun08
  hp prime - command syntax bluesun08 6 910 11-10-2013, 11:57 AM
Last Post: bluesun08
  HP PRIME: command to read the SERIAL ? Joseph Ec 9 2,001 11-01-2013, 12:43 AM
Last Post: Joe Horn
  Connectivty Kit for HP Prime needs an "Import Program" Command Eddie W. Shore 3 683 10-23-2013, 03:37 PM
Last Post: Eddie W. Shore
  HP Prime MOUSE command SanS 3 585 10-15-2013, 12:15 PM
Last Post: Han
  HP Prime Bug bluesun08 19 1,840 10-14-2013, 10:48 PM
Last Post: Han
  HP Prime bug in EDITMAT Han 7 992 09-27-2013, 10:15 AM
Last Post: Han

Forum Jump: