Saturday, October 5, 2013

The Imlac's First Drawing

The Imlac says "Hello"
Ehhh, ok, so that's perhaps a bit... unimpressive.  You might be asking what the heck it is, in fact -- and for good reason!  (You are demanding, but also very astute.)

To understand the above, we have to go back.  Way back.  Back into time.  To, oh, three hours ago.  I thought it might be fun to see if the Imlac's Display Processor is working at all, and what better way to do so than by toggling in the "Simple Display Program" from the PDS-1 "Technical Manual?"  (There are probably a number of better ways, actually.)  So I put on some MST3K (Episode 904, "Werewolf."  Joe Estevez is not really in this movie) and got to work.

This program exercises the Display Processor by writing "HELLO" in block letters in the lower corner of the display.  (You can find the program listing on page 70 of the Technical Manual here, if you so desire.)

Upon running the program it was pretty clear that no, the Display Processor wasn't really working properly.  The DOF / DON (Display Off/On) instructions were working, as was the SSF (Skip on 40Hz Sync) but once a DON instruction was executed, the Display Processor was off in the weeds, executing code in the middle of nowhere.  (At least it was executing it sequentially...)

It was clear that the DLA instruction (which copies the Accumulator into the Display's Program Counter) wasn't having any effect.  As this instruction is how the Main Processor tells the Display Processor where to start executing, that would likely explain why it was currently executing random code.

The Display Processor's Program Counter (DPC) is loaded when the "-LOAD DPC" signal is cleared (see the logic on the Display PC boards, 203 and 204).  Investigation revealed that this was always being held high, which would prevent DPC from being set.

The "-LOAD DPC" signal is generated by the "Display Control Card" (201) and in the case of an DLA instruction it's based on the "C(AC)=>C(DPC)" signal that comes from the "IOT Control" board (318).  This latter signal was always low, so the problem in this case is likely on the "IOT Control" board.

Much like the instruction decoder I fiddled with last time, the IOT decoder uses a series of 7442 BCD decoders to generate control signals based on instruction words.  The "C(AC)=>C(DPC)" signal is meant to be generated by the "Digit 0" output from the 7442, but the output from this (on Pin 1) was always low.

IOT Decoding Logic (Partial)


The schematic above shows the related circuitry.  The 7442 at B4 (upper right) decodes instruction bits 10-12 directly (pins 13-15) and pin 12 is based on the "Digit 0" output from the 7442 at D2 (which decodes instruction bits 7-9).  So in order for "C(AC)=>C(DPC)" to be signaled, bits 7-12 must be zero.  And the Machine code for "DLA" is "001003" so that makes perfect sense. 

(A (possibly) interesting aside: The least-significant three bits (13-15) of the instruction are decoded separately (not visible on the above schematic).  Although the programming manual states that for the DLA instruction both bit 14 and 15 should be set (the "3" in the last digit of the instruction) the hardware actually only needs bit 14 to be set for "C(AC)=>C(DPC)" to be signaled and for DPC to be modified.  In fact, if bit 15 is set, this raises the "0=>C(DPC)" signal, clearing DPC.  Apparently when both of these are signaled at the same time, "C(AC)=>C(DPC)" takes precedence.  I have verified this behavior on the actual hardware.  The "Clear DPC" instruction is not documented anywhere (likely because it would be nearly useless) and this signal is not used anywhere else.  So, for future reference, DLA should really be "001002" and "001001" is an undocumented instruction for clearing DPC.  I'll have to add that to the Emulator, just in case...)

Where were we... So bits 7-12 have to be zero and what I was seeing on the logic analyzer was that the inputs to B4 were (mostly) all ones.  Bit 10 was sometimes changing to zero for a little while for no apparent reason.  Looking at the schematic, these inputs are fed through a set of inverters (the 7404 at E4 -- see the lower left corner of the schematic) and since I know that the Memory Buffer inputs are correct (I fixed them months ago) it's a pretty safe bet that the 7404's to blame.  (This seems to be a theme.)  Here's the logic analyzer output watching the MB inputs to the 7404 (pins 5, 3, and 1) and the final outputs (pins 8, 10, and 12) from the 7404:

Bad 7404.
As you can see, the outputs are all high, while the inputs are all low.  Except where bit 10's output randomly decides to become 0.  Yep, this is another bad 7404.

Replaced the 7404 and now DLA works like a charm.  And now running the "Simple Display Program" causes the Display Processor to run in a much more sane fashion.  I figured what the heck and I wired up my oscilloscope to the X/Y outputs and the picture at the top of this post was the result.  So... we've got a ways to go yet, but at least I'm getting somewhere, right?

Well, that's all for this evening.  Until next time, always keep a bag of kitty litter in your car.

No comments:

Post a Comment