Another HP-15C LE bug?



#10

While testing the HP-15 LE for speed by using the Taylor series of Arctan(1) to get an estimate of pi (pi/4= 1-1/3+1/5-1/7...), I seem to have stumbled into an unusual, unpredictable and potential annoying bug. After an ON/- reset, I entered the following:

LBL A
4 STO 0
3 STO 1
1 CHS STO 2
1 EEX 4 STO 3
LBL 0
4
RCL 1 / <= altered code (see below)
RCL 2 *
STO+ 0
2 STO+ 1
1 CHS STO* 2
DSE 3
GTO 0
RCL 0
RTN

At some point, the program stops with ERROR 0
Checking further, RCL 1 (where it says altered code above) is changed to RCL 5, and since R5 contains zero, there is a divide by zero error.

Bottom line, the program was modified during execution !!!

Additionally:
- The R3 value when this occurs is never the same.
- The problem does not seem to occur if you enter EEX 4 instead of 1 EEX 4.
- I also tried a few other values for the number of cycles and did not see this problem.

Does anyone find the same on their machine?
Any clue on the cause, and fix?
Does this happen on the original HP-15C?


#11

I just tried your program, very quickly, on my 15CLE. I didn't do an ON/- reset - I just did an f CLEAR PRGM and then entered it. The first time, I used a loop count of 1 EEX 2, just to check what was going on. Then I went in and edited the 2 to a 4, and ran the program three times, successfully. No ERROR 0, and no program corruption.

I suspect this is related to the ON/- reset.

Best,

--- Les

[http://www.lesbell.com.au]

#12

Even after an ON/- reset it works on my LE.

#13

Just a quick test here as well - it seemed to work properly for three runs on mine. Also worked after an ON/- reset.

Kind of a long shot, but do you have all the settings at default? (Display mode, trig mode, flags, register allocation, etc.?) just in case that's got something to do with it?


Bob

PS Looks like the line feeds in your code listing got eaten by the editor - I took the liberty of putting them back in and adding line numbers. (Hopefully without introducing any errors of my own!)

[1] LBL A 
[2] 4
[3] STO 0
[4] 3
[5] STO 1
[6] 1
[7] CHS
[8] STO 2
[9] 1
[10] EEX
[11] 4
[12] STO 3
[13] LBL 0
[14] 4
[15] RCL 1
[16] /
[17] RCL 2
[18] *
[19] STO+ 0
[20] 2
[21] STO+ 1
[22] 1
[23] CHS
[24] STO* 2
[25] DSE 3
[26] GTO 0
[27] RCL 0
[28] RTN


Edited: 2 Oct 2011, 10:51 a.m. after one or more responses were posted


#14

Les, Alexander, Bob,

Thank you for your feedback.

The purpose of the ON/- reset was to get the machine into a standard state before the test.

This being said, I tried this morning and could not reproduce the problem for a while. Then edited the program (changed 1 EEX 4 to 1 EEX 2), and edited back again, and the problem came back in the exact same way (RCL 1 changed to RCL 5). Fixed the RCL 1 and tried again, and it worked... odd


#15

There is a chance it's a hardware fault. You might try re-entering a second copy of your code (with different labels) without deleting the original version and see if the new copy works correctly. If it does, then do a clear program memory and re-enter the code once with the new labels. If that misbehaves I'd strongly suspect bad memory (i.e. step 15 is being stored in a flaky cell).

Cheers,
Bob


#16

Bob,

Thank you for the suggestion. I have tried as you suggested and the 2nd copy did not crash so far. I tried also a small program that cycles infinitely with RCL 1 in cell 15 - no program corruption after quite a while - so I am really at a loss at what is happening...

#17

Quote:
...Then edited the program (changed 1 EEX 4 to 1 EEX 2), and edited back again, and the problem came back in the exact same way (RCL 1 changed to RCL 5).


Hi Benoit:

Did that happen straight away? That is, right after the edit? Or after editing it and then running it?

Bob


#18

I tried to reproduce this, doing the editing and rerunning as you suggest, with no errors or program corruption. If possible I suggest that you measure the voltages on the two batteries in your calculator.

It might be that a low voltage -- which will occur when running a long program -- is corrupting memory before the brown out detection kicks in. Brown out detection shuts down the ARM chip before voltage becomes too low to sustain memory, this voltage threshold is settable in firmware and might be too low. This would be really bad news so I hope that's not the issue, but I'm going to try testing that just the same.....


#19

The machine has been turned off for ~ 30 minutes.
I took out the batteries - both measured 2.92 V on my digital voltmeter (I just measured a AAA new battery with it at 1.59~1.60V, so it probably does not give a low measurement).

What is the min voltage for an ARM processor?


#20

2.92 is actually pretty low for unloaded 2032 cells. If you can put a resistor across them and test the voltage under a simulated calculator load you'll know what the calculator is seeing. Try a 300 ohm resistor (or 330, that's easier to find) across just one cell.

I don't know what the brown out voltage is set to, you'd need see the source code to tell for sure. I'll try some tests later today to see if I can determine if whatever it's set to is working as it should.


#21

Katie,

With a 330 Ohm resistor, the voltage drops to 2.82V.

I just bought 2 new batteries, and without load, the voltage is 3.27~3.28 V (vs 2.92 V for the original batteries).

So the original batteries in the HP-15C I bought were either bad from the beginning, or got depleted extremely quickly (I barely used the machine before the problem started to occur).

So far, no error with the new batteries. Your idea is probably correct, which would mean the 'low bat' detection may need a review.

Thank you

#22

Edit and Run


#23

Quote:
Edit and Run

Interesting - so it may be something in the 15c edit routine that's tripping up the emulator code? And there's still the possibility it's a hardware problem on your 15C LE, particularly since no one else can reproduce it.

Katie: I was thinking about a low-battery related problem as well, but you'd think the errors would be more randomly distributed. Benoit's problem seems to crop up with particular key strokes and, maybe, a particular location in memory. Maybe it's both? If he's got a duff byte in memory that's more sensitive to voltage than it should be, when the edit routine tries to manipulate it, it fails. It's interesting that he always gets the same error. Maybe a sticky "4" bit?

Benoit: Could you try changing your code to swap your use of registers 1 and 2? If the error then changes to "2" becoming "6" that would seem to indicate a bit flip issue, likely in hardware.

Also, do you have any fresh batteries? Might be interesting to see if the problem goes away.

Thanks for trying all this. Barring some freak battery problem I'm guessing that you'll need to return your calculator, but it would be good document the problem here in case it crops up again.


#24

The bug which modifies a memory location when a self-test is executed may be related to this one. Try if an ON+/ sequence or similar causes the same program space corruptions.


#25

Marcus,

I presume you mean turning off the machine, then pressing ON and + together, then releasing +, then releasing ON?

I get ERROR 9


#26

Error 9 is the hardware error message for the original HP-15C and other Voyagers. It appears that your unit is faulty.

Edited: 2 Oct 2011, 10:17 p.m.


#27

Nope.

TW


#28

Care to elaborate.


#29

The self-tests for the original 15C were not supposed to be in the 15C LE or its manual. Getting an error from the doesn't signify that anything is wrong.

#30

Quote:
The bug which modifies a memory location when a self-test is executed may be related to this one. Try if an ON+/ sequence or similar causes the same program space corruptions.

I hazard that isn't the case. Furthermore my earlier suspicion
of HP having a bug in their Voyager/NUT emulator where the
failing self test can't corrupt memory I now believe is incorrect.
The original 15c firmware (perhaps others in the series as well)
do indeed modify/corrupt memory in the case the system test
fails.

I'd inadvertently backed out the patch in KEMU which supports
self test on the 15c, and found the self test to then fail which
corrupted an existing program. So that's apparently been the
behavior of the firmware all along, but with a legacy 15c
doing so was a non issue.

#31

Bob, Katie,

RCL 2 did turn into RCL 6, so the hypothesis of a weak bit impacted by a weak battery seems the most likely...


#32

It'll be interesting to see if the problem is resolved after replacing the batteries.


John


#33

Bad news. I did some testing and if there is a brown out detection level set it's not working. When battery voltage drops below around 2 volts or if the batteries can't supply the needed 20ma of current (when running) you will lose all memory and possibly corrupt memory before that happens. I haven't seen any low battery indication warning before this happens either.

This is a serious bug.

The 12C+ seems to have the same problem, BTW.

Edited: 2 Oct 2011, 9:36 p.m.


#34

Ouch! Better keep a supply of 2032's on hand.

Best,

--- Les

[http://www.lesbell.com.au]

#35

Katie,

I am afraid you are right.

I run a few additional tests: after running the PI calculation program just 4~5 times (total run time < 10 minutes), I checked the brand new batteries (3.27~3.28 V unloaded before use) and they showed 2.95 V unloaded. Half an hour later, machine OFF, they had barely recovered to 3.0V. So the batteries really take a beating - makes me wonder whether you can run long programs without errors, and whether you need to change batteries all the time... (the 2 new CR 2032 cost me $10...)

What's next? Is HP reading this? Can we expect a firmware fix? What do you think?


#36

Hi Benoit:
Did it work OK with the new batteries? At least initially?

Katie:
Ugh - that's *not* good news, but I'm still thinking Benoit has a unique issue (or perhaps a unique manifestation of the brown out issue) with his 15C LE...thoughts?

Bob


#37

Hi Bob,

It did so far but the batteries seem to deplete very quickly.

I probably have a sensitive machine, but from what Katie found, I suspect that the same phenomenon will appear, without warning, on all machines as their battery wear out.

#38

Quote:
I'm still thinking Benoit has a unique issue (or perhaps a unique manifestation of the brown out issue) with his 15C LE...thoughts?

I agree, there's probably a weak bit in memory, or maybe several ones. But if the BOD (brown out detection) was working properly he likely would have never have known this. Probably his tests were causing the battery voltage to sink below the minimum memory retention voltage and he's seeing the one bit die as an early warning sign.


#39

Katie: Yep - that's probably what's happening. Benoit's calculator might be out in the statistical tail and consequently he was the first to notice the problem.

Benoit: Your calculator seems to have a unique issue no one can reproduce, so you might want to think about a return.

Edited: 3 Oct 2011, 9:42 p.m.

#40

$10? just buy these. :) Even if 50% of them are dead, it would still be a better deal. Though waste becomes a problem if you just need 2 or 4 of these. . .

#41

A good pair of CR2032 can be bought for +- an euro. You hust have to find the right place (for example: https://www.electronic-shop.lu/115137.html ).

Nevertheless, this is not a solution to this new problem.

#42

I think Cyrille said that the battery level is checked only every 50 keystrokes or something like that.


#43

Quote:
I think Cyrille said that the battery level is checked only every 50 keystrokes or something like that.

I remember that too, although it might have been in conjunction with the 20b/30b not the 12C+.

However I just torture tested my 15C LE and no matter what I do, no matter how many keystrokes I press, no mater how slowly the voltage decreases, I have yet to see the low battery indicator come on (outside of the self tests). When the voltage gets low enough or the batteries can't supply the needed current memory is lost.

Furthermore, even if the low battery light comes on the ARM chip should go into brown out mode and protect its memory, and it's clearly not doing that. So running a long program will not only kill the batteries it will clear memory.


#44

Katie, can you test this with a 12C+. It's a volume model which might cause error corrections getting a higher priority.


#45

I just tested my 12C+ with firmware dated 2009-11-19, which should be the latest but might not be what's in the majority of calculators in production, there are several versions out there now.

Anyway, I get exactly the same results as I found with the 15C LE. The low battery indicator never comes on and memory is lost when the battery voltage gets low enough.

This is really bad, but not as bad as the in the 15C LE: there's less memory to lose in the 12C+, most users have probably never entered a program, it doens't have the key-down 20ma current draw problem (therefore much better battery life) so this issue will not surface as often.


#46

This should get the attention of Cyrille and Tim, I hope.


#47

Ditto.


Edited: 3 Oct 2011, 7:55 a.m.

#48

Is it a firmware bug, or is it a hardware problem?

I think to remember s.o. (you?) wrote that in an earlier firmware version for the same hardware (12c+, 15c LE) the battery drain problem wasn't there.


#49

If the drain problem wasn't there and the PSE bug wasn't there on that said earlier firmeare version: would one of the beta testers care to share that version here? Please :)

#50

I wrote that the battery drain was not a problem on the 12C+ when keys were held down. On the current release of the 15C LE, the current draw when pressing and/or holding down a key is the same as running a program, 20ma.


#51

Just another plea for new HP 15C LE new firmware.

As long as running a program or keeping keys pressed may cause loss of memory contents, the new calculator doesn't deserve a "C" symbol after the "15". And, sadly, it may also be said that the "limited" word in the "limited edition" string has little to do with the number of units manufactured...

Let's hope that a new firmware revision will correct this situation... and the PAUSE bug too!

I really like to have my new 15C, and I congratulate the people pushing it into reality in a less-than-optimum context... I just expect these issues to be solved soon.

#52

have just been looking over datasheets for various brands of CR2032 cells. to cut a long story short, the MAXIMUM continuous current draw allowed by any manufacturer seems to be 3mA. given two cells in parallel, this translates to a MAXIMUM of 6mA total current draw by the 12C or 15C calculator.

at 3mA from each cell, the normal CR2032 capacity of 210mAh will be reduced 150mAh at an operating temperature is 23 degrees C. so one would expect a 'running' time of 50 hours [based upon CR2032 datasheet from Mitsubishi]

up at the 20mA level - 10mA per cell - the storage capacity of the cell will (based upon projecting up from lower current drain characteristics) will be almost nothing. that is, if the cell is empty within minutes is will be due to NO fault of the cell manufacturer nor any cell design fault. quite simply, this discharge rate is outside of operating specs (the closet i can find is a pulse discharge of 15mA for 15 seconds, with no ratings provided below a 2.6v terminal voltage - this is perhaps why low voltage sensing is turned off in the firmware!!).

as i follow the unfolding of other's follies, i hear a mantra playing in the background:

THERE ARE NO FREE LUNCHES. THERE ARE NO FREE LUNCHES. THERE ARE NO FREE LUNCHES. THERE ARE NO FREE LUNCHES. THERE ARE NO FREE LUNCHES. THERE ARE NO FREE LUNCHES. THERE ARE NO FREE LUNCHES. THERE ARE NO FREE LUNCHES. THERE ARE NO FREE LUNCHES. THERE ARE NO FREE LUNCHES.

the candle that burns brighter burns out proportionately quicker. in that case, it burns out even quicker still. the only sane engineering solution is for HP to release firmware for the new 12C and 15C calculators that limits speed such that current drain remains below 3mA per cell (6mA in total). it would be prudent to limit the current drain even further.

this would, of course, mean that your shiny 'new' calculator is only a paltry 10x faster than the old one - but at least it then might give accurate numeric results...


#53

This sort of issue is one of many that will deny the 15C-LE status as a bona fide re-issue of the 15C. No one ever picked up an extremely I/O and memory limited device like the original 15C and wondered "What limitless possibilities could be explored if only the 15C were one hundred times faster?" Instead, the much greater quality and battery life of the original 15C assures that the original 15C will always be the ultimate Voyager.

The re-issue of any old calculator through emulation on a much faster processor system grossly aggravates the battery energy depletion issue. The Savage Benchmark run on the HP 30b (not emulated), compared to the same benchmark run on the HP 15C-LE, performs it with a results error that is 55 times smaller in one-eighth the time. Problems that can be performed on both machines will use eight times more battery energy on the 15C-LE, compared to the 30b. All one can say good about emulation is that it is valuable if that is the only way machine performance can be upgraded, such as that emulated HP 49g known as the HP 50g.

Emulation should be abandoned for all future products. The original programmers were smart enough to program within the limits of the available hardware 30 years ago...why should that not be expected for current programmers and the hardware available today?

Edited to correct 49g+ to 49g.

Edited: 3 Oct 2011, 7:58 p.m. after one or more responses were posted


#54

Quote:
This sort of issue is one of many that will deny the 15C-LE status as a bona fide re-issue of the 15C [...]

a nearly 30 year old 15C has a fairly good chance of still being fully functional today. the IC fabrication technology was optimized with extra internal layers to promote long life. the keyboard was engineered with materials far exceeding the design requirements. the plastics chosen and moulding methods used stood the test of time. the original machine was built to the mantra: ONE calculator to last the LIFETIME of the owner.

a 2011 model 12C/15C is built using a processor with a designed materials lifespan of perhaps 10 years, keyboard (including contacts) and plastic parts that are 'just good enough'. the LCD is attached with a printed flex + glue system that is known to fail over time (several years) - though said failure will in 99% of units be safely outside of the 1-year limited warranty. and the PCB assembly uses a lead-free soldering process that is guaranteed to fail before this decade is out.

the technology all round is a compromise that (a) minimizes cost, (b) maximizes shareholder revenue, while (c) producing a product that will just adequately fulfil the expectations of a 21st century consumer that is used to a disposable calculator that will need to be replaced after a few years because of irreparable failure.

not wanting to criticize the modern 12C/15C design team - they have done a great job (ignoring keyboard failures in one batch and power-hungry firmware) to fulfil the modern design specifications - but the modern 12C/15C is as much a collectable 'design classic' as a $1 plastic flower pot painted up to look like a ming dynasty vase.

Edited: 3 Oct 2011, 2:50 p.m.


#55

Quote:
the modern 12C/15C is as much a collectable 'design classic' as a $1 plastic flower pot painted up to look like a ming dynasty vase.
OK, I can live with that, but then why does it have to cost me $99?

#56

Quote:

OK, I can live with that, but then why does it have to cost me $99?


see point (b) above:

"(b) maximizes shareholder revenue" :-)

Edited: 3 Oct 2011, 3:08 p.m.

#57

So I just write:

The new HP-15C limited edition is crap. And all has been said.

HP can muschel me.

#58

Quote:
that emulated HP 49g+ known as the HP 50g.
You mean that emulated HP48G/HP49G known as the HP 49G+/HP50G.

#59

You're absolutely correct. I didn't intend to put the + sign after the 49g. Thanks, I'll correct the post.

#60

Quote:
This sort of issue is one of many that will deny the 15C-LE status as a bona fide re-issue of the 15C. No one ever picked up an extremely I/O and memory limited device like the original 15C and wondered "What limitless possibilities could be explored if only the 15C were one hundred times faster?" Instead, the much greater quality and battery life of the original 15C assures that the original 15C will always be the ultimate Voyager.

Agreed. Except for raw calculation speed, IMHO the legacy
voyagers are superior in every way, no qualifiers needed,
end of conversation.

But it is even more staggering considering they were designed
back in 1980-81. As one example for benefit of perspective,
have a look at the PPC/museum holy scrolls of the NUT cpu
instruction documents banged out on what appears to be an IBM
mainframe class line printer. This level of engineering
achievement despite arguable rock and stick tooling is beyond
impressive.

Quote:
All one can say good about emulation is that it is valuable if that is the only way machine performance can be upgraded..

Well it allows leveraging legacy technology which is otherwise
prohibitively expensive to re-engineer for a given application.
The 15c le would never be here otherwise.

Quote:
Emulation should be abandoned for all future products.

I believe I've also reached that conclusion. Yet there is
something quite seductive about seeing 30 year old firmware
spring into life in the context of your handiwork. But unless
the associated firmware can reasonably survive as a black box,
it will soon be beyond the point of diminishing engineering
return.

Quote:
The original programmers were smart enough to program within the limits of the available hardware 30 years ago...why should that not be expected for current programmers and the hardware available today?

I do indeed sympathize with the emotional outcry.
But to be fair it isn't at all a programmer/programming skill
limitation. The prospective market in 2011 just won't sustain
a business model developing pie-in-the-sky, clean slate pocket
calculator products as was possible in 1982.

#61

The datasheet for Energizer CR2032 cells shows the anticipated capacity for several pulse load scenarios including up to 23mA (brief) current pulses per cell. There is even data showing the effects on output voltage of a 30mA pulse for two seconds on a cell. I believe the data from this manufacturer suggests that a pair of CR2032 cells in parallel is at least a viable power source for these calculators provided there is some provision for limiting the duration of the 20mA pulse and correctly determining the brownout voltage in order to prevent corrupting RAM data. Here is the data sheet.

http://data.energizer.com/PDFs/cr2032.pdf


#62

There's nothing on this sheet that comes even close to the load the 15C LE put on the cells. Just pressing a key is a 20ma pulse lasting around 100mSec (depending on the user). The 23ma spec is for "1mSec ON / 14mSec OFF". So just entering a number exceeds this spec by a factor of 100.

I think the spec sheet was totally ignored in the power design of this machine. The firmware needs a total revamp in this regard.


#63

OK, my head is spinning with all this power demand technical stuff.

But what does this mean vis-a-vis HP's stated battery life (1 year normal use)? Is that a complete fabrication? Should I go out and buy a bulk pack?

Has anyone had their cells fail yet (normal usage)?


#64

If "normal use" was defined somewhere I could tell you.

I just did a little calculation/guesstimate (on the 15C LE of course!) that resulted in a 1 year battery life if all you did were 50 simple additions of two 5-digit numbers every day. The major assumptions I made where: that you spend 1/10 second pressing a key down, that battery life is degraded by a factor of 5 from the spec due to the excessive 20ma current pulses, that you have new Energizer CR2032 cells to start with. I think that these are reasonable assumptions.

But this calculator was made to run programs and invert matrices and more substantial, power hungry things. So battery life is gong to be less if you use it a lot, maybe a lot less.

Edited: 3 Oct 2011, 4:28 p.m.

#65

across several manufacturers there are some limited specifications for drawing 10mA for 15 seconds. but the drop in terminal voltage is the killer at this high a current, and in most cases a long recovery time is mentioned (10 pulses/day for one manufacturer).

i suspect the 10mA/15sec figures are included specifically for applications where two CR2032 cells in series are being used to drive a white LED. in such applications nobody cares too much about cell capacity, or indeed wrecking the cells.


Edited: 3 Oct 2011, 4:06 p.m.

#66

Quote:
The datasheet for Energizer CR2032 [...]


unfortunately one can not guarantee the user will always use Energizer brand cells. from a design perspective it is necessary to select a power scheme that respects the specifications of at least most middle-of-the-road average-quality cell brands. assuming it is not acceptable (or practical) to have a calculator that runs at full-throttle for the first 2 seconds before slowing down, one has to select a current draw while 'running' that is sustainable on a continuous basis.

at the current 10mA/cell the terminal voltage will dip down below the nominal low-battery level specified by most every manufacturer after just a few seconds. it is, therefore, impossible to detect low-battery voltage while a program is 'running' at the currently implemented speed. this is a simple fact.

given the demonstrated memory corruption, it can therefore be concluded that one can not with any certainty guarantee correct calculator operation (more specifically, numeric results). i would suspect that any historic reliability of the original 12C/15C binary code (often mentioned) is completely swamped by this failure of the modern hardware/firmware.


#67

Quote:
unfortunately one can not guarantee the user will always use Energizer brand cells. from a design perspective it is necessary to select a power scheme that respects the specifications of at least most middle-of-the-road average-quality cell brands.

I really don't know much about the CR2032 "coin" cells, but my experience with using "button" cells like the formerly ubiquitous LR44/357 for many years, is that all name-brand cells of a given chemistry perform similarly, and the cheap Chinese brands are junk.

Edited: 3 Oct 2011, 5:01 p.m.

#68

Unfortunately I could not always find pulse load data on various manufacturer's CR2032 datasheets (that should be a red flag). As you suggested earlier, "the only sane engineering solution is for HP to release firmware for the new 12C and 15C calculators that limits speed such that current drain remains below 3mA per cell (6mA in total)." And fix the bug that causes the high current draw while a key is pressed. Of course they could no longer advertise the 15-CLE being up to 100x faster than before.

The HP20b and HP30b have the same potential issues. Cyrille did mention (on 14 Apr 2010) for the HP20b that "The latest version of the SW only uses high speed when needed, and only for a short period, after that, it drops back to more manageable levels for the battery. since most calculation that will finish in any reasonable time will finish before the speed drops, it seems to work well." That probably still does not address the issue of momentarily drawing current beyond what the cells are rated for.

In the case of my WP-34s (it was a HP30b in a previous life), I now run it in SLOW mode to save battery life. I did this after noticing the low battery indicator flashing on and off when I was running a program in a tight loop. Using the batteries that came with the unit, the battery voltage (as measured by the BATT command) was around 2.6V after a few seconds of my program. New batteries were much better (for now).

By the way, I really love this WP34s calculator.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime graphing bug BruceH 1 408 11-19-2013, 08:14 AM
Last Post: Joe Horn
  HP Prime - another cosmetic bug BruceH 3 511 11-12-2013, 02:18 PM
Last Post: Ken Shaw
  HP Prime Bug bluesun08 19 1,549 10-14-2013, 10:48 PM
Last Post: Han
  HP Prime bug in EDITMAT Han 7 826 09-27-2013, 10:15 AM
Last Post: Han
  OT - A lucky find - Busicom Handy-LE LE-120A Cristian Arezzini 2 450 09-26-2013, 04:43 AM
Last Post: Cristian Arezzini
  Low power warning for HP-15C LE and batteries Nick_S 1 392 09-16-2013, 09:34 AM
Last Post: Hans Brueggemann
  [HP 39Gii] - Bug report Jean-Michel 1 400 08-28-2013, 10:53 AM
Last Post: Tim Wessman
  HP 15C-LE replacement still available? Borja 16 1,411 08-22-2013, 11:16 AM
Last Post: Michael de Estrada
  JTAG on HP-12C and HP-15C LE Ingo 5 747 07-01-2013, 06:37 PM
Last Post: Paul Dale
  Is the HP-35S bug free? Matt Agajanian 22 1,706 07-01-2013, 04:03 PM
Last Post: Andrés C. Rodríguez (Argentina)

Forum Jump: