Advice for a recalcitrant 29c

[[kby]]

I have a 29c that I don't seem to be able to make further progress on (although it's "better" than when it started, at least).

This 29c arrived with no display on power-on The power supply voltages looked OK (powering from charged NiCd batteries; no charger), but there was no Phi 1 or Phi 2, so I replaced the ACT with one from a -67 logic board (same chip number).

At that point, the calculator does show signs of life. It powers up to "Error" (which now blinks once and still says "Error"; can't remember at the moment whether it was the same just after replacing the ACT, but I would guess it was). I was maybe 90% sure the ACT from the 67 was OK as I think the only thing wrong with the logic board was I'd removed the CRC (can't remember why; might have thought it was the ACT long long ago), and it had the buggy -67 ROMs.

A more detailed note of the behaviour:
1. Always powers on to "Error" that blinks once, even if batteries are not removed.
2. Pressing any key clears "Error" and results in "0." in the display.
3. Key presses seem to register (display blinks when key is pressed), but many don't work as expected. Digits, if entered by themselves, change the display to "0.00000…0 00" (e. g. full scientific notation of 0). PRGM/Run switch works properly. SST/BST work properly in both Run and PRGM modes. Function keys sequence properly although the display still winds up being 0. at the end: for example, if you give "f ln" in program mode, the program counter does not advance until you hit the ln key (which is the 7 key). In Run mode, f ln yields "Error" after hitting ln, as it should. Since I can't get any other numbers in, it's hard to test much else functionally. All prefixed operations appear to execute in the sense that the sequence of keys is processed as expected (e. g. f ln requires two keystrokes; sto + 3 takes 3), but every thing results in "0." at the end (unless it's an error as in f ln). In short, keystrokes do seem to register sort of correctly, but no useful results can be obtained. Operations don't get entered into program memory in PRGM mode, even though the step counter advances; program memory remains all 74s (R/S).

I obtained a copy of the service manual and with its guidance have tried the following, using chips from a 19c that had mad printing disease originally, and now parked the head but still seems to have the motor energized. I understand that its chips may thus be suspect, although the symptoms above have not changed regardless of what I've done, so unless the failure mode is the same, it seems unlikely.

1. Replaced ROM 3
2. Replaced ROM 1/DS 1
3. Replaced DS 2
4. Replaced the ACT again with the one from the 19c

Reading through the failure chart, ROM 0 seems unlikely as CLEAR PRGM, CLEAR Prefix, SST, and BST are known to work. ROM 2 seems to be dedicated to trig functions, so, although it may or may not work, it shouldn't cause this problem. DS 0 are the primary and statistics registers; again, it could be bad but it seems I haven't been able to get far enough to have this be testable. The LLD chip seems like it might affect the "Error" message on startup, but nothing else.

I think I've vinegared the board, but it looks clean; no obvious corrosion or missing traces, although many of the traces go under chips. It's a little hard to test the continuity without a board picture or pulling off all of the chips at once.

Any thoughts? Thanks.

[teenix]

(06-06-2019 03:09 AM)[kby] Wrote:  I have a 29c that I don't seem to be able to make further progress on (although it's "better" than when it started, at least).

1. Always powers on to "Error" that blinks once, even if batteries are not removed.

Reading through the failure chart, ROM 0 seems unlikely as CLEAR PRGM, CLEAR Prefix, SST, and BST are known to work.
Any thoughts? Thanks.

ROM 0 is responsible for the 'Error' display at initial power on or normal display otherwise. It is also first port of call for all calculator functions so it could have a bug in it.

cheers

Tony

[[kby]]

Ugh. I'll keep it in mind; I have no spare (so that means finding another machine or a Panamatik ACT, I guess. I'd like to keep it close to original if possible at this point.

29c field service suggests issues with the "Error" appearing on power-up should be ROM 3, although it points to ROM 0, but the ROM 0 note on the "Error" topic only speaks of having incorrect characters in "Error", which is not the case. Or is this not accurate?-kby

[teenix]

Just looking a bit deeper, at power on ROM0 executes initially, then ROM3 and DS1 are responsible for the Error display.

RAM register 46 in DS1 is tested for the 56 bit value 03493428400200 at power on. If this value is not there, then all RAM is cleared, that value is stored, and 'Error' is displayed

Assuming the battery is ok, on the next switched power cycle, that value will still be in RAM (assuming ROM and RAM are functioning OK) and the test will succeed, so RAM is not cleared and the calculator continues as normal.

cheers

Tony

[[kby]]

Thanks; that explains a lot.

I did just try GTO .nn in program mode, and that also does work, so digits are getting entered.

I also neglected to mention, with both working (?) ACTs, the Phi1 & 2 clocks seem a bit faster than I recall seeing spoken of elsewhere—about 206 kHz. Could this be an issue? It's not 2x like something I read in one of Katie's posts, but it seems faster; I've usually seen numbers in the 175–185 kHz range in other people's posts.

[teenix]

(06-06-2019 07:35 AM)[kby] Wrote:  Thanks; that explains a lot.

I did just try GTO .nn in program mode, and that also does work, so digits are getting entered.

I also neglected to mention, with both working (?) ACTs, the Phi1 & 2 clocks seem a bit faster than I recall seeing spoken of elsewhere—about 206 kHz. Could this be an issue? It's not 2x like something I read in one of Katie's posts, but it seems faster; I've usually seen numbers in the 175–185 kHz range in other people's posts.

Probaby won't matter much, but a possibility - C2 a 330pF timing capacitor on pin 13 of the ACT might be lower in value due to age. The oscillator is around 715KHz so phi0 phi2 should be around 178KHz. The CRO pictures in the manual suggest around 167KHz.

cheers

Tony

[rprosperi]

Though I am well over my head even commenting here, it may be relevant that Panamatik pointed out in a different thread only a day or two ago that the 29C (unlike other Woodstocks) stores its X register in the RAM chip, so perhaps the RAM chip is bad; that seems consistent with some of the symptoms described, if I am following your discussion.

[[kby]]

(06-06-2019 01:15 PM)rprosperi Wrote:  Though I am well over my head even commenting here, it may be relevant that Panamatik pointed out in a different thread only a day or two ago that the 29C (unlike other Woodstocks) stores its X register in the RAM chip, so perhaps the RAM chip is bad; that seems consistent with some of the symptoms described, if I am following your discussion.

Thanks for the suggestion. The service manual calls the RAM areas “DS” (Data Store?) and DS 2nis the one that holds x.

This would make sense for any “C” machine as x has to be part of the Continuous Memory and therefore must be in a CMOS RAM area as the ACT would presumably not be powered when the machine is off.

[PANAMATIK]

(06-06-2019 04:40 PM)[kby] Wrote:  This would make sense for any “C” machine as x has to be part of the Continuous Memory and therefore must be in a CMOS RAM area as the ACT would presumably not be powered when the machine is off.

Except for the first "C" machine HP-25C, where X is not part of the Continuous Memory.

This allowed HP to use the same firmware for HP-25 and HP25C for faster time to market. The CMOS RAM chip of the HP-25C just ignored the Clear Memory instruction which is issued at initialization, while the PMOS RAM chip executes this instruction. This is the only runtime difference between the two machines.

Bernhard

[[kby]]

(06-06-2019 11:01 PM)PANAMATIK Wrote:  

(06-06-2019 04:40 PM)[kby] Wrote:  This would make sense for any “C” machine as x has to be part of the Continuous Memory and therefore must be in a CMOS RAM area as the ACT would presumably not be powered when the machine is off.

Except for the first "C" machine HP-25C, where X is not part of the Continuous Memory.

This allowed HP to use the same firmware for HP-25 and HP25C for faster time to market. The CMOS RAM chip of the HP-25C just ignored the Clear Memory instruction which is issued at initialization, while the PMOS RAM chip executes this instruction. This is the only runtime difference between the two machines.

Bernhard

Ah…should have done my research better before spouting off generalities.

Update (but no progress):

Checked connections for continutity (with a meter) the ACT all of the RAM and ROM chips for Phi 1, Phi 2, ground, power supply connections, SYNC, DATA, and IS/IA lines as well as the PORO line and also did a closer visual check. Found some suspect ones, but fixing them doesn't seem to have changed anything.

A couple of anomalies (both probably useless/irrelevant):

1. Display sometimes shows an extra "0." about three positions to the right of the correct one (as well as the correct one on the far left) if you hold down the "GTO" key squeeze the keyboard and battery pack in just the right way at the right point while trying to ensure that the batteries are making good contact. However, that was somewhat reproducible last night but doesn't seem to be now, so I'm attributing it to making the contact actually worse. Similarly, sometimes the "Error" display will show one brighter character with similar extra pressure on the batteries. [ignore this—see note below]
2. arc cos function behaves slightly different than any other functions—returns "0.0" rather than "0." But the display change doesn't persist if you do anything else.

[[kby]]

(06-07-2019 05:16 PM)[kby] Wrote:  A couple of anomalies (both probably useless/irrelevant):

1. Display sometimes shows an extra "0." about three positions to the right of the correct one (as well as the correct one on the far left) if you hold down the "GTO" key squeeze the keyboard and battery pack in just the right way at the right point while trying to ensure that the batteries are making good contact. However, that was somewhat reproducible last night but doesn't seem to be now, so I'm attributing it to making the contact actually worse. Similarly, sometimes the "Error" display will show one brighter character with similar extra pressure on the batteries. [ignore this—see note below]

I’ve figured this was caused by springs in the battery pack shorting some of the keyboard traces when trying to increase/secure battery contact, so this is indeed irrelevant.-kby