Two Steps Forward, One Step Back

Well, it's been awhile since my last update and while I was hoping to post some forward progress with the Imlac, there have been certain setbacks so I'll post about those instead...

Since the last post, I spent some time putting the rest of the Imlac's CPU through its paces and a lot of instructions were working fine, while a subset of them were showing interesting behavior.  In particular, any instruction that addressed memory ended up changing the contents of that memory address, regardless if the instruction was a read or a write.

After doing a bit more playing around, it was clear that the memory contents were being incremented on each access, and I narrowed it down to one of a pair of faulty components in the logic controlling the indirect increment register behavior -- rather than incrementing the memory contents only when an indirect access to an increment register (addresses 10-17) was made, it was incrementing all memory addresses, all the time.

Seemed simple enough, but when I went to track down the fault suddenly the front panel started acting strangely, and I have not yet isolated the cause.

The Imlac no longer runs programs via the "Start" or "Continue" switch, and about half the time, when doing a "Read" or "Store" operation from the front panel nothing happens at all.  The behavior is erratic and appears to be basically random.

I've spent a good deal of time tracking this issue down.  I started by looking at what should normally happen when an operation is triggered by the front panel.  One of the main things is that a set of "T" clocks (T1 through T10) are fired in sequence -- these T clock impulses drive the different parts of the CPU logic at the right time in order for an instruction to execute.  (For example, during the "T2" cycle of a fetch instruction, the PC is incremented by 1, and during T8, T9 and T10 the accumulator is shifted (one or more times) during a Shift operation.)

For the times the front panel operation succeeds, T1->T10 is generated properly.  During those times the front panel operation fails, T1->T10 does not change state at all.  So this issue is clearly related to the generation of the system clock.  The system clock is generated by the "Timing Pulse Generator and Clock" board (slot 215), which as it turns out I don't have schematics for (or so I thought, more on that later).  So, I spent a couple of evenings reverse-engineering the board and drawing up my own.

It became clear that the T clocks were generated only if the "RUN" signal was high and after doing a bit of probing it was clear that RUN was not being asserted when the panel was failing.  So... what generates the RUN signal?  Why, the "Run Control" board (in slot 231), of course!

The Run Control schematic (partial)

 The "RUN" signal is controlled by the output of a pair of J/K flip-flops (the 7476 at E1 in the schematic above).  When a front panel switch (such as the READ switch at the top left of the schematic) is toggled, this ends up triggering the 74121 at E2 to fire a one-shot pulse about 5 microseconds later -- this in turn triggers the PR input (pin 7) of one of the flip flops (labeled "RUN SYNC") which in tandem with the "RUN CLK" signal on pin 6, eventually raises the "RUN" signal, originating from pin 15 (the Q output of the other J/K flip flop -- labeled "RUN") of the 7476.  Whew.

The purpose of this circuit is to synchronize panel operations with the "RUN CLK" signal -- since panel operations are run by humans who do things any damned time they please and the Imlac runs on a very regulated 1.8 microsecond schedule, the 74121 in combination with the 7476 make sure that the operation started by the operator happens at the beginning of one of these 1.8 microsecond periods.

After even more investigation it became clear that the input (pin 7) to the state machine implemented in part by the 7476 was being raised properly, as was the RUN CLK signal, and so I suspected the 7476 to be faulty.  On replacement, no change was noted.

Hmm.  Let's take a closer look at the signals here, shall we?  Using my state-of-the art Tektronix 1241 Logic Analyzer (one of my favorite tools, c. 1988) we see the below when the front panel is working:

The "correct" behavior

As you can see, the "RUN CLK" signal (labeled as "CLK" on the analyzer) is clocking, and at the same time the panel trigger input (labeled as "P") is going low; when P goes high again, the "Q" output (labeled, oddly enough, "Q") changes state to low -- raising the "RUN" signal properly.

OK, so what does this look like when things don't work?

The "incorrect" behavior

 

 

 

 

Here, we see the clock signal being generated as before, but the panel signal "P" is going low in between clock pulses!  So in this case, the "Q" output does not change state, and thus "RUN" is not properly raised.

So it seems clear that one of two things is broken here:

1) The "P" signal isn't getting generated properly (i.e. it's too short and so it's not reliably overlapping with the RUN CLK signal)
2) The RUN CLK signal is incorrect (i.e. the duty or "on" cycle is too short, leading to the problem discussed in (1) above).

After investigating possibility (1) for quite awhile it seemed that the 74121 was operating properly, as was the cute R/C network set up to fire the one-shot pulse for the "P" signal.  I'm still not 100% certain as I don't have any frame of reference for what characteristics this pulse is supposed to have.

I also spent a good deal of time investigating issue (2) and there's nothing obviously at fault.  However, looking at the RUN CLK signal with the oscilloscope reveals this waveform:

The RUN CLK signal

Which doesn't look incredibly "clocky" to me -- normally I'd expect this signal to look much more squared off and even -- those spikes (which correspond to the "on" duty cycle in the CLK signal seen in the logic analyzer photos) do not look good to me.  However, once again I have no frame of reference since I have no idea what characteristics this waveform is supposed to have.  Ahh, to have a service manual...

I even brought in the big guns on this one, my friend Ian who knows a lot more about this stuff than I do (it's his day job) and he was stumped too.  We're still working on it, and I know we'll get to a solution eventually.

In the meantime, I've shot off a mail to Tom Uban, the owner of the only working Imlac I know of, to see if he'd be willing to grab a photo of the RUN CLK signal on his machine.  He's graciously offered to help me out, but it'll be a few weeks.

So, eventually I'll get this machine running again.  Just a minor setback...

Meanwhile, I thought I'd look through the PDS-1 schematics on Bitsavers -- since the PDS-1D schematics have no timing details in them, I thought I'd double check to see if the -1 schematics did.  They didn't.  But... about halfway through the PDF I started seeing schematics for things that seemed to belong to the 1D, not the 1.  Including... the Timing Pulse Generator board that I spent 8 hours drawing up my own schematic for.  Sigh.

But on the positive note, I now have schematics for parts of the system I previously thought I was missing -- including the aforementioned TPG, but also the Long Vector Hardware (I can now confirm that the protoboard in my machine is a hand-built implementation of that) and the Disk Controller hardware (which I can now confirm my machine once had installed).  That's nice to have.  So, something good came out of this setback.

While I'm brooding over this issue, I'll be spending some time with the PDP-8/L, and I'll post about it once I've made some progress.  I'm currently waiting for new capacitors for the power supply to arrive.

Until next time, keep fighting the good fight!