Monday, September 30, 2013

A Brief Imlac Update

Well, it's been awhile.  Too long, really.  Unfortunately that's because I don't have too much to report.  Over the past month I've spent some time fighting with current loop adapters for the 8/L (long story short:  I can get the 8/L to send data to the PC, but not the other way around) and other than that I haven't had a lot of time to spend on projects.

I've put the 8/L aside for awhile and I'm refocusing on the Imlac again.  When we last left the Imlac, it was not running properly, due to a problem with the clock and / or the "Run Control" logic.

Tom Uban kindly provided a reference for the RUN CLOCK signal from his working Imlac, and while it looks a little bit different than mine, I think effectively the two are identical.  I also had the good fortune to be able to borrow a Waveform Generator for a few days, and feeding a similar square wave into the Imlac resulted in no change in behavior.

Based on that, I'm ruling out the RUN CLOCK signal as the culprit here and I'm returning my attentions to the Run Control board.  (This is board 231 for those following along at home.)  Here's the relevant part of the schematic:

The Run Control schematic (partial)
A brief recap:  The 74121 at E2 notes console switch input (for Read/Store, etc) via input from E2 and triggers a 5uS one-shot pulse.  The 7404 and 7400 at C1 and B1 respectively (and the R/C network between the two) cause a short pulse at the end of that one-shot (at Pin 3 of B1) which is fed to the RUN SYNC 7476 flip-flop at E1 (via pin 7).  The input to Pin 7 and the RUN CLOCK signal (pin 6) are meant to overlap at some point, which flips the state of pin 11 of the 7476, in turn changing the state of the RUN flip-flop (also in E1), which sets the RUN line high.  This in turn causes the CPU to go off and do stuff, either for one cycle or for many, depending on which toggle switch was toggled (Store/Read/Continue vs. Start).

The issue at this point appears to be that the short pulse at Pin 3 of B1 and the RUN CLOCK pulse are not always overlapping, apparently because the B1 pulse is too short.  Here's a picture of the relevant signals at the end of the 5uS one-shot, captured via my fancy-pants "new" HP 16700A logic analyzer:



As you can see, the pulse (B1-3, appx. 60ns) is too short  to reliably overlap with the RUNCLK signal (appx. 44ns duty cycle, 180ns period); it's a matter of chance whether it will or not on any given front panel operation.

The duration of the pulse is controlled by the capacitor CP16 and the resistor R14.  I've replaced CP16 to no effect, and R14 measures fine (150  ohms), so it doesn't look like there's anything obviously wrong with either of them.  This is where my complete lack of experience with analog circuits becomes a problem:  I don't know what kind of duration the R/C network should actually be producing.  If the 60ns pulse is correct then I'm at a loss as to what's going on here, to be honest.  One interesting thing is that the B1-3 output goes high again about 20ns before the B1-1 input goes low; this may just be a discrepancy between what the 16700A and the 7400 in the Imlac consider to be a TTL level signal, or it could be that the 7400 in the Imlac is a bit out of spec.  Even adding those 20ns to the B1-3 pulse doesn't make things much better, however.

Time to do some readin'.

Until next time...

No comments:

Post a Comment