Friday, May 24, 2013

Signs Of Life (this time it's for real)

Two fairly major bits of progress were made yesterday on the Imlac restoration.

First, I got the 5V supply working properly.  I replaced the faulty power transistor, but this made no appreciable difference; the voltage went up from 1.25V to 1.5V so it had a small effect but this was still far off from correct.  There's a large heatsink for the four power transistors Q1-Q4 and I noticed that after being powered on for just 30 seconds or so this was getting extremely warm -- this hinted to me that something was drawing a lot of current, possibly a short or a faulty component somewhere.
Mystery Coil.

I immediately suspected the component to the right which is mounted on the rear panel along with the memory system. I'm unsure entirely what its intended purpose is; I've been discussing with my (much more knowledgeable) friend Ian and he suspects it's used for current limiting purposes.  However, the way it's wired up makes no sense to either of us.  The yellow wire is connected to the +20V unregulated supply, and the blue wire is the +5V regulated power supply.  I have no schematics for this particular section so right now it remains a mystery.

At any rate, it was also getting incredibly warm so it was a good candidate for being the current sink that was drawing the 5V supply down so dramatically.  I disconnected it from the +20V supply, powered the system up again and now the 5V was at 5.02V.  Nice.

Until I work out what the mystery coil is for, I won't be attempting to power up the memory boards, but until then I still have plenty of work to do on everything else.


The 5V supply under load
I hooked the 5V supply up to a moderate load (a 12V automotive bulb) and let it run for a half hour or so.  The voltage remained stable and ripple free.

Since everything checked out it was time for the fun part:  Powering up the CPU for the first time in 20-30 years.  I reinstalled the cards I'd previously removed, and powered it up.  Nothing exploded and the universe didn't collapse in on itself.  Voltages were nominal.

I powered it down again and installed the cabling to the "Control Console," and reapplied power.  LEDs lit up -- now we're cooking with gas. 

The Imlac, running for the very first time
Amazingly, many many front panel functions are working properly.  There are a few stuck bits -- Bit 3 the Memory Address register is stuck on; Bit 1 of the Memory Buffer register behaves erratically; Bits 3 and 6 of the Accumulator register are broken, and Bit 15 of the Program Counter behaves oddly.  But all of the registers increment properly when incremented using the "Read Next" or "Store Next" toggles, and I can load data into the registers mostly successfully (ignoring the stuck bits). 

Hitting the "Start" toggle causes the "Run" light to come on (though it doesn't do much since all memory is zeroes) and the processor seems to go through the motions of single-stepping and single-cycling if I enable those toggles.

This is a very encouraging sign -- I was honestly expecting no response at all -- having just this basic functionality working means that a good deal of the main CPU logic is at least minimally functional.  Though if all of the stuck bits are any indication, there are likely to be a lot of faulty components to trace down.

I spent an hour this evening debugging the stuck bit in the Memory Address (MA) register.  Bit 3 is stuck on (note for those playing along at home, the bits on this machine are numbered differently than most modern systems -- bit 0 is the MSB, bit 15 is the LSB).  The question is, what component is at fault here?  There are several possibilities:
  1. The front panel is incorrectly displaying bit 3
  2. The front panel is incorrectly loading bit 3 as a "1" all the time (a broken switch, for example)
  3. The buffer in the CPU that holds the address has bit 3 stuck
  4. Logic between the front panel and the buffer in the CPU is mangling data
  5. Gremlins
#1 and #2 are immediately suspect, since Bit 3 behaves correctly for other registers on both load and store.

A pair of Buffer Control boards
To further rule out the front panel, we can try invoking some operation that updates the Address independently of the panel.  The only operation we have at our disposal is incrementing (via Read Next or Store Next).  With bit 3 already a "1," loading bits 4-15 with "1" and doing an increment should normally cause overflow into bit 2 and reset bits 3-15 to zero.  However, on the Imlac bit 3 remained on and bits 4-15 were reset to zero (bit 2 was untouched).  These simple tests eliminated #1, #2 and #4 from the above list -- the front panel is not at fault here.

The Buffer Control boards at right are used for control and storage for most of the registers in the machine (the Accumulator uses a different set of boards).  These are generic and interchangeable -- each board stores 8 bits of a register, so each register uses 2 of these cards.  The MA register is implemented as cards 208 and 209, for example.  208 controls bits 1-7, and 209 controls bits 8-15.  (Note that 208 does not control bits 0-7 -- the PDS-1D is limited to a 32K address space, so the MSB is not used).
1/2 of a Buffer Control board


From the schematic at the left you can see that the logic is fairly simple; we have a 74161 4-bit counter which provides the incrementation support, the outputs of this are connected to a 7495 4-bit shift register.  This provides the ability to shift the address by one bit in either direction -- but for the MA register these lines are unused and are not connected to anything on the backplane (the Memory Buffer register does use these lines to provide support for the shift and rotate CPU instructions).  The input to the 74161 passes through a 74H52 AND/OR gate which collects inputs from various sources (the front panel, the Program Counter (PC) or Display Program Counter (DPC)).

So, if bit 3 is stuck, who's to blame?  My first guess would be the 74161; since it's responsible for incrementing the upper 4 bits of the MA value, and since bit 3 does not change when bit 4 of MA is incremented it seems a very likely culprit. I 'scoped out the input (pin 4) and output (pin 13) and pin 4 was a steady 1.8V, pin 13 was a steady 3.8V and were completely unaffected by inputs from the console.  It's still possible that the 74H52 is pulling the input to pin 4 down but it's difficult to prove, at least given my still limited debugging skills.

I took a gamble and replaced the 74161.  Afterwards, Bit 3 was still stuck on, but I could occasionally get it to go out now, however the behavior was pretty random -- setting Bit 4 and then clearing it would cause Bit 3 to go out.  Any other operation would cause Bit 3 to come back on.  Weird.

At this point I figured it had to be the 74H52 so I replaced it as well.  Success!  Bit 3 works correctly now, and now the MA register seems to be 100% working.

With the MA repaired I can now address the boot ROM, which lives at address 40 (octal).  I can successfully read the boot ROM using the front panel (modulo the bug in the Memory Buffer register)!  This means that the memory addressing logic is working correctly, which is another bit of good news.

That's enough for tonight.  I plan to do two things to make debugging and repair easier:
  • I need an "extender" board (similar to these, only smaller) for Imlac cards, so I can access the logic more easily.  (I debugged the MA board by tacking wires onto the chip leads with a bit of solder -- this is a royal pain in the ass.)  I plan to construct one or two of these before I continue the repair work.
  • Having a better supply of 74XX series logic on hand would be very useful so I don't need to run out to the store every time I find a faulty chip.  I plan to order a small sampling of the chips commonly used in this machine so I'll have them when I need them; even if I don't use them in the Imlac they'll be useful for other repair projects.
 Egads, it's late.  That's all for now, catch you on the flip side, Kidd Video!

No comments:

Post a Comment