HP-10 disassembly/reassembly

[[kby]]

Does anyone have a technique/order/trick for assembly the HP-10 calculator without bending a bunch of the famous board interconnect fingers? The HP-10 (aka the reserve power pack for the Sting series—no continuous memory) has three independent layers of interconnected boards. Two sets of fingers to connect the bottom to the middle; one set to connect the middle to the top (which is the keyboard). Unlike the HP-19c, the middle layer doesn’t connect to the top by a flex cable; the middle board is completely free. It’s difficult to see inside to align all of the pins while putting the keyboard (which is part of the top case) on, so it seems as though you only have a choice of first connecting the bottom two layers and then trying to connect the top by “feel” or connect the top and middle, then connecting that by “feel” to the bottom. In theory connecting the middle and bottom should be easier (2 sets of connectors) and then the top fit by feel, but the already poor interior visibility is worse this way. Thanks in advance…-kby

[[kby]]

To answer my own question, it appears that the proper assembly procedure is to attach the CPU board to the power supply and then carefully fit the cover. If aligned up properly at the bottom, you can usually (but not always) detect when things are lined up for the keyboard to mate to the CPU board without bending pins. But it's still possible, where as the other way (affixing the CPU to the keyboard and then trying to mate that to the power supply) seems nigh impossible. Note that when you take the case apart, the CPU board will generally be attached to the keyboard.

So, many fixed traces and a few parts later, I do have a mostly working "reserve power pack" for my HP-19C, aka the HP-10, but it has one odd problem I'm hoping I can get some hints on: the "5" and "2" keys don't work. To answer the obvious questions:

1. the "8" key does work. Inspection of the keyboard shows that this does make sense; the "8" key is on a different trace.

2. The keyboard does not appear to be the problem. I have figured out with a meter which contacts appear to be closed when the buttons are pushed, and they work. They also work if the CPU board is connected and a meter is used to check the connections that should close. The "5" and "2" keys go into a single pin on the CPU chip. All traces and pins look reasonably clean and firm, but this is not possible to verify with the case completely together. Shifting the case slightly does not help. No corrosion or weak traces on the keyboard.

3. The problem is solid; not intermittent.

4. I have re-soldered the pin of the CPU that the trace connects in to, although it did not look like it was the issue.

The only other obvious answer to me is that that particular pin on the CPU is bad (bummer). That does seem rather unlikely with all other functions working to me, but am I missing something? Can someone (Tony? Katie?) suggest another thing to check?

The machine is a bear to service. Although it superficially looks like at least the printer is the same as the 19C or 97, the logic is somewhat different so that other than the actually printer, parts are not that interchangable. In particular, the quad switching transistor array is PNP whereas the other two machines use NPN. I post this as a warning that you can't assume you can substitute dead chips on a 10 with some from a 19C, let alone a 97.

Thanks in advance for any suggestions.

[teenix]

(02-14-2020 05:45 AM)[kby] Wrote:  ......the "5" and "2" keys don't work.

A voltmeter connected to CPU pin (37) and ground while the calculator is running should show a small voltage change when either of those keys are pressed. A better method is using an oscilloscope which you can see either key press as a low going pulse.

Seeing that you appear to have checked the common trace for these 2 keys back to the CPU pin, it would seem to suggest that the CPU chip has failed.

cheers

Tony

[[kby]]

Tony,

Thanks for the bad news :-(. Seriously, I do appreciate the hints and the verification of my logic. Clearly I would hope it's not the CPU as it is made of (as is said in the classic audio electronics sphere) "unobtainium." But if it is, it is.

I did think of putting a scope on the pin so I also appreciate knowing what to look for. My main issue with actually doing that is how to connect the 'scope with the calculator all buttoned up. I have since figured the only way is to run some leads from the relevant pieces out to hook up the scope. That's not great but the only other alternative seems to be making an equivalent cabled connector to attach the keyboard to the CPU without the machine being put together. Both seem like too high risk for me for a low chance of finding out something that I'm not going to be able to fix anyway.

I did get the idea that maybe I can try cleaning under the CPU chip (without removing it) in case something is parasitically draining off the signal transition. I will likely try that.

I do have a question on your schematic, though, which you gave me an implied answer to in your response, but which leads me to another question. The pins on the keyboard module (other than Vcc and the battery voltages) are numbered, but don't show where they are connected to anywhere else. Your response implied that they connect such that connection "n" connects to the CPU on the pin labelled "Kn." But it also appears there are Kn connections with overlapping values of n to the display. Is that correct, and, if so, why are the display keyboard and CPU connected on the same pins of the CPU?

Thanks again.

[[kby]]

Tony,
From your answer (and further assuming what I asked about in the previous reply), there are some pinout issues on the CPU. The line in question (line 4 from the keyboard) actually connects to pin 36 of the CPU, not pin 37. I took (hopefully) good photos of both sides of the board so I can figure out what else is off.

Sadly, reflowing the solder (again) and trying to scrub out under the chip near that pin didn't help (which is not a surprise, but one could hope). My guess is the pin is disconnected inside the DIP package.-kby

[teenix]

(02-14-2020 09:16 PM)[kby] Wrote:  Tony,
From your answer (and further assuming what I asked about in the previous reply), there are some pinout issues on the CPU. The line in question (line 4 from the keyboard) actually connects to pin 36 of the CPU, not pin 37. I took (hopefully) good photos of both sides of the board so I can figure out what else is off.

Sadly, reflowing the solder (again) and trying to scrub out under the chip near that pin didn't help (which is not a surprise, but one could hope). My guess is the pin is disconnected inside the DIP package.-kby

Yes, I just noticed that the pin outs are not correct. I must have been having a senior citizen moment :-) I'll repair asap.

Sad news for the possibly faulty CPU.

cheers

Tony

[teenix]

(02-14-2020 06:33 PM)[kby] Wrote:  Tony,

Your response implied that they connect such that connection "n" connects to the CPU on the pin labelled "Kn." But it also appears there are Kn connections with overlapping values of n to the display. Is that correct, and, if so, why are the display keyboard and CPU connected on the same pins of the CPU?

Thanks again.

I have changed the HP-10 pin numbering and uploaded the circuit files zip.

Yes that it correct. The same multiplexing method is used in the HP-29C for example.

Each time a cathode driver pin is LO, the LEDs in the corresponding display will get updated from the anode driver. At the same time the A B or C lines are tested. It is possible now that either or all of these lines are LO depending on what keys are pressed.

For example, if K11 is LO, then the LEDs in the 11th display are being updated from the anode driver. If A B C = LO HI HI, then '6' is pressed, if = HI LO HI then '3' is pressed, or if HI HI LO then '.' is pressed.

It is possible that A B C = LO LO LO. In this case the microcode might decide to take the first A B or C that it tests to be the active key, or it might produce a dodgy keycode and the software ignores it.

The DSP, ALL and PRT switches are tested in the same way from the 'E' line by using K6 or K10.

This type of multiplexing can present a problem with the circuit when multiple keys are pressed which is why diode isolation is included on the A B C and E lines from the keyboard.

cheers

Tony

[[kby]]

Tony,
Thanks for the corrections. It now agrees with at least the part I was looking at and helped me to realize that indeed the K12 pin is connected to the display.

Which leads me to a follow-on question. I'm not sure how the entities are defined in your explanation. The basic question is, if, indeed as is surmised CPU pin 36 is dead and unresponsive to keypresses, should there also be some kind of display artifact as well? Can you give me a better idea of what specific (kind of) artifact I should be looking for? I don't see anything obvious, but maybe I'm just not looking carefully enough at the right time.-kby

[teenix]

(02-16-2020 02:53 AM)[kby] Wrote:  Tony,
Thanks for the corrections. It now agrees with at least the part I was looking at and helped me to realize that indeed the K12 pin is connected to the display.

Which leads me to a follow-on question. I'm not sure how the entities are defined in your explanation. The basic question is, if, indeed as is surmised CPU pin 36 is dead and unresponsive to keypresses, should there also be some kind of display artifact as well? Can you give me a better idea of what specific (kind of) artifact I should be looking for? I don't see anything obvious, but maybe I'm just not looking carefully enough at the right time.-kby

I was alluding to an electrical fault on the PCB between the keyboard and CPU pin. It is possible that if all 8's were displayed that the corresponding digit might look slightly dimmer or brighter - hard to say.

A scope attached would at least verify that the correct signal is present. Hopefully not, but you might well see the correct signals getting to the CPU pin, but the CPU may not be interpreting it properly. Maybe the K12 line is driving the display but not LO enough to be detected as a key press. All just guesses of course :-)

The display on HP calcs flickers off briefly while the key press is processed by the CPU. Does this happen on the HP-10, and also the keys in question?

cheers

Tony

[[kby]]

I was alluding to an electrical fault on the PCB between the keyboard and CPU pin. It is possible that if all 8's were displayed that the corresponding digit might look slightly dimmer or brighter - hard to say.

A scope attached would at least verify that the correct signal is present. Hopefully not, but you might well see the correct signals getting to the CPU pin, but the CPU may not be interpreting it properly. Maybe the K12 line is driving the display but not LO enough to be detected as a key press. All just guesses of course :-)

The display on HP calcs flickers off briefly while the key press is processed by the CPU. Does this happen on the HP-10, and also the keys in question?

cheers

Tony
[/quote]

Haven't quite gotten desperate to hang the scope off of it (reassembly of the case is problematic as noted above) and not quite ready to do that for what would seem at best very interesting but not that helpful information.

The display does flicker on other key entries but not the bad keys. The flicker is much briefer than other calculators.

I would say the overall display seems a little on the dim side relative to other machines, but not enough that I could tag it as unusual.

all "8"s look pretty uniform.-kby

[teenix]

(02-16-2020 08:34 AM)[kby] Wrote:  The display does flicker on other key entries but not the bad keys. The flicker is much briefer than other calculators.

That then means pretty much back to square one I suppose. Either the signal is not getting to the CPU in a useable form, or the CPU is faulty.

I know it would be painful, but if it were me, I would solder a couple of wires, (fine wire wrap wire is a good choice) one from ground and one from the CPU pin and see the signals being generated on a scope. To me that is really the only way to find the culprit.

As the K12 line to the display is in parallel with the keys line, isolating it from the display might prove if that is a problem also.

cheers

Tony

[[kby]]

Thanks Tony,

Perhaps when I have more time and if no eureka moment comes up before then I'll consider it. Right now it seems if I ran this test it would tell me it's either the CPU or it's not; if it is, then I have a slightly better confirmed diagnosis; if it's not then, well, it won't necessarily tell me what to look for in and of itself.

Knowing me, I'd probably want to take multiple measurements, like the trace from a "good" key and one from the "bad" keys to compare. And knowing me I'd probably put the test leads in t he wrong place the first "n" times.

I think a strategy that could work, though, for me is to get a bunch more jumper wires with pin clips and just jumper the keyboard to the CPU board. That way I'd be able to take as many measurements as I wanted for only one assembly/disassembly operation. But I don't have that many wires available right now.This would also allow me to put the scope probe close to where it really counts and not worry about any interference on the test wire run out. I suspect jumper wires between the keyboard and the connecting pins shouldn't be a major issue since they're the not-great pin contacts anyways. I agree that it would be really nice to have additional confirmation/information even if the eventual solution doesn't change.

Oh, I did decide to try swapping displays. No change in the symptoms, although the new display is definitely brighter, so any dimness observed before is not completely caused by the issue.

[teenix]

Just trying to summarise things...

As you mention, the A B C and E lines from the keyboard are common and must be working with the CPU or other keys wouldn't work. Also, the K12 line must be working with the CPU or the display digit 12 wouldn't work.

The display is not flickering when those two keys are pressed, suggesting that the CPU is either not seeing those keys, or is not processing them.

The PCB tracks have been tested as being ok on the key board for the 2 and 5 keys all the way to the connectors for the CPU board.

The PCB track from the CPU board K12 connector pin to the CPU pin has been tested and is ok.

Best case, if it is assumed that the CPU works, then the obvious weak link here is the connector pin that connects the K12 line between the two boards. Have you inspected the pin and the mating hole closely. Sometimes, the plating inside the hole corrodes, or erodes away, or the two prong pin is bent inward a tiny bit and will not make proper contact.

A word of caution with these pins. They are brittle and do not like being bent very much at all or they will snap.

You could try shorting the CPU board to keyboard connection for K12.

To simulate key presses, you could also try briefly shorting out the A line to K12, or the B line to K12. This would have be at the anode of the diode on the A (or) B lines to the K12 CPU pin.

If either of these tests work, it points to the connector again.

cheers

Tony

[[kby]]

Excellent summary. I think I actually checked through the connector between the CPU to keyboard connector. Can’t remember for sure if I did cpu pin to cpu pin, but that would’ve been the obvious. This was done by mating the cpu board to the keyboard but not attaching that assembly to the power supply/printer, thereby allowing me to check from the bottom side of the cpu board. That might not be exactly positioned as it is when the whole thing is together, but if that were the issue I would expect I could make it intermittent by slightly moving the case pieces around,which doesn’t help. I have also tried cleaning out the connector holes and pins.

Of course it is always possible I measured something wrong or was on drugs when I was aiming the meter probes…-kby

P.s. I’ve experienced the fragility of the pins multiple times. For now I have adequate spares, but it is something I don’t relish dealing with.

[[kby]]

Abstract: CPU confirmed to have issue.

I finally had time to get to this and had also figured out in the intervening months how to actually take measurements. I realized I could put the machine together except the keyboard and use jumper wires to connect the needed pins between the keyboard PCB and the CPU pcb. This allowed me to run the calculator with the shell open. Only the pins that are necessary to jumper needed to be done, so about
a half-dozen and I could have gotten it down more if I wanted.

The trace can be viewed here (machine is not up all of the time, unfortunately):

https://pdp-10.endoftheinternet.org//~[k...esktop.mp4

As an additional experiment I fed the output from the problem keys to a different keyboard line and got the expected (wrong) numbers entered (in this case 3 and 6 rather than 2 and 5; 2 and 5 are the non-registering keys. I tried the other way, too; using keys that work and mapping them to the 2/5 inputs; no entry. The display does flicker, but no digit :-(.

Does this pretty much confirm that the CPU is bad (seems to me like most likely issue would be the pin is disconnected from the actual silicon).

I might also eventually have to deal with a faint printer, but I might have enough spare parts to fix that.-kby

[teenix]

It sounds like the processor then, and it is possible that an internal chip connection has broken or the logic has gone faulty. If so - a real bummer.

It will probably be tough to replace it or get a separate CPU board.

As the microcode is encapsulated inside the CPU chip with other stuff, it will be difficult to create some sort of replacement. I did write the microcode from scratch for my HP-10 emulator, which seems to work ok, but it is definitely not the original.

cheers

Tony

[[kby]]

Thanks, Tony; I do appreciate the confirmation of bad news.