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

Solving the last of the obvious faults

About time for another update, I'm overdue.  And this'll be a relatively quick one, but there is some good news.

At the time of the last blog post there were three known faults left with the main CPU (at least the faults that can be detected by playing with the front panel and having no memory):

Memory Buffer:  Bit 1 behaves oddly (will only turn on if Bit 0 is also on)
Program Counter: Bit 15 does not load correctly.  Loads as a 1 when set to 0 and bit 14 is incremented when a 1 is loaded into bit 15.  The register increments correctly, however.
Memory Reads:  Bit 1 is always stuck on when a read is done from memory (either from the Diode ROM or from non-existent memory elsewhere).

The Memory Buffer problem turned out not to be a bad 74H52 as I suspected.  After replacing the chip there was no change in behavior.  I replaced the original chip and looked at other culprits.  The real issue was a bad 7495 at B2, which I probably should have noticed to begin with.

The problem with the Memory Reads was clearly not due to any problem with the Memory Buffer register -- moving the boards around did not move the stuck bit.  The only other option was the Memory Output Buffer board, at position 114 (or 111 in the schematic, my machine varies a bit from the schematics in places).  Inputs to the 7403 at C1 looked to be fine, but the outputs were always 1.  Replaced the 7403 and bit 1 was fixed.

I spent some time poring over the schematics trying to figure out the issue with the PC register.  My initial description of the problem is accurate but there's a more obvious one:  The PC that gets loaded is the address switches + 1.  From the schematics, this almost seems to be intentional, but I'm not 100% sure yet.  (And the user manuals I have of course do not cover the operation of the front panel.)

So, two problems are fixed and one problem turns out to potentially not be a problem.  That's pretty good!

I realized I hadn't checked the Display Program Counter register.  This register can be viewed from the Control Console, but cannot be modified with it.  However, it uses the same boards as the Program Counter, so by swapping them around I can do basic testing from the console.  Turns out bit 11 is stuck on on load, but will change on increment.  This indicates that the 74161 shift register and the other chips on the other side of it are probably OK.  Which means that (surprise surprise) the most likely culprit is a bad 74H52 at D1.  And so it is.  Pulled the old chip, installed a new one and everything's golden.

At this point, I discovered another problem:  If the Data switches are set to 0 and a Store or Store Next operation is invoked from the Console, both the Memory Address register and the Program Counter register are incremented by 2 (instead of 1) every time a Read or Store operation is invoked from the front panel.

This is pretty odd behavior, and it took me awhile to track down.  The MA and PC register are basically tied together on Store, so that explains why both are affected in the same way.

The PC register supports an increment operation, which is invoked either under normal program control (i.e. to support normal program execution) or by the front panel (during a Read Next or a Store Next operation).  This increment is performed by the four 74161 counters -- the carry out of the first counter is tied to the "Count" input of the next, and the first counter's "Count" input is tied to logic that controls when increments take place.

If you look at the schematic, this input is provided by the "B, MB, MA, PC Control" board in slot 207.  Tracing the signal back a little ways lead me to the 7410 Triple-Input NAND gate at E4.  There are three inputs to this gate.  One is triggered on the T6 timing cycle from the CPU control, so it's expected that this input would go high during a load or a store.  Another is the output of the "ALU=" signal from the ALU.  Since the Data switches are 0 when this issue occurs, this input will also be high during a load or store (and this explains why the issue only occurs when the Data being stored is 0.)  The last input is the "SAM & EXEC" input from the "Instr. Reg & Decoder" board at slot 226.  There's no reason this output should go high during a load or a store operation -- the CPU is not running, and it is not executing a "SAM" instruction.

So, board 226 looks to be the culprit.  This board uses a pair of 7443 BCD decoders in a clever manner to decode instructions, the "SAM" output is derived from one of its outputs, but the outputs look OK (they are always low).  This leaves only one possibility: the 7404 inverter at B3.  Sure enough, when other inputs on the same chip (there are 6 inverters per chip) changed, the SAM & EXEC output from the chip went high, even though the associated input was also high.  I replaced the 7404 and now Store operations work properly again.

At this point the registers were all behaving properly, so I thought I'd try executing the code in the Diode ROM.  There's no working RAM in the machine, but the ROM should still execute, if the CPU decoding and control logic is functional.  Amazingly, it does appear to be executing correctly -- at least well enough to execute a simple loop waiting for TTY data to become available.  I'll take that as a good sign, and as a good place to stop for the day.

From here, I'm going to need to get the core memory system running so that I can run diagnostic programs in order to test the CPU further.  I'm not expecting that to go smoothly.

That's all for now.  Hm, so much for this being a quick update... Until next time:  Be the ball.