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...

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...

Bringing the 8/L Back to Life

The 8/L's backplane, stuffed with Flip Chips.

I spent some time last week cleaning the 8/L in preparation for the new power supply capacitors.  This was a pretty painless process -- the machine's already very clean externally and internally it was a matter of gently brushing 44 years' worth of accumulated dust off of all of the flip chips installed in the backplane.  This was done with an old toothbrush, and while I was at it I cleaned all the edge connectors with a bit of Scotchbrite.

The PDP-8/L 718 Power Supply

The replacement capacitors for the 8/L arrived on Thursday, so that evening I put on some MST3K ("Escape 2000," in which you are encouraged to Leave the Bronx!) and got to work.

The above picture shows the 8/L's power supply, designated as the 718.  It's a simple linear supply and it was a trivial matter to replace the three large electrolytics (18000uF, 22000uf, and 80000uF) with their new replacements, since they're all screw-terminal types.  All three appear to be originals, and while they look yellow in color in the photo, back in 1969 they were silver.  Some folks prefer to reform old capacitors, but having had a couple of working capacitors go dead short on me in a previous project, I prefer not to take chances.  I'll be keeping the originals just in case.

With the new capacitors in place and the power supply unit bolted back together, I powered it up and checked the voltages; the 718 provides a regulated +5V supply, and unregulated -30V and -15V supplies.  The 5V measured in at 5.05V under load, and the -30V and -15V were -35V and -18V unloaded -- well within tolerances.  The 8/L also uses a -6V supply and this confused me for a bit, as the -6V line was reading at -35V as well, which would be wildly wrong.  It turns out that the -6V line is regulated by the G826 regulator board installed in the 8/L chassis -- it's not part of the power supply itself.  Together, the -6V and -30V supplies provide the power supply for the core memory system.

Since everything looked good, I reinstalled the 718 in the 8/L chassis and powered it up (while keeping my fingers crossed):

First power-up

And hey, everything lit up and the fans sputtered to life (they'll probably need a bit of lubrication).  An initial checkout indicated that the front panel was working -- I could load addresses into the Memory Address register from the Switch Register, and use of the Exam and Dep switches would increment the Memory Address correctly.  Only four dead lights on the front panel (these are low voltage incandescent bulbs, not LEDs) and fortunately I have a few spares.

Hitting the "Run" switch caused the CPU to take off running whatever it thought it was getting from memory, and hitting "Stop" caused it to stop --so quite a bit of the CPU logic appeared to be working.

Not a lot of response from the memory, though.  Hitting "Exam" would step through the address space but I mostly got zeros back and I was completely unable to deposit anything into memory.

Well, I figured that was to be expected since the power supply had been rebuilt and the core memory system requires careful calibration in order to work correctly.  The calibration procedure is documented in the maintenance manual (starting on page 5-7, for those following along at home).  Essentially, the difference between the MEMORY SUPPLY + and MEMORY SUPPLY - lines (the -6 and -30V supplies mentioned earlier) should be about 22.5V.  Mine was only reading about -18V, so I goosed it up to (er, down to) -22.5V using the trimpot on the G826 regulator):

Everything's nominal...

This had no effect at all on the behavior of the memory, so I turned my eyes to the memory control timings (also discussed in the maintenance manual).  Things looked pretty much OK there as well, and the waveforms coming back from the core memory read amplifiers looked OK as well.

Using the logic analyzer indicated that all the requisite control signals were being generated correctly (they looked identical to figure 5-3 in the manual).

Core memory is a complicated mechanism and I won't bore you too much with the details (the maintenance manual covers it in exhausting detail if you're curious).  Effectively, a "read" operation destroys the contents of the memory being read (resets everything to a "zero" state), so every read must be followed by a write to put the original contents back.  Given that the waveform for the read amps looked good (and also indicated that everything was zeros) and in combination with the fact that "write" operations from the front panel were not working, I began to suspect that the problem with the core memory was with the "write" side of things.

Since every bit of every address seemed to be coming back as all zeros, it seemed unlikely that it was any of the circuitry related to control or amplification of the individual data bits in the MB buffer (i.e. it was unlikely that every single read/write amp and inhibit driver for the memory data was broken in the same way).  On a hunch, I swapped the pair of G228 Inhibit Driver flip chips for the X/Y Read/Write control with a pair from the Memory Buffer Inhibit Drivers.  And voila -- the memory started responding again and I was able to write to and read from it reliably (with a single bit stuck).

From here it was easy to isolate the faulty flip chip, and from here to narrow down the cause to a bad 7440 IC.

The faulty G228 Inhibit Driver.

After replacing the 7440, the memory system appeared to be working reliably, but it's difficult to track down individual dead or stuck bits just by playing with the front panel.  DEC supplied a plethora of diagnostics to run (the checkerboard test is a particularly brutal one), but at the moment I have no way to load them onto the machine other than toggling them in manually (I'm waiting for my RS232<->Current Loop adapter to arrive).  I'm far too lazy to toggle all that in, so I whipped up a very basic diagnostic myself:

00 7200  CLA
01 1023  TAD 30  ; Load start address
02 3024  DCA 24  ; Copy to curr. addr.
03 3025  DCA 25  ; Copy AC to test value
04 1025  TAD 25  ; reload into AC
05 3424  DCA I 24  ; Copy to memory loc
06 7200  CLA
07 1424  TAD I 24  ; reload memory
10 7041  CIA       ; negate (2s cmpl)
11 1025  TAD 25    ; add current value
12 7440  SZA     ; Should be zero
13 7402  HLT     ; Memory did not match
14 2025  ISZ 25  ; Move to next value
15 5021  JMP 21
16 2024  ISZ 24  ; Move to next address
17 5003  JMP 03  ; Run test with new address
20 5000  JMP 00  ; Address has wrapped to 0, start again.
21 1025  TAD 25
22 5003  JMP 03  ; Run test against current address with next value
23 0030  ; Constant - starting memory address to test
24 0000  ; Variable - Address being tested
25 0000  ; Variable - Value used to test address

This walks memory from 0030 to 7777 and for each address, it writes, reads back, and compares all possible values.  If a mismatch is found, it halts, otherwise it will loop forever.

I've now had it running the above test for a few hours without issue.  Once I get my current loop adapter, I'll be able to run some real diagnostics on it but this is still a pretty good sign -- there are no stuck or dead bits in the core and quite a bit of the CPU is working properly.

So one dead 7440 is the only fault so far.  Not bad for a 44 year-old computer.

That's all for now!  Until next time, always let your conscience be your guide!

Addendum (8/26/13): Looks like I spoke a bit too soon about the core memory being 100% operational.  Fired up the machine and ran test program again this evening and after about 30 seconds it hit some stuck bits (3 and 8) at address 0506; these stuck bits continued for a few pages, after which there were a few more good pages, followed by stuck bits, etc.

But, after letting the machine warm up for 20 minutes or so the test started passing again.  This indicates that the memory isn't aligned quite properly, so it will need some fine tuning.

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!

The Imlac's memory is alive!

This is a quick update; I'll post more details later.

After dealing with corroded pins, bad connections, and counterfeit 7400-series logic (no, really) I finally have one of the two Dataram core memory boardsets running, giving me a whopping 8KW of memory.

And now that I have some memory to play with, I can actually get it to run a program!  Since Blogger apparently refuses to let me embed the video, you can see it here.

I assembled the program manually, here it is in all its glory:

0 CAL     ; 100011
1 ISZ 37  ; 030037
2 JMP 1   ; 010001
3 IAC     ; 100004
4 JMP 1   ; 010001

Pretty fancy.  It increments the contents of memory location 37 until it overflows (becomes zero) and then increments the Accumulator and starts over again.  In this way, it slowly increments the Accumulator.

That this program executes indicates that quite a bit of the main processor is functional, which is encouraging.  Since I don't have any official diagnostics (other than a memory test routine) I'll be spending some time coding up a few diagnostics of my own, to ferret out any remaining issues in the main processor before moving onto the display processor.

That's all for now.  Until next time...

8/L Exterior Cleanup

Just a few pictures today.  Spent some time making the 8/L look all purty on the outside.  Based on suggestions from the cctalk mailing list, I used some WD-40 (liberally applied) to loosen the ancient masking tape on the front panel and switches.  The end result is this:

The 8/L, ready for a night on the town.

That worked wonders, and afterwards it cleaned up quite nicely.  The front panel is in immaculate condition.  The switches still need to be (carefully) taken out and more thoroughly cleaned, but I'll save that for another day.

The 8/L's primary interface to the world: an ASR-33 Teletype.

The teletype is in pretty good shape -- it's missing a few screws and it's very dirty but it's mechanically sound.  After giving the insides a visual inspection and making sure that nothing was preventing the motor from spinning, I powered it up briefly and it appears to work correctly.  It'll need a good cleaning and lubrication before I put it into regular use.

The ASR-33's keyboard.  Some serious oxidation on the key plastic, but that should clean up.

That's all I have for today.  Until next time -- don't forget to wind your watch!

New plaything: A PDP-8/L

I'll follow up later with more details, but I just wanted to share a bit about my latest acquisition, a PDP-8/L:

My 8/L, rebranded for use in an early CNC application

The PDP-8/L was introduced in 1968 by DEC, as a smaller, cheaper, (and less expandable) version of the PDP-8/I.  As you can see, my 8/L has been rebranded by Houdaille Electronics, an early provider of CNC (Computer Numerical Control) machines.  (Normally, 8/L's look more like this.)  I don't know precisely what application this would have been used in, and I don't have a ton of information on Houdaille.  I've been told that they did quite well up until the late 70s building machine tools for automakers and auto parts subcontractors.

The 8/L was fairly popular in the late 60s and early 70s, selling 4000 units or so before it was superseded by the 8/E.  It shipped with 4K of core memory, which was expandable to 8K via a 4K unit in an enclosure the size of the computer itself (the BA08).  While it was possible to expand beyond 8K, it was rarely done and the hardware to do so (the BM8L expansion -- see here for some pictures) is hard to find. 

There were not many peripheral options available for the 8/L; anything beyond a Teletype interface and high-speed paper-tape reader/punch required the BA08 expansion to house the hardware for the peripheral interfaces.

My 8/L is a very basic configuration -- 4K of core and the Teletype interface.  That's it, but that's all you need, really! A Teletype generally came with a paper tape reader/punch, and while slow (110 baud), it was functional and reliable, and allowed for storage, editing, and retrieval of programs and data.

Along with the 8/L, I got a dirty but complete ASR-33 Teletype (pictures to follow at some point), and an incredibly heavy and ugly half-height rack.  I was hoping there'd be something else aside from the CPU unit, but the rest of it is just empty space.  Well, if I ever find a BA08, I'll have some place to put it.

The cards comprising the 8/L CPU and peripheral interfaces

The 8/L's logic is made up of a hundred or so individual circuit boards, called "Flip Chips" in DEC vernacular.  Each of these flip chips is plugged into a wire-wrapped backplane (which is mounted upside-down to make servicing fun.)

The 8/L's wire-wrapped backplane.

And of course, no computer of this vintage would be complete without Das Blinkenlights:

 It's a bit dirty at the moment (and some schmuck stuck some masking tape on the panel and a few of the switches) but with some elbow grease it should clean up nicely.  The lights on this display the contents of the Memory Address, Memory Buffer, and Accumulator registers, and show decoding for the instruction being executed and a few status bits.

My 8/L is serial number 467, which makes it a pretty early unit.  Based on datecodes on the ICs I've looked at, I'd place it somewhere at the beginning of 1969.  So, this is now the oldest digital computer in my collection, huzzah!

I'm still focused on getting the Imlac running, but I'll probably spend some time working on this over the next few months as well.  According to the seller, this unit was working when put into storage a decade ago, and it does look to be in pretty good shape.  I don't foresee any major problems in getting this thing running again.

The 8/L in it's rather homely rack enclosure.

That's all for now -- until next time, make a little birdhouse in your soul!

sImlac v0.0 is ready for human consumption

Just a quick update today.  After spending numerous hours hunting down a couple of well hidden (and very stupid) bugs, I finally have sImlac (the Imlac emulator) in a state where I feel like other people might actually want to play with it.

Pinball, looking like, well... Pinball

You can grab sImlac 0.0 from here.  You can grab Imlac software from here (thanks again to Tom Uban for providing this).  The readme.txt file is basic but functional -- feel free to bug me if you have questions.  You'll need .NET 4.0 (or the latest Mono) to run it.  Having a fast machine wouldn't hurt either as at the moment absolutely nothing is optimized at all.

Have at it!

See you, Space Cowboy...