Communication Breakdown (Part 3)

Sorry for the delay, I've been busy and I've been waiting for replacement parts to arrive.  I'll spare you most of the gory details and keep today's post short, since a lot of this is the same old schtick (just a lot of faulty chips that were fortunately easy to trace down) -- but to give you a general idea of what I did over the past week or so, here's a list of the chips I replaced:

5 74H61s
2 74H52s
1 7408

At this point both RS232 interfaces (primary TTY and secondary TKA) are working properly at 300 and 9600 baud respectively, and the Keyboard input (and the Keyboard itself) are also working correctly.  There are no stuck bits left in the Accumulator & Input Mixer boards so I'm going to declare victory here -- the Imlac is now able to speak to the world, and the world can talk back to it.

Next on my list of tasks is to deal with the memory problems.  As you may recall, there are two known issues with the core memory:

1.  A few randomly dead bits (stuck off) across the address space.
2. The address space wraps around at 2K, indicating faulty addressing logic.

Issue #2 can be fixed, it's just a matter of tracing down the addressing logic on the core memory control board.  Issue #1 is more problematic, as the randomess of the dead bits makes it pretty clear that it's an issue with the core memory itself, probably defective cores.  While these issues aren't impossible to fix, they are extremely difficult given the very small scale at which work needs to be done.  Let's just say I'm not optimistic.

My plan is to swap core planes with the other 8KW boardset to see if it works any better.  If the cores from that set test out OK, I will likely live with 8KW for the time being -- it's enough to run most Imlac software -- and I'll fix the addressing logic. If the other plane has errors as well, then there's not much point in fixing the addressing and I'll look into building a replacement using more modern static RAM chips.

Until next time, let a smile be your umbrella!

Update:
I swapped in the other core plane and it too has stuck bits.  Many fewer than the current core plane, but even one is enough to make it unusable.  I managed to partially solve the addressing issue -- I can access memory above 2K properly from the front panel but indirect accesses under program control read the wrong address; this looks like a CPU problem.  To add to the mystery, I can address the full 8K with the original core plane, but only 4K works with the other swapped in --  this may explain why the bootstrap loader was rejiggered for a 12K machine...

So, in summary:  Looks like I'll be building some manner of replacement for the core memory.

Interesting Imlac Info

I stumbled on this set of scans over at DigiBarn (a most excellent computer museum), a reprint (in the late '70s) of Imlac's brochures for their systems and configuration options.  I thought I'd reproduce some of the text here, since it's pretty interesting (to me, anyway) and since a lot of this is completely new to me -- I've not seen it referenced anywhere.

OVERVIEW
Imlac Corporation (founded in 1968) is a manufacturer of interactive intelligent graphic display systems.  It has marketed the PDS-1 Graphic Display Computer since 1970 and the PDS-4 system since 1974.  The PDS systems are programmable stand-alone or terminal graphics processors.  Internally, the systems consist of two independent processors which use system memory in common:

• The main processor (a minicomputer manufactured by Imlac), which performs file I/O, field calculation, and other support functions. 

• The display processor, which may be programmed in its own Assembly language to generate the screen displays.

The basic PDS-1, which sells for $8,300, consists of a 15-inch display screen, an operator keyboard, 4K words of memory, the display and main processors, and an interface for telecommunications.  A basic PDS-4, which sells for $17,300, consists of similar components, with a 17-inch screen, faster main memory, and a more powerful display processor.  A full complement of software is supplied with all systems, including a FORTRAN compiler (disk system only), Assembler, linking programs, and debugging aids.  Also available is a floppy disk system comprising a controller, interface, and up to four IBM 3740 compatible disk drives.

 For systems sold with cartridge disks, Imlac provides a full disk operating system with file access facilities and support of the programming languages.  For systems which use the telecommunication interface, a set of interactive operating software is available, including graphical terminal control programs on the PDS systems and a set of FORTRAN callable support subroutines for the host computer.

To date, some 600 PDS systems have been delivered.  Table 1 presents the specifications of the systems.

[No, that's not a typo -- by 1977, Imlac Corporation had sold only six hundred PDS systems, total.  Given Imlac's last gasp was in 1979, I can't imagine that many more than 1,000 Imlac systems were ever made. It makes me wonder how they managed to stay in business that long, the margins couldn't have been that high.]
 

Table 1

 COMPATIBILITY

All peripherals of PDS Systems are compatible with all PDS mainframes, allowing upgrade from a PDS-1 to a PDS-4.  PDS-1 software is also upward compatible with that of the PDS-4.  However, the PDS-4 supports additional display generation commands and its software is not, in general, compatible with PDS-1 software.

For PDS systems which use telecommunications, Imlac provides software to communicate with most timesharing systems.  Under local program control, the user may specify transmission speed, character parity, and character echoing.  Emulators are also available for Tektronix 4010 and 4014 Graphic Terminals.

As part of its standard peripheral options, Imlac has developed a number of direct connection interfaces to most popular minicomputers and some mainframe computers.

PERFORMANCE AND COMPETITIVE POSITION
Imlac was one of the first companies to produce and market stand-alone intelligent graphic systems.  The only product line of the company is and always has been graphic-based systems.

The principal difference between the PDS-1 and PDS-4 systems is one of throughput, or graphing rate, and graph sophistication.  The PDS-4 uses main memory with a cycle time under 1 microsecond, where the PDS-1 uses 1.8-microsecond memory.  A larger display screen is provided as a standard element of the PDS-4 than for the PDS-1, and the display processor of the larger system allows for twice the number addressable points in both the X and Y directions.  The PDS-1 has one display intensity value, and the PDS-4 has sixteen (optional on the PDS-1), which may be associated with any figure on the screen under program control.  Hardware blink and virtual paging are optional on the PDS-1 and standard on the PDS-4

A number of display options are available for the PDS-4 only: a special instruction set provides for display processor scaling, rotation, translation and windowing; an automatic increment feature allows rapid display of very compact data lists.  Both units offer an arc generation hardware option and may support multiple independent display monitors.

Over the years, a number of competitors have entered the programmable graphic system market, but Imlac has maintained its position of offering programmable graphics systems at a low cost.  To date the minicomputer based competitor with the closest price to the Imlac equipment is the Tektronix 4081 Interactive Graphic Computing System, priced at $27,000.  Recently, microprocessor-based programmable graphic systems have also been announced, principally the Tektronix 4051 Graphic Computer System (priced under $8,000), but these devices do not have the display power or peripheral capability of the Imlac systems.

Generally, higher priced programmable graphic systems offer faster processors, faster display rates, larger display areas, or specialized functions such as windowing, reflections, circle and ellipse generators, or three dimensional software.  To a certain extent, the relatively low price of the Imlac equipment may be attributed to the use of its own minicomputer.

USER REACTION
Users were interviewed from the engineering, electronics, and medical fields.  They were unanimous in stating that the PDS systems had met their objectives, and had proven to be a cost-effective solution to the wide range of applications.  Typical user configurations were basically of two sorts:

• A small PDS system configured (often by direct connection to a general-purpose minicomputer) as a smart graphic terminal.
• A stand-alone disk-based configuration, usually with some telecommunication connection to a remote host computer.

Most users programmed PDS systems in Assembly language or by using host facilities provided by Imlac.  FORTRAN is usually preferred by users with disk systems; one user has developed a cross assembler for his host minicomputer.  Another user found that the program editing software provded by Imlac was very good, and he uses it as a word processing system for manual documentation.

Equipment reliability was rated good to excellent by the users.  A large number of them performed their own hardware maintenance; the rest used standard Imlac service contracts.

Engineering
One user, an engineering consultant, has a PDS-4 system with a disk and line printer.  He uses the system to develop a series of power plant control displays for the electric utility market.  The Imlac system was chosen over faster screen displays because of the amount of alphanumeric data which could be displayed on the screen, and it was selected over other graphics systems, such as Vector General, IDI, and Evans and Sutherland, on the basis of cost effectiveness.

The power plant displays make heavy use of both alphanumeric and schematic diagram data as control information for the plant operator.  The development work done on the first PDS system was sufficiently successful; additional units were built to the firm's own specifications.  Recommendations have been made to place the PDS in a number of power plant control rooms around the world.

Research
A large western university has a number of PDS systems installed in various departments; the bulk of the work is done in the field of medicine.  The systems, both PDS-1 and PDS-4, are connected to a large central IBM computer, and typically use emulation software for IBM graphic devices such as the 2250.  Here, the Imlac equipment was chosen for its cost effectiveness.

A gamut of both experimental and operational application is running on PDS systems: graphical data reduction of EEG recordings for brain function analysis, pulmonary physiology studies for emphysema research; a very large package of statistical programs used in such departments as mental retardation studies, radiation treatment planning, and an "excellent version of Star Trek."  These units are mainly small configurations with few peripherals.  The host computer is relied upon for application processing with only graph manipulation occurring at the PDS system.

Simulation Applications
A number of other users were employing PDS systems as graphic control terminals in simulation applications.  Two users had flight training systems operational where the PDS system was directly connected to a general-purpose minicomputer.  In both systems, the PDS was used as the instructor's display and was used to continuously update training history and simulated radar information.

Another PDS-4 is directly connected to a Data General NOVA minicomputer.  It is used by the U.S. Navy to verify operational communications links and protocols.  The screen is used in a fashion similar to the standard tactical display screens for exercising, emulating, and verifying communication traffic.

[I need to find a copy of that "excellent version of Star Trek."  So much software lost to the ages.]

CONFIGURATION GUIDE
The standard PDS system consists of a display screen with display processor that shares memory with the minicomputer, a main processor (16-bit minicomputer), a keyboard, and an RS-232 interface.

The basic PDS-1G includes the graphic display processor, a 15-inch display screen (17- or 21-inch screens are optional), a minicomputer with 4,096 words of memory, an alphanumeric keyboard with programmable function keys, ROM bootstrap for program loading and an RS-232 interface for modems or asynchronous devices (75-600,000 baud).  The PDS-1G-8 includes all of the above plus an additional 4,096 words of memory.

The basic PDS-4 includes a graphic display processor, a 17-inch display screen (15- or 21-inch screens are optional), a minicomputer with 4,096 words of memory, an alphanumeric keyboard with programmable function keys, a ROM bootstrap for program loading and an RS-232 interface for modems of [sic] asynchronous devices (75-600,000 baud).  The PDS-4-8 includes all of the above plus an additional 4,096 words of memory.

The basic system may have the following added to them:  memory up to a total of 32K words, three independent display monitors and keyboards, a number of specialized display options, and a variety of peripheral devices (a cartridge disc, a floppy disk unit (PDS-4), paper tape equipment, magnetic or cassette tape drive, a hard copy unit, printers or printer/plotters and a graphical digitizing tablet).

[600,000 baud?  It does look like it's technically possible to wire the RS-232 ports for just about any baud rate but somehow I'm skeptical...]

Mainframe
The central, or main, processor is a 16-bit minicomputer with a .99-microsecond (PDS-4) or 1.8-microsecond (PDS-1) cycle time.  It includes 4,096 words as standard, and a maximum of 32K words (PDS-1G) or 64K words (PDS-4).  The processor has one interrupt level; another interrupt level is added if a direct memory access (DMA) option is used.

The display processor operates on a cycle-stealing basis using the system main memory; its speed is governed by main memory speed on each model.  Operationally, the main processor loads or constructs a display program for the display processor and instructs it to execute the display program.  The display processor draws the graphic display, based on the contents of its current display program.  The display generation occurs simultaneously with operations by the main processor.

Optional features may be selected for memory protection, floating point arithmetic, a real-time clock, a DMA channel (with additional interrupt), display arc generation hardware, scaling, rotation and windowing hardware (PDS-4 only), parallel or serial I/O channels, a programmer console, and special direct interfaces to a number of other computers.

PERIPHERALS
A variety of peripherals are available for the PDS graphic systems; Table 1 lists auxiliary storage limitations.

Cartridge Disk.  The disk file system consists of a single disk drive of two platters, one fixed and one removable, with a total subsystem storage capacity of 10 megabytes.  Data transfer is at the rate of 180K bytes per second, with a random access time of 35 milliseconds.  Disk transfers occur through the system DMA channel.  Systems with disks are provided with the Imlac Disk Operating System.

Magnetic Tape.  Units are available to support both 1200- and 2400-foot reels, using 9-track tape recording at 800bpi.  Transport speed is 12.5 or 37.5 ips.

Floppy Disk.  Dual floppy disk drives may be attached to the PDS-4.  The units operate across the DMA channel.  This floppy disk system comprises a controller, interface, and up to four IBM 3740-compatible disk drives.  Minimum system requirements for use with the system is 16K bytes of core memory.

Cassette.  A read/write cassette drive is available at recording at 120 cps.

Paper Tape Equipment.  A photoelectric paper tape reader, operating at 300 cps, and a paper tape punch, operating at 75 cps, are available.

Graphic Hardcopy Device.  This optional unit creates a permanent exact copy of the display screen on an 8-inch-square sheet.  It may be connected directly to the system display or driven as an independent display.

Digitizers.  A data tablet with a 14- or 72-inch square surface is available, as well as a graphic mouse for the digitizing of input.  Both a joystick and a lightpen are available.

Printers.  Printers (132 column) operating at 30cps or 70 lpm are available.  A 500 lpm printer plotter is also offered.

[I'd love to know what technology the "Graphic Hardcopy Device" used to make a copy of the display screen -- perhaps something similar to what Tektronix 40xx series terminals used?]

The last three pages contain a huge table covering all of the various options and their prices, which I won't attempt to recreate here.  16KW of memory cost an additional $6,500.  The Floating Point Arithmetic module was $9,500 -- I'd love to know what that consisted of given that it was more expensive than a base PDS-1G at the time.

Communication Breakdown (Part 2)

After resolving the issues with the TKA serial port (well, at least in theory until the replacement chips arrive) I turned my attentions to the TTY serial port.  Neither transmit nor receive functions were working at all; specifically:

• Transmitting of data via TPR and related opcodes fails.  No data is sent, and the "TTY Output Status" flag (used by the TSF/TSN opcodes) never gets set.
• Receiving data via RSF and related opcodes fails (what gets read is always zero).  The "TTY Input Status" flag (used by the RSF/RSN opcodes) is always set.

I started my investigations with the Transmit side of things.  I had a hunch that something might be wrong with the clock signal based on the behavior of the Output Status flag; since it was never getting set after a Transmit operation, the Transmit board's state machine was clearly not running properly.  This state machine is clocked by a 5Mhz signal generated from a crystal oscillator on the Receive board, and then divided down by a 16-bit counter on the Transmit board.

The full Transmit Board Schematics

Looking at the above schematic, you can see that there are four 74161 4-bit counters at the lower left:  This is the aforementioned 16-bit counter.  The 74161 at A3 has both its Clock and Enable inputs (pin 2 and 10) connected directly to the 5Mhz clock (pin 67 of the card edge), so it gets clocked at 5Mhz.  The other three are clocked by the "Carry Out" signals of the preceding counter in the chain:  A3, B3, and C3 have their "Carry Out" signals (pin 15) tied to the Enable inputs of the next counter in the chain.  D3's Carry output is connected to the "Shift Clock" logic (see the upper-middle of the schematic) and this logic controls the three 7495 4-bit Shift Registers at C1, C2 and D2 that contain the byte being sent plus up to two stop bits.  Each time the Shift Clock signal clocks, the next bit is shifted through pin 10 of D2 and sent over the wire.

Thus, the 16-bit counter formed by the 4 74161s is used to divide down the 5Mhz clock into a clock rate suitable for RS-232 communications.  The divisor is user-configurable (via soldering iron).  The inputs to the 74161 (TT0-TT15, see the lower left of the schematic) are brought in from another board, pictured below:

The "Comm Speed Select Board"

The orange wires on the right each control a single bit of the input to the 16-bit counter, either "High" (1) or "Low" (0) as designated by the etching at the top of the board.  The above board's wired value is 57203.  Each time the 16-bit counter overflows (reaches 2^16, or 65536), it will be reloaded with 57203.  This means that for every clock from the 5Mhz input, 65536-57203 (or 8333) clocks must take place before the 16-bit counter overflows and clocks the Shift Clock logic.  5,000,000 divided by 8333 comes out to 600.02, which is two times the expected 300 bits per second rate.  I believe this is because each output bit is actually transmitted for two divided clock cycles before a shift takes place but I have not confirmed this.

Back to the investigation:  The 5Mhz clock signal looked fine, so I traced the signal down the chain. The carry outputs from A3, B3, and C3 looked fine, but D3 never changed.  Well, that would explain quite a lot, if the divided clock never runs then nothing at all will ever happen.

I replaced the 74161 at D3 with a spare and the Imlac was now able to transmit again!  On to the Receive logic.

The programming-level issue with the Receive logic was kind of the inverse of the Transmitter's problem:  The "Data Ready" flag was always set, even when nothing had actually been received.  Reading from the Receiver always came back as all zeroes.

The full Receive Board Schematics

On a hunch I decided to start looking at the problem by examining the data getting clocked into the 74161 shift register at C4 (see the lower-left of the above schematic).  It was all "1"s, all the time -- so the Receive logic thought it was constantly receiving a stream of "0" bytes over the wire.  The shift register input comes out of the 7408 AND gate at B2, which combines the current loop and EIA (RS-232) inputs.  The inputs to the 7408 were fine, but the output was always high.  I replaced the 7408 at B2 and the Receiver started working again.  (Ok, not quite -- the same bits are stuck off as with the TKA Receiver until the new 74H52s arrive and are they ever taking their sweet time to get here...)

So, the Primary (TTY) serial port is working again!  That wasn't too painful at all.  Next time I'll look at the Keyboard input, but until then: Earn good money selling Grit!

Communication Breakdown (Part 1)

Now that I have the Imlac's CPU and memory running well enough to attempt running basic diagnostics, my plan of attack for the rest of the work is roughly as follows:

1. Investigate the functionality of the Imlac's I/O devices, and get them working again where necessary.
2. Use the I/O devices to upload more advanced diagnostics from a PC.
3. Repair remaining CPU issues
4. Repair remaining Memory issues
5. Get the Display Processor working properly
6. ...
7. Profit!

I've spent a few evenings over the last week or so working on step #1 in my nefarious plan.  My Imlac has four I/O devices fitted: Two asynchronous serial ports (RS-232 or Current Loop), one synchronous serial port, and the Imlac Keyboard input.

In order to move onto step #2, it will be necessary to have at least one of the two async serial ports working, though unless I find a good reason I'd like to take the time to make sure that both of them are working.  The synchronous serial port is interesting but I don't have anything else that can talk to it (and I have no documentation for it either) so it's going to go untouched for the time being.

Testing the keyboard input isn't strictly necessary at this point but since I'm looking at the I/O devices I might as well cover it.

To test out the basic functionality, I coded up a couple of quick test programs to exercise the serial ports' "transmit" functionality.  For the "primary" (TTY) port this is:

0  TCF      ; 001042
1  LDA      ; 100041
2  TPR      ; 001041
3  TSF      ; 002100
4  JMP 3    ; 010003
5  JMP 0    ; 010000

and for the "secondary" (TKA) port this is:

0  IOT 242    ; 001242

1  LDA        ; 100041
2  IOT 241    ; 001241
3  IOT 224    ; 001224
4  JMP 3      ; 010003
5  JMP 1      ; 010000

The above programs continually read the contents of the console Data Switches into the Accumulator and transmit them over the serial port.  The TTY port was completely unresponsive, and the program would sit in the loop at 3/4 forever waiting for the transmit to complete.  However, the TKA port happily transmitted data -- and at 9600 baud.  I was expecting 300, so this was a nice surprise.

Since the TKA port could transmit, I decided to see if the receiving end was working as well and I coded up the below:

0  IOT 242    ; 001242    ; clear xmit
1  IOT 232    ; 001232    ; clear rcv
2  LAW 0      ; 040000    ; clear AC
3  IOT 204    ; 001204    ; skip on rcv
4  JMP 3      ; 010003
5  IOT 231    ; 001231    ; read
6  IOT 241    ; 001241    ; xmit
7  IOT 224    ; 001224    ; wait for xmit
10 JMP 7      ; 010007
11 JMP 0      ; 010000    ; again! again!

This waits for a byte to be received, and when it is, it retransmits it back, effectively "echoing" it back to the source (a laptop PC in this case).

This did not work so well.  Numerous bits were apparently stuck off (sending a lowercase 'a' (0x61) would echo back an '@' (0x40) to the PC).  Strangely, and for reasons I still do not understand, running the PC at 300 baud worked fine in both directions.  This threw me off for quite awhile and I do not yet have a rational explanation for how this could possibly work, as the TKA port is clearly wired at 9600 baud (and I've verified this baud rate via investigation with my oscilloscope).

I thus spent quite a bit of time looking over the Async Receive Board (board 327 in the schematics).  Weirdly, everything looked fine -- the data coming in looked fine, the clocks were clocking, the shifters were shifting, the buffers were, you know, buffering...  At the last stage of the output from the board there is a set of 7403 open-collector output NAND gates and at this point the data turned into garbage.  Replacing the 7403s made no difference.

The outputs from the 7403s are wired into a simple "bus" of sorts, used as one of several inputs to the Accumulator register.  The other end of this bus is on the "Accumulator & Input Mixer" boards, occupying slots 219-222 (4 bits each).  These boards have a set of pull-up resistors to complement the open-collector outputs on the I/O boards themselves.  Other I/O devices use this bus to allow reading a single word of data into the Accumulator, and only one I/O device is supposed to put data on this bus at a time.

So the thought occurs:  Well, maybe another device has gone crazy and is using the bus when it shouldn't be?

The answer to that turned out to be "no."  I removed other applicable I/O devices (which were the TTY serial port and the synchronous serial port) and the behavior remained.

I was stuck here for awhile, and I was completely distracted by the anomolous "works fine at 300 baud" behavior.  I spent a lot of time looking at signals on the logic analyzer.

It occurred to me that I could try swapping the "Accumulator & Input Mixer" boards around to see if the stuck bits moved around.  This seemed unlikely to make a difference, since I was sure the problem was with the bus; but sure enough, swapping boards 219 and 220 for 221 and 222 caused the behavior to change -- now only one bit was stuck (bit 6).  So the problem wasn't with the bus after all, though I'll have to add the odd readings I was getting on the logic analyzer to my list of unsolved mysteries...

At this point, it was clear the problem was on the Input Mixer side of things, and there weren't too many places the problem could be.

The Accumulator's ALU inputs

As a representational sample, the I/O bus input for bit 11 comes in on pin 64 of board 221 (shown above, bottom left.)  This is tied to the input on the 7400 NAND gate, which passes through a 74H61 before being combined at the 74H52 and sent to the ALU.

Investigating with the Logic Analyzer (which is quickly becoming my favorite device in the universe) showed that the 7400 was fine, but the outputs from the 74H61 at E4 were incorrect.  Similar discoveries were made on the other 3 Input Mixer boards, and at the end of the day, three of the eight 74H61s across all four boards had one or more outputs stuck low.

Of course, I have no replacements for these on hand (nor do any local electronics stores), so I've placed an order for some new ones and they should arrive in a few days.  Once they get here, the TKA serial interface should be working correctly again.

With that problem solved, I could now turn my attentions back to the unresponsive TTY serial interface, but that is another story, and shall be told at another time...

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.

More Imlac Progress

After looking at the Power Supply Regulator schematic I decided to live with my hack to the P/S READY signal for awhile and spend some more time debugging the CPU.  I'll return to the power supply later (much, much later) but for now it runs well enough without it to do some other investigations.

Let's see... where did I leave off two months ago before I was sidetracked by the supply issue?  Oh yeah:

Any instruction that references a memory location (either a read or write) will end up causing its contents to be incremented by one. 

So, I put on some MST3K ("Diabolik," -- deet deet dah!) and got to work.

There's only so many things that can reasonably cause this behavior.  The Memory Buffer control board (for bits 8-15) has a single input explicitly to enable this behavior.  This is used for ISZ instructions and indirect increment register (memory locations 10-17) accesses.  Thus it seems reasonable to assume that this signal is being raised inappropriately, likely for every instruction but only impacting those that actually touch memory during their operation.

I whipped up a quick program to test the behavior, meant to be single-stepped through while watching on the logic analyzer:

0 CAL    ; 100011
1 ADD 3  ; 064003
2 JMP 1  ; 010002
3 000001 ; constant to add to AC

Verifying with the logic analyzer showed that the increment input to the Memory Buffer was indeed high.  On the Memory Buffer schematic (Board 213) this is the "C(MB)+1 => C(MB)" signal and it's generated by board 207 (The "CP, MB, & MA Cntl" board).

I checked the logic on Board 207 and it was clear that one of the inputs, the "ISZ & EXEC" signal was being raised when it clearly shouldn't have been (the CPU was not executing an ISZ instruction). This signal is generated by Board 226 (the "Instruction Register & Decoder" board).  The related portion of the schematic is below:

The portion of the Instruction Decoder responsible for the ISZ instruction

The Imlac uses a pair of 7442 BCD to Decimal decoder chips in a clever way to decode instruction words; an ISZ instruction causes D6 on the 7442 to go low.  Testing revealed that the 7442 was fine, but the input to the 7420 at A1 (pins 12 and 13) looked very very odd:

Odd ISZ signal behavor, GRAPHICALLY PORTRAYED!!!!

As you can see, once EXEC (measured at pin 9 at A1) goes low, the ISZ signal (as measured at pin 12 at A1) does a fun little jitter before it finally decides for some reason to go high.  This shouldn't happen since the ISZ signal from the 7442 isn't changing.  Based on this, it's a fair guess to suspect that the 7404 at D3 between the 7442 at C3 and the 7420 at A1 has basically gone insane.

After replacing the 7404, the test program executed as expected.  Huzzah!

At this point, the CPU seems to be working pretty well, though I will have to spend some time going through all the instructions to look for anomalies.

Since things were looking up, I decided to do a basic test of the memory.  I assembled a quick program (very similar in behavior to the one I used on the 8/L):

00    060031  ; LAC Value   ; Load test value
01    120030  ; DAC I Addr  ; Store it
02    160030  ; LAC I Addr  ; Read it back
03    070031  ; SUB Value   ; Compare with test value
04    002001  ; ASZ OK
05    000000  ; HLT         ; Memory does not match, halt
06    030031  ; ISZ Value   ; Test next value
07    010000  ; JMP Start
10    030030  ; ISZ Addr    ; Value overflowed, test next Address
11    010000  ; JMP Start
12    004100  ; LAW 100     ; Start over at 100
13    020030  ; DAC Addr
14    010000  ; JMP Start

30    000100  ; Addr
31    000000  ; Value

As an aside, you might notice how much shorter this is than the 8/L test program even though the two operate in exactly the same way -- 21 words for the 8/L vs. 14 for the Imlac.  The Imlac's instruction set is a bit more rich than the 8/L's due to the wider instruction word, allowing for more compact code.  You may also notice a problem with this program -- it tests the entire 16-bit address space (64K) which of course I don't have (and no Imlac ever had), so it'll halt once it runs off the end of installed memory (8K in my case).  I was going to correct this, but it became clear pretty early on that a fix could wait.

Running the above program has revealed that there are a few problems with the core memory.  Most addresses test out fine but there are a few here and there that fail sporadically.  Some fail under test but seem to behave fine from the front panel, some seem to have a few bits stuck off at all times.  In general, these bad addresses are not contiguous and are spread all over the address space without any apparent pattern.

This could point to improper alignment (which would not surprise me in the least given the original state of the memory boards) or there could be actual physical defects.  I pray it is not the latter, as these sorts of defects are basically impossible to repair.

I will have to do a deeper analysis of the failures to see if patterns emerge (indicating failures with address decoding or X/Y drivers).  I also need to read through the documentation to see what alignment and diagnostic procedures it recommends.

I think that's probably enough for this evening.  Until next time...

Another Imlac Update: In Which Foreheads Are Slapped

Well... as it turns out I may in fact have been entirely mistaken about the problem this whole time.

I was puzzled by a certain behavior of the front panel, namely that toggling the Read/Store/Continue switches would actually do their associated action about 50% of the time, but "Start" never actually started the system running, even though based on my interpretation of the schematic, once the one-shot successfully meshes with the RUN CLK signal, it should just be off and running.

I was still a bit fuzzy about the behavior of the RUN / RUN SYNC flip flops so I wired up the logic analyzer to watch all the inputs and outputs, and I discovered that when the Preset input (pin 7, from the one-shot driven by the front panel) went low, Q/-Q would change state... but only as long as Preset stayed low.  Once preset went high again, Q flipped back off.  My understanding is that Q/-Q should hold the new state if Clear is high... but wait... Clear is low.

So... what drives the Clear input?  The "GATED PS RDY" line. Which is active high and is currently low.  Oh, good.  So to confirm my suspicions, I isolated the Clear input from the circuit and wired it to Pin 3 of the flip-flop (which is currently connected to +5V though a current-limiting resistor).  Fired it up... and everything works normally again.

Sigh.  So apparently if the power supply "Ready" line doesn't come high, the machine just acts bonkers.  That's good to know.

Well, now to figure out why the power supply isn't coming ready.  The supply voltages look fine, so this should be interesting.  I traced the GATED PS RDY line back to the "Misc. Control" card (board 232) and the "P/S RDY" line is always low.  This is connected to "TB3-1" which is actually on the supply itself.  Should be good, good fun.

With that, it's well past time for bed...