▼
Posts: 758
Threads: 9
Joined: Jul 2007
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
▼
Posts: 2,247
Threads: 200
Joined: Jun 2005
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.
▼
Posts: 758
Threads: 9
Joined: Jul 2007
Bug 2.
Bug 1 was the self-tests that don't work, and that also corrupt program memory.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Isn't that more an un-wrong-documented feature rather than a bug?
Quibbling ...
▼
Posts: 758
Threads: 9
Joined: Jul 2007
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.
Posts: 22
Threads: 1
Joined: Mar 2010
Does no one test before releasing? I hope HP provide a new firmware...
▼
Posts: 349
Threads: 66
Joined: Apr 2007
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
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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!)?
▼
Posts: 325
Threads: 18
Joined: Jul 2006
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.
Posts: 758
Threads: 9
Joined: Jul 2007
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.
Posts: 1,089
Threads: 32
Joined: Dec 2005
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.
Posts: 22
Threads: 1
Joined: Mar 2010
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.
Posts: 2,448
Threads: 90
Joined: Jul 2005
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?
▼
Posts: 758
Threads: 9
Joined: Jul 2007
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.
Posts: 384
Threads: 18
Joined: Sep 2010
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.
▼
Posts: 202
Threads: 9
Joined: Jul 2009
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.
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
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
▼
Posts: 384
Threads: 18
Joined: Sep 2010
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.
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
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+.
Posts: 735
Threads: 34
Joined: May 2007
Simple solution, don't use it. :-)
Thomas
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hmmh, PSE isn't something so arcane you won't need it. So IMHO this must be fixed.
Posts: 255
Threads: 59
Joined: Jul 2007
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
▼
Posts: 349
Threads: 66
Joined: Apr 2007
...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
▼
Posts: 2,247
Threads: 200
Joined: Jun 2005
Now we really need reliable and easy to use software and USB cables to update the firmware easily in Windows 7.
Posts: 1,477
Threads: 71
Joined: Jan 2005
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?
▼
Posts: 1,248
Threads: 33
Joined: Aug 2007
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.
Posts: 556
Threads: 9
Joined: Jul 2007
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.
Posts: 203
Threads: 29
Joined: Nov 2009
Just curious, does this bug also occur in the windows emulator that comes with the 15C LE?
Posts: 125
Threads: 5
Joined: Jun 2008
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Agreed. Being able to input values during a pause is great for games.
- Pauli
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
Yes, that's where the 41's workaround using flag 22 and flag 23 was mainly used - does the 15C have something similar perhaps?
▼
Posts: 125
Threads: 5
Joined: Jun 2008
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! :(
Posts: 1,193
Threads: 43
Joined: Jul 2005
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.
Posts: 653
Threads: 26
Joined: Aug 2010
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
Posts: 125
Threads: 5
Joined: Jun 2008
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.
Posts: 381
Threads: 32
Joined: Mar 2006
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 ...
▼
Posts: 122
Threads: 9
Joined: Jul 2007
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.
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
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 ;-).
▼
Posts: 22
Threads: 1
Joined: Mar 2010
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.
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
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 ;-).
▼
Posts: 22
Threads: 1
Joined: Mar 2010
Thank you for giving me a information. Okay, I've wait more than 5 years and I'll wait for a while. :)
Posts: 1,545
Threads: 168
Joined: Jul 2005
As was pointed out, this bug is not present in the firmware on machines given out at last year's HHC conference.
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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?
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
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.
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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.
Posts: 9
Threads: 1
Joined: Nov 2010
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
▼
Posts: 260
Threads: 21
Joined: Nov 2006
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.
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
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.
▼
Posts: 384
Threads: 18
Joined: Sep 2010
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.
Posts: 1,545
Threads: 168
Joined: Jul 2005
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. :-)
▼
Posts: 1,248
Threads: 33
Joined: Aug 2007
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...
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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. :-)
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
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. :)
Posts: 1,248
Threads: 33
Joined: Aug 2007
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?
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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.
▼
Posts: 1,248
Threads: 33
Joined: Aug 2007
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.
Posts: 349
Threads: 66
Joined: Apr 2007
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
Posts: 1,830
Threads: 113
Joined: Aug 2005
Man with free horse: "Gee, that left molar looks suspicious!"
Posts: 202
Threads: 9
Joined: Jul 2009
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.
Posts: 2,247
Threads: 200
Joined: Jun 2005
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
▼
Posts: 1,278
Threads: 44
Joined: Jul 2007
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.
Posts: 11
Threads: 2
Joined: Aug 2011
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.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 1,278
Threads: 44
Joined: Jul 2007
More like past few months of nights. . .
TW
Posts: 384
Threads: 18
Joined: Sep 2010
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.
▼
Posts: 1,083
Threads: 126
Joined: Sep 2006
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
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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!
Posts: 758
Threads: 9
Joined: Jul 2007
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.
|
