Hit a snag on the way to getting PDP11GUI hooked up: while the M9301 console emulator was working fine with the VT52, I could not get serial communication to my laptop (MacBook Pro + Keyspan USA-19HS USB serial) to work as expected. Some detective work showed that the voltages from the EIA output drivers on the DL11 were way out of whack (+3V for mark, which should have been a negative voltage). Somehow the VT52 was able to still make sense out of this signaling, though the laptop was not.

Some investigation of power to the DL11, which was sitting in one of the backplane SPC slots (26-28), showed that there was no distribution of +15V to pin CU1 of these slots where the DL11 was expecting it. So that explained the bad driver output voltages. Moved the DL11 over to the DD11 expansion backplane which does have +15V to that pin, and serial to/from the laptop started working fine.

So this raises a bit of a question about the SPC slots on the 11/45 backplane. Was EIA console serial from these slots ever supported? The configurations listed in the 11/45 engineering prints call out only DL11-A, the 20mA current loop version, which doesn't have EIA drivers and thus doesn't need the +15V supply, so maybe not. Was +15V distribution perhaps added to these slots in subsequent revisions or via an ECO? I'd like to track down a wire list for this or later revision 11/45 backplanes, and/or a comprehensive list of KB11-A ECOs, but so far haven't seen traces of either anywhere out there.

One other curiosity of these SPC slots that came up while investigating this: the power distribution table in the 11/45 maintenance manual, EK-11045-MM-007, page 5-10, implies that +15V should be distributed to the SPC slots on CA1. This is suspicious to me (maybe a typo?) because all other SPC pinouts that I have seen use this pin and CB1 as NPR in/out. And in checking my backplane, there is no power distribution to those pins. But slots 27 and 28 (Unibus B) do have their CA1 pins bridged to one another, and their CB1 pins bridged to one another, with what look like factory installed wire wraps. This also seems unusual for NPR/NPG. So, some mysteries remain about these slots...

In other news, the clock oscillator on the VT52 has given out, so that's down now until I can find a replacement. They are out of production and aren't easy to track down, but I do have one lead to follow so far.

Also, I pulled the suspected failed subsidiary ALU control ROM, tested it in isolation, and verified that it had indeed failed. This card is just a spare for me, but I'd like to go ahead and repair it since the fault is isolated. With some help from the classiccmp mailing list (thanks guys!) I have a recommendation for some vintage PROM programmers to stalk on eBay, and some compatible parts, that would allow me to blow a replacement and make the repair.

Replacement DRAMs showed up. Pulled and replaced the two faulty ones on the MS11. Pic below -- you can see the replacements are socketed, and are the TI parts instead of the original ITT. Full address space is working now! Now that bank 0 is repaired, trap vectors can conceivably work.

Jumpered and configured a DL11-E serial card for use as console, slotted in an M9301-YB bootstrap terminator, connected up the VT52, powered up, and off it goes straight to the console emulator! That means the basic instruction set tests in the boot ROM are passing as well, which is great news.

Next step will be to hook up PDP11GUI and load some more in-depth diagnostics, in order to shake out any remaining bugs with the CPU and memory system. Will slot in the FPU at that point for testing and debug as well.

Tracked down the source of the inverted result after register-to-register move problem on GRA: outputs of the subsidiary ALU control ROM E74 on pins 6 and 7 are floating. Will need some closer inspection to determine if this is a board fault or a chip fault. In the meantime, I have a spare GRA which I had been reluctant to try because it has a "bad" sticker on it... Decided to give it a try anyway, and it seems to be working much better than the one I have been debugging.

Now have enough of the CPU debugged to toggle in and run a simple light chaser program:

1
2
3
4
5
6
7
8

000000  013700  177570  L0:     MOV     @#177570, R0    ;LOAD COUNT FROM SWITCH REGISTER
000004  005300          L1:     DEC     R0              ;COUNT DOWN
000006  001376                  BNE     L1              ;LOOP UNTIL ZERO
000010  006301                  ASL     R1              ;SHIFT DISPLAY VALUE
000012  001002                  BNE     L2              ;SKIP AHEAD IF NOT SHIFTED OUT
000014  012701  000001          MOV     #1,R1           ;ELSE RELOAD
000020  010137  177570  L2:     MOV     R1,@#177570     ;STORE TO DISPLAY REGISTER
000024  000765                  BR      L0              ;REPEAT FROM THE TOP

Some notes on the program and video above since I've received some questions:

• The listing here is shown assembled at location 000000, but the program is relocatable and can be toggled in at any convenient address (000000, on top of the trap vectors, probably isn't the best choice!)

• Data display should be on "DISPLAY REGISTER" to see the chase.

• The front panel toggles are loaded into a counter to control the speed of the chase. Without some of the most significant bits set the chase may go too fast to see, especially on older 11's with incandescent indicators. All toggles off is a special case: this will be the slowest chase, since as written the counter wraps around when decremented before being checked for zero. The video has toggles 15 and 14 up.

• If you look at the address lights in the video, you can see that I ran this program from address 100000. This was because at the time I had a fault in the first 16KW of memory on my MS11-L so I couldn't execute any code at lower addresses.

After addressing the -15V problem on the MS11, most of the bad behaviors seem to have cleared up except a stuck (on) bit 6 in the first 16K words of address space (000000-077776). Hooked up the new logic analyzer, and it has been very useful in troubleshooting the board -- can easily capture and inspect the timing of complete memory cycles. Definitely worth the investment!

Using the analyzer, I was able to verify the refresh and chip select logic on the board, then track down the stuck bit to what seems to be a single failed DRAM chip (E96 on the MS11-L engineering drawings). I'd like to test the entire card before ordering replacement parts, but need to set up address translation to get beyond the first two banks from the console.

Here is the address translation register setup that I used for testing. This was followed by a deposit of 000001 to KT11 SR0 (777572) to enable translation. KT11 SR3 was left all zeros to keep D space disabled. This setup allows console access to physical addresses in banks 1 through 7 by appropriate settings of virtual address bits 13 through 15. I wanted to reserve PAR7 to map I/O space, so I left out bank 0 since it was one of the two already tested.

This worked as expected according to panel PROG PHY and the logic analyzer, so the KT11 option which I had not previously tested is at least working for kernel I space. Tested each bank on the MS11 from the front panel using this setup, and uncovered that bank 4 bit 10 also has a stuck on condition. Since bank 1 is working now, I can use that as work space for the time being in order to continue the CPU debug while awaiting some replacement DRAM chips in the mail.

Pics here of the logic analyzer setup, and captured traces of a write and subsequent read to one of the misbehaving chips:

Made some progress on the inverted result after register-to-register move problem: with the help of the KM11, extender card, and a logic probe I was able to track down that signal ALUM L coming onto the DAP is not asserted when it should be for a MOV instruction. This means the ALU is performing in arithmetic instead of logic mode and thus the incorrect result.

I next moved the extender card over to GRA, where this signal originates from a subsidiary ROM, but unfortunately at that point the MS11-L memory behavior got even worse, putting and end to these experiments. So I'll have to tackle that first...

Moved the M792 ROM over to the expansion backplane where the MS11-L resides, and it works fine there. So it doesn't seem to be a bus wiring or jumper problem onto the expansion backplane. Checked the power input pins on the backplane behind the MS11-L. 5V was a little low there; trimmed this up. Probably need to clean or replace the Molex contacts on the power distribution board in the cabinet, as it seems a few mV are being shed there needlessly compared to the output of the same regulator on the main backplane, but things seem within stated tolerances for now.

The -15V input to the MS11-L was missing entirely. Removed the DD11 expansion backplane, and added jumpers between the battery backup supply inputs and the corresponding main supply inputs, per documentation. Now have -15 to the MS11-L, but still no joy.

Will need to go deeper into the MS11-L next time...

Received the boards and components for the KM11 replica; stuffed and soldered, and it appears to work! There are some photos below. I can easily single-step microcode, clock states, and bus cycles now, which should really help with the CPU debug.

Swapped DAP for a spare, and this has fixed the stuck PC issue. Memory issues remain, but by choosing a working memory range, I can start to toggle in and attempt to execute very simple programs.

The simplest possible program, unconditional branch to self, seems to execute correctly:

1

001000 000777         BR      .-0

A register to register data move test does not however:

1
2

001000 010203         MOV     R2,R3
001002 000776         BR      .-2

Control flow is as expected, but the value that ends up in R3 seems to be negated. Still, pretty good progress! Now that I can step machine states, the next step will be to put the DAP out on an extender card and start tracking down signals with a logic probe.

The HP1662A logic analyzer from eBay has also arrived; should come in handy in investigating the memory issue.

Received and installed the replacement lamps for the -15V regulators. Pic below shows what the power supply looks like with all the lamps functioning.

Verified backplane DC voltages and ripple currents again, and re-trimmed all the DC regulators. Verified AC LO and DC LO deasserted and free of glitches. Found some harness wiring mistakes to the DD11 expansion backplane; corrected these.

Tried some CPU board-swaps looking for a quick win, but broken console behavior didn't change significantly with different boards.

Investigated the timing generator board, and found that the crystal oscillator wasn't oscillating. Tracked this down to inductor L1 which looked as if it had been partially sheared away from the board at some point during installation/removal/storage. Repaired this. Success! Able to load addresses from the front console now. Switches are mirrored in the BR when halted in console.

Address bit 0 seems stuck. Swapped PDR from spare board back to the original. Can now examine and modify the light/switch register, and examine the contents of the M792 ROM.

Jumpered the DD11 expansion backplane back in, and slotted in the MS11-L memory. Limited success: can modify and examine memory for example near address 001000, but cannot modify low memory addresses. In some ranges, can only modify every other word. Also, PC seems stuck at 022000.

At this point, I could really use a KM11 maintenance board set. These are pretty hard to get a hold of, but a few folks on the web have built their own reproductions. I put in a PCB order to ExpressPCB with a KM11 layout by Tom Uban (described here), and also put parts on order to stuff it.

Also, figuring I'll need to be going deeper into the CPU debug, I found and bought an HP1662A logic analyzer on eBay, for about the same money as the KM11 PCB and parts!

Connected up the aforementioned red wire hack to the new power harness, and verified +5V to slots 10 through 15. Console is no longer all address and data lights on, but basic console load address / examine / deposit operations are still not working. A random assortment of address lines seem stuck, different on each power cycle. About the only thing that reliably functions from the console is loading the two highest address bits from the switches immediately after a reset. Pulled the floating point unit, unjumpered the DD11 expansion backplane, and removed all peripherals except the M792 diode ROM; same (broken) behavior...

Scoped all the DC voltages, and did not notice any glitches. Pulled the H742s for some bench work: verified AC LO and DC LO signaling on both units, replaced a broken Mate-n-Lok connector on one of the units, blew out dust from all the 5V regulators and replaced their indicator bulbs with modern equivalent (CM7381). Sourced and put on order a modern equivalent (OL-6003BP) for the indicator bulbs on the -15V regulators.

Next steps will be to verify various Unibus signals on the backplane, then maybe play some swap games with CPU card spares to see if I can get closer to a working console as a starting point. All I have time for this weekend, though; sorry nothing new to see so no new pictures this time!

Beeped out the new harness to check for shorts or incorrect pins, then plugged in just the H742s and fired it up. All the DC regulator modules seem to be working, and I was able to trim them up to nominal voltages at the CPU end of the harness. The indicator lamps on all but one of the DC regulators seem to be burned out, though, so I put some new lamps on order (at last for the +5V regulators; a modern equivalent for the -15V regulators is tougher to find).

Given that success, I plugged in the CPU side of the harness, took a deep breath, and powered on! Hmmm. No detonations or smoke, but all data/address/mode lights lit (see below), which is not right... Front panel lamp test and data address mode switches and indicators are working though at least.

Some investigation on the backplane turned up no +5V to slots 10 though 15, which could be part of the problem. Ah, that's what the mysterious clipped red wire soldered to the backplane might have been about (visible in the top right here...) Sure enough, some inspection shows the corresponding trace on the backplane looks burnt! I could hack this red wire into my new harness I guess, but I'd rather remove it and try to repair the board trace with a shunt. So the backplane will have to come out. I guess that's what I get for not investigating the weird red wire and for not beeping out the power distribution on the backplane before mounting and populating it...

Moved the power modules and partial harness back over to the racks today, got everything remounted, finished and dressed the backplane terminations, and completed the inter-H742 connections.

I did not do the runs for the backplane memory to the lower H742, as I do not have any backplane memory. I probably won't ever have any, either: these memory options are specialized to the '11/45, are quite rare, and only cover part of the available address space. Additionally, they would require me to track down the details of a backplane ECO to do the corresponding parts of the harness correctly. The core and MOS memory that I do actually have are all system-unit options anyway.

Here are some pics of the in-rack wiring in progress, and a couple views of the finished harness. If you add up the capacity of the DC modules, you'll see that an '11/45 like mine (with floating point) is provisioned with +5V at 100 [sic] amps, and -15V at 20 amps. That's no joke of a power supply...