Our vintage ROM bit is back! And so is the Hakko desoldering iron.

I was eager to try to get my stuck ROM bit back. I donned my Fancy HP Repair Pants and it seems to have helped.

Not having found any obvious short with the HP 547A probe, I decided to try to isolate the ROM 0 from the other chips and see if our bit would reappear. Was the bit still alive in the boot ROM 0? To find out, the simplest experiment was to snip the data bit 5 pin of the chip, as you can see in the picture below. Hopefully this should not be hard to repair with a solder bridge.

I then took a logic analyzer trace from a probe sitting on top of ROM 0, making contact with the top of the pin. If the bit was in still alive in ROM 0, it would still not show on the bus (now it's completely disconnected of course), but it should show on the probe. After a few difficulties, I got the trace below. Look at line 2. The bus data still reads the erroneous 164001, but the ROM data probe I point to at the right reads the correct 3 lower digits! It shows a correct 041, not 001 as we read before. Yep, our bit is still alive and well in the ROM, which is good news.

On the schematics, one can see that data bit 5 of the ROM is connected in parallel with 6 other chips: 4 other ROM bit 5 (U33, U34, U35, U36), the RAM chip towards the right that does all the RAM bit 5 (U20), and the tristate buffer above it (U28). 

So I should first repair my ROM 0 snip, then try to snip each connected pin on these other chips, one at a time. The bit should reappear on the bus as soon as I hit the chip that's causing the problem.

Repairing the snipped bit on ROM 0 was easy, as expected:

My next candidate was the RAM chip, which can be seen being snipped mercilessly in the picture below. Ouch, says the chip.

I ran another trace, and the fault had reappeared. Line 2 reads a faulty 001 again  - our ROM 0 bit 5 is again being pulled to 0. But not by the RAM chip!

So I went on to the buffer. No cigar. Then ROMs U36, U35, U34. Still no cigar. At this point I am getting a bit nervous, as there is only ROM U33 left. So here we go, last snip, everything that was on the bit 5 line except ROM 0 has been snipped. You can see the three ROMs with their pin snipped in the picture below.

And? MY BIT STILL DID NOT REAPPEAR! Still reads 001 on line 3. What gives?

After double and triple checking everything, I could not find any fault in my methodology. So there must be a random short between the bit 5 trace and something else, God only knows where that would be on the board! 

But I quickly reasoned that it most likely would have come from something I did to the board. So far I have replaced 3 TTL chips. The two that were driving the faulty  STM' signal, and the one that let the magic smoke out. So I closely inspected the board under these repairs. And I quickly spotted a problem under the "magic smoke" TTL. Can you see it?

It's on the bottom row of the repair, 4th pin from the left. A trace makes a weird bend and connects to the pin. It's not a solder bridge mind you, it's a real bend in the trace that goes right over the soldering pad of the pin. A quick look at a good board confirms that this is definitely not right. The trace must have physically moved during the rework, I suspect during desoldering. Sure enough, that trace carries data bit 5. Bingo. 

I reheated the area and straightened the trace back into its proper position with an Xacto knife, under the binocular. Much better!

Confident that this was the problem, I fixed all my snipped pins, and ran a logic analyzer trace. Yay! The bus reads the correct 164041, and the processor goes on to execute most of the boot code as it did previously. 

It still does not boot because of the previously identified RAM amnesia problem. But now we can resume debugging that problem in earnest.

In other good news, the Hakko is all back together with a brand new heater, and ready to remove more bad chips. 

We're back in business. Next step: RAM refresh debug.

Marc