(last updated: 06-Jan-2017)
The current configuration is in its original 'as acquired' condition, except that I've returned a few loose boards into their original positions.
The second 16KW (32MB) memory board has two banks disabled giving the system a total of 28KW (56KB) of RAM, leaving the upper-most 4KW (8KB) for hardware options, as is usual with a PDP-11.
In addition to the 11/03 chassis, there is a second, expansion chassis. The system is floppy-based, using two RX01 dual-floppy subsystems as mass storage.
| H9270 / H9270 | A | B | C | D | |
|---|---|---|---|---|---|
| Q18/Q18 | 1 | M7264 : KD11-F : LSI-11 16-bit CPU w/ 4KW (8KB), EIS/FIS (KEV11) | |||
| 2 | M7955-BD : MSV11-CD : 16KW (32KB) Memory | ||||
| 3 | M7955-YD : MSV11-CD : 16KW (32KB) Memory (8KW disabled) | ||||
| 4 | M9400-YE : REV11-E : Expansion headers and termination | M7940 : DLV11 : SLU (console) | |||
| Q18/Q18 | 1 | M9401 : (REV11) : Backplane expansion | M7946 : RXV11 : RX01 Floppy controller (primary) | ||
| 2 | M7940 : DLV11 : SLU | M7946 : RXV11 : RX01 Floppy controller (secondary) | |||
| 3 | M7940 : DLV11 : SLU | M9400-YA : REV11-A : Termination, refresh, floppy boot | |||
| 4 | (empty) | (empty) | |||
20-Feb-2006
Part of a PDP-11/02 system in an archaic, badly banged-up, foam-green-colored 6-foot rack, which itself was part of a larger acquisition of several Qbus PDP-11 and MicroVAX systems from Longmont, Colorado.
This system consists of a BA11-M box/PS cabled to another BA11-ME expansion box/PS.
31-Aug-2007
This system was extremely dusty inside. It is nearly 30 years old and it looks like it! The whole syste, I guess, was used in a very dirty environment, almost as if outdoors. It has so much dust everywhere!
I used my normal drill for this system...vacuum all the surfaces and cranies, then remove a layer and repeat.
The boards in the system, as acquired, are:
CPU Chassis 1- M7264 : KD11-F : LSI-11 CPU w/ 4MW (8MB), EIS/FIS (KEV11) -> 2- M7955-BD : MSV11-CD : 16KW (32MB) Memory -> 3- M9400-YE : REV11-E : Expansion headers and termination | (empty) 4- (empty) | (empty)Expansion Chassis 1- M9401 : : Backplane expansion | M7946 : RXV11 : RX01 Floppy controller 2- M7940 : DLV11 : SLU | M9400-YA : REV11-A : Termination, refresh, floppy boot 3- (empty) | (empty) 4- (empty) | (empty)
I first removed the boards, and set them aside after vacuuming their surfaces. I then vacuumed the entire cage/power-supply assembly, getting as much of the dust as I could. I then removed the wireframe cardcage with it's bottom pan attached, disconnecting, first, the 10-pin ribbon cable. Then I removed the bottom pan, giving good access to the wireframe, backplane, and the pan. I vacuumed each of these again, and wiped the pan with Windex to get it really clean.
I removed the front panel switch assembly and cleaned the plastic faceplate and switch PCB. There is a 16-pin ribbon cable that connects the upper socket on this PCB to the power supply PCB. Also, in this case with the expansion chassis, there is another 16-pin ribbon cable the connects the lower socket of this PCB to the upper socket on the expansion boxes PCB. This is the switch interlink and controls the power switching remotely on the expansion box. I took photos of how this cable was connected and routed, so that I can get it back again.
Then the hard part. Wanting to do a better job on this system than I did on the 40-inch racked PDP-11/23, especially with so much dust, I worked out a way to get the wireframed power supply sub-assembly appart. The key is to remove the 18-guage power ribbon cable from the underside of the PCB, then remove the push-on terminals to the rectifier attached to the rear of the big heat sink, and the square molex-type connector on the PCB. I took lots of photos to show how this is finally done. Then by removing two countersunk screws at the rear side where the wireframe card cage goes will allow the PCB to be slide out and away, leaving the capacitor terminals still connected. There is no need to remove the wires from the capacitor terminals, since the positive (+) wires lead only to the disconnected Molex connector. So the wires can remain in place.
With that accomplished I was able to vacuum the power supply PCB, using my toothbrush to reach the few hard to reach areas, and then the boxer fans. The wires to each boxer fan are solder on, and can't be removed. This makes it impossible to remove the fans from the assembly. But, I did loosen the fans by removing two countersunk screws and nuts, each, and this allowed me to vacuum all six faces of the fan, getting almost all of the dust, even from inside the blades.
So, with this state of disassembly, I'm ready to reform the capacitor. It'll have to wait a day or two; I'm right in the middle of reforming the capacitors on the RX01 #1 unit.
31-Aug-2007
I'll keep this short, since the two chassis are identical. I performed the same operations as I did for the CPU backplane, and have this unit ready for capacitor reformation, too, awaiting it's turn in the queue. I took a few photos, not many, as I worked on this one, just to show the cables that tie the two chassis together.
02-Sep-2007
With the successful reformation of caps in the RX01 #1 and #2 units, I put this unit in the works. And since each power supply, from the CPU chassis and the expansion chassis, has only one capacitor, I decided to reform them together. I just put them in parallel and then connected the bench power supply.
-5v (8:39p-8:39p), I could see right away that these capacitors were showing no problems, the voltage rose rapidly and the current dropped immediately to just 85uA.
-10v (8:39p-8:40p), again a very rapid rise to voltage with current ending after just one minute at 60uA.
-20v (8:40p-9:25p), rapid rise to voltage, and settling at 300uA. Finished at 20uA.
-40v (9:25p-), nice steady climb to voltage, settling at 530uA. I'll let this 'cook' overnight.
03-Sep-2007
I put together a minimized system with just the CPU chassis, and which included the M7264 CPU, M7955-BD 16KW memory, with a DLV11-J temporarily stolen from the 48-inch PDP-11/23, and the '0/1' M7946 floppy controller. I didn't connect the RX01 subsystem yet. Upon powering up I got console output! Great!
But, a problem. The sytem stays in HALT mode, even with the HALT/RUN switch in the RUN position. I can step through instructions using the ODT 'P' command, but if I use 'G' it just halts again, as if the HALT/RUN switch is always in the HALT position. I checked the ribbon cable from the front panel, and to the backplane, and cosmetically they look good. Next I'll have to make sure they are electrically okay.
Well, I figured it out! I need to have bus termination! I installed the M9400-YA bootstrap board, and it did the trick! Since I now had floppy bootstrap, I tried it. After connecting the RX01 ribbon cable, it works! I first had to copy a new DX (instead DY) bootstrap to my working floppy. The boot ROM just presents a '$' prompt on the screen, and I figured I'd just go with the general model I've used. I tried 'DX
I tried to work with the TU58 emulator, but it get's read errors, which is a surprise. I believe it's because the 38400 baud rate on this LSI-11 system is just too fast. I might slow it down and try again, for confirmation.
04-Sep-2007
After sorting out the second RX01 unit's power supply, I wanted to try it with the system. Using last night's setup, I tried it. All is well! So, knowing that the RX01 works fine, I swapped RLV11 controllers and tested with the '0/1' controller. Still works fine! This is good!
I let the system just run for a while, excercising itself by running MAZE.SAV. No problems. No smoke. No inordinate heat. All good, so far.
Now, I need to test everything, all together...the expansion chassis, the second board of memory, and somehow, the DLV11s that are set for 20ma current loop operations.
Hmmm. I wonder. Do the DECwriters and printer belong to this system? Everything is configured for 20ma current loop. It just might be!
05-Aug-2009
Today, after a long time of having the replacement fans on hand, I decided to replace the two flaky fans in this unit, one in the CPU PS, and one in the expansion bus PS. I removed both chassis/PS assemblies and plugged each in to confirm that it is the fan in the inboard location that is bad in both units. The CPU's fan is dead, and the expansion chassis's fan won't spin on its own until it is given an initial push. So out they go!
I started with the CPU unit, first removing all of the PCBs and then removing the 4 screws that attach the card cage to the PS. Releasing the PS cable to the card cage, and the logic cable, let me remove the cardcage, exposing the fans and their attaching screws.
Once clear it was easy to remove the old, bad fan and replace it with the new one, which is a perfect match. The only issue was that the old fan has only soldering lugs, to which were soldered two wires. The new fans have pre-attached wires. So, what I did was to mount the new fan, and clip the leads short, then solder them to the pre-existing wires coming from the switch terminal block. Very easy. I used the original wire's heat shrink tubing to insulate the new connections, and I was done!
I performed the same procedure on the expansion chassis PS, again with no trouble.
05-Aug-2009
Well, I'm now ready to fire up the whole system. What I can't remember if I already reconfigured the two RXV11s, or not. I'm going to pull everything again (should have done this when the systems were apart!) and confirm the configuration of each board. As I did so, I changed the "2/3" RXV11 Address and Vector settings from primary to secondary, so that both RXV11s will co-exist.
CPU CHASSIS:M7264 etch E : KD11-F : LSI-11 CPU w/ 4KW (8KB), EIS/FIS (KEV11) : s/n AB75107059 - Memory bank 0 (address 000000) selected (W1 removed, W2 jumpered) - LTC interrupt enabled (W3 removed) - Memory refresh enabled (W4 removed) - Power-up mode 2 (PC to 173000) (W5 removed, W6 jumpered) - Memory reply enabled (W9 removed) - Reply during refresh enabled (W10 removed) - Onboard memory select enabled (W11 jumpered)
M7955-BD : MSV11-CD : 16KW (32MB) Memory : s/n MO8130337 - Starting address 020000 (SW1: off; SW2-5 on) - No banks disabled (W4,W8,W12,W16 jumpered) - Internal refresh enabled (W7 jumpered) - External refresh reply disabled (W6 jumpered) - Battery powered disabled (W1,W5 jumpered) - Battery power to refresh circuit enabled (W2,W3 jumpered) - Bus grant enabled (W14,W15 jumpered)
M7955-YD : MSV11-CD : 16KW (32MB) Memory : s/n 2507609 - Starting address 120000 (SW1,3: off; SW2,4,5 on) - 2 banks disabled (8KW used) (W4,W8 jumpered; W12,W16 removed) - Internal refresh enabled (W7 jumpered) - External refresh reply disabled (W6 jumpered) - Battery powered disabled (W1,W5 jumpered) - Battery power to refresh circuit enabled (W2,W3 jumpered) - Bus grant enabled (W14,W15 jumpered)
M7940 : DLV11 : SLU : s/n AB4460863 - CSR at 177560 (standard console) (A3,A7 jumpered, A4-A6,A8-A12 removed) - Vector at 60 (standard console) (V3,V6-V7 jumpered, V4-V5 removed) - 9600 baud (FR0,FR1,FR2 jumpered, FR3 removed) - 8 data bits (NB1,NB2 removed) - 1 stop bit (2SB jumpered) - No Parity (NP removed) - Odd parity (PEV removed) - Framing error halt (Halt on BREAK) (FEH jumpered) - Active 20ma configured (CL1,CL4 jumpered; CL2,Cl3 180-ohms) - EIA drivers disabled (EIA removed)
M9400-YE : REV11-E : Expansion headers and termination : s/n AB2520486 - (factory configuration) (W1,W3 jumpered)
EXPANSION CHASSIS:
M9401 : Backplane Expansion : s/n AB2301520
M7940 : DLV11 : SLU : s/n (missing, 744F on handle) - CSR at 177500 (A3-5,A7 jumpered, A6,A8-12 removed) - Vector at 300 (V3-5 jumpered, V6-7 removed) - 4800 baud (FR1,FR2 jumpered; FR0,FR3 removed) - 8 data bits (NB1,NB2 removed) - 1 stop bit (2SB jumpered) - No Parity (NP removed) - Odd parity (PEV removed) - Framing error halt (Halt on BREAK) (FEH jumpered) - Active 20ma configured (CL1,CL4 jumpered; CL2,Cl3 180-ohms) - EIA drivers disabled (EIA removed)
M7940 : DLV11 : SLU : s/n (missing, 745F on handle) - CSR at 177510 (A4,A5,A7 jumpered; A3,A6,A8-12 removed) - Vector at 200 (V3-6 jumpered; V7 removed) - 300 baud (FR1 jumpered; FR0,FR2,FR3 removed) - 8 data bits (NB1,NB2 removed) - 1 stop bit (2SB jumpered) - No Parity (NP removed) - Odd parity (PEV removed) - Framing error halt (Halt on BREAK) (FEH jumpered) - Active 20ma configured (CL1,CL4 jumpered; CL2,Cl3 180-ohms) - EIA drivers disabled (EIA removed)
M7946 etch C : RXV11 : RX01 Floppy controller : s/n AB81331485 - [marked "0/1"] - CSR 177170 (W7,W12,W13 jumpered; W8-11,W14-17 removed) - Vector 264 (W1,W3-4,W6 removed; W2,W5 jumpered)
M7946 etch C : RXV11 : RX01 Floppy controller : s/n AB81331523 - [marked "2/3"] - CSR 177174 (W12,W13 jumpered; W7-11,W14-17 removed) - Vector 274 (W5 jumpered; W1-W4,W6 removed)
M9400-YA : REV11-A : Termination, refresh, floppy boot : s/n AB80511226 - DMA refresh disabled (W2 removed) - Bootstrap ROM enabled (W4 jumpered)
With all of the boards' configurations identified, it was time to test everything out. I reinstalled all boards except the two spare DLV11 SLUs. Because the all of the SLU options, including the first one (configured for console) are set to use 20ma current loop, I decided this would be a good time to re-energize and exercise my Decwriter II, which is configured for 20ma also. I changed the buad rad of the primary SLU to 110, and cabled up the disk drives, and the Decwriter II.
When I powered on, I saw the front panel lights (though the DC OK doesn't light on the CPU chassis) and got output at the console! It gave me the '$' prompt as expected since I'm using a REV11 bootstrapper. My first tries at booting from the floppy ( using $ RX) were not successful; I kept getting '173756' output and being dropped to ODT. I tried 'RX0' and 'RX1' with the same results. Reading in the handbook says that when booting, the system will first test the CPU and the memory, then boot. I was seeing a faulty memory error.
The bad address is in R2 with the expected data in R3. When I checked this out using the 'XM' command, I see address 150044 failed, containing 040000 not 000000 as expected, and after hitting 'P' to proceed shows address 146474 also failed, containing 040000 not 000000 as expected. So I have two bad address, with the same bad bit (bit 15 of 16). I must have a single bad memory chip. I pulled the memory board (filling the bus with the two spare SLUs) and no longer had errors, so I have confirmed that the second memory board is faulty. Now the challenge will be to figure out exactly which chip (out of 64) to replace! The memory array is made up of MK4096N-19 chips, all dated from mid-1977.
I left the 2 spare SLUs in and tried to boot again, but still no joy. I'm not sure that my floppy is correctly built for booting from an RX01, since all of my other gear uses RX02s. Checking on my tall 11/23, I confirm that the floppy's boot blocks contain the DY driver, not the DX driver that this machine needs. I tried to build the correct floppy configuration, but it still didn't work. I'm not convinced that the floppy is functional, so that should be worked out first of all.
I did, however, sadly, discover that the 0/1 (masking tape labels) RX01 unit is NOT responding. I confirmed this by moving the 2/3 unit to the 0/1 controller and saw that work. So, it looks like I have some problems in one of the RX01 floppy units.
Quickly removing the front panel and checking the DC ON LED with my VOM's continuity/diode tester confirms that the DC ON LED is high resistance in both directions. Looks like it has become open-circuit. I confirmed this with a 3V battery source, using a 690-ohm series resistor, and sure enough, the LED is dead. Turns out there is a third, unused LED on the PCB, so I'll just use it as a replacement!
So, today's outcome? I found three hardware faults that need to be corrected: 1- Front panel DC ON LED needs to be fixed 2- Second memory board has a bad MK4096N-19 chip 3- First RX01 floppy subsystem is not communicating
Still, looking back at my September 4, 2007 entry suggests that the second RX01 unit was working then at least. Hmm.
05-Aug-2009
Well, rather than wait, I just went ahead and tackled replacing the DC ON LED in the contol panel assembly. It was easy to remove the control panel, just remove four screws, but I almost lost the washers that are 'behind' the circuit board. After a little frustration, I had them gathered up.
I desoldered the LEDs, but I'm not very good at using a soldering iron and in the process I overheated the 'good' LED that was to be my replacement. Once it came off, it no longer worked. I dug around in my junk bin and found another LED. It's not the same type, but it will work. Soldering the LEDs back onto the PCB was easy, and was done quickly.
Now the real challenge arose. How to refit the control panel with those pesky washers? What I ended up doing was feeding the screws through their holes and just 'hanging' the washer on the few threads of the screw that protruded. It made for some delicate maneuvering, getting all four washers on together, and then placing the whole assembly squarely onto the mounting posts. After three tries I got it done, except one washer had slipped off-center a bit preventing the screw from going through. I fished the screw out, while keeping the washer pinched in place. Then with a long stiff wire, I recentered the washer and finished with the screw. Whew!
Well, the good news is that the newly installed LED works and I can now see the DC ON indication as I should. The mostly inconsequential bad news is that the replacement LED is slightly dimmer than the original, which is apparent if you pay attention, but it works, and I'm happy.
One problem down, two more to go!
05-Aug-2009
Looking carefully at the etchings on the memory board, I see that the columns are marked E100 on the upper-right of the chip array to E115 on the upper-left. My guess is that the rows (each a 4MW 'bank') are numbered from bottom to top, but it could be from top to bottom. So that suggests that there are two possible locations of the bad chip, both in column E114 (15th bit) in either the second or third row, depending on if the counting is up or down.
Now I need to get a replacement MK4096N-19 chip.
31-Aug-2011
I have a [faulty] recollection that sometime back I ordered and received a tube of replacement 4Kx1 MK4096 memory chips. With them on hand, I can complete the job of determining which chip is the faulty one and replace it. [Turns out I DO NOT have the replacement chip after all.] I've examined the board carefully, and referenced the board details in the CPU and Memories handbook, but cannot readily determine from those efforts exactly which chip is responsible for which address and bit. So I have a plan.
I know that the faulty chip is one of four, that is, it's in bank 2 and is the 15th bit, so depending on how the board is laid out it could be column E114, or column E101. My method will be to short the lowest address pin which will force a fault on that chip. The using the ODT facility I can test addresses to determine if the new fault corrosponds with the address of the original fault. When that is true, I know that I've found the correct chip.
11-Sep-2011
Today, at last, I fired up the system in order to begin further isolation of the bad memory chip. I'm happy to report that the system, attached to the Longmont DECwriter II, is functional with two exceptions: the bad memory board, and the first RX01 dual-floppy subsystem ("0/1"). I've got the system running with the second RX01 subsystem ("2/3") in place of the first as DX0: and DX1:, and with the bad M7955-YD memory board pulled.
I decided to check each row separately on the faulty memory board and I did this be enabling just each row, and using the onboard memory checker in the bootstrap board, it should tell whether the memory it finds is good or bad. So I installed jumpers to single rows in the following manner, with these results, using the 'XM' command at the '$' prompt (see the REV11-A section of "Microcomputers Interfaces Handbook"):
Jumpered Results ------------- --------- W4-l to W4-r no error W4-l to W8-r no error W4-l to W12-r fails with 173732 (address) and 173756 (data) errors W4-l to W16-r no error
I was unable to determine what the error really was when doing my third test, since when I was dropped to ODT after running $XM, it seemed that both R2 and R3 are identical. This has me stumped. (Later, I realized that I needed to examine the date at the address held in R2!)
Continuing, I reset the jumpers so that both W4(l-r) and W8(l-r) are jumpered. This should give me 8KW (4+4) enabled. I installed the board and ran the '$XM' test. I saw no errors.
Then, I added the W12(l-r) jumper and tried things. I now see errors from the '$XM' command. Here are the results:
Expected Data (R3) Mem Address (R2) Faulty Data ------------------ ---------------- ----------- 000000 070044 040000 000000 066474 040000
So, we have two errors with the same faulty bit. Working out the octal shows that the faulty bit is the 14th bit:
0 4 0 0 0 0 0 100 000 000 000 000
Trying to force errors on the particular chip that I thought might be the culprit (E114 on 3rd row down from the top handle) I first jumpered [Vcc] - [Dout] trying to force the data to always be high. With this done, I reinstalled the board and started the system. Running the '$XM' test gives address(!) errors on every address from 037776 through 037770, which was as far as I went. I removed the board and removed the jumper, instead connecting [Vcc] - [~CS] thinking that would force all addresses in the row to readout '0' in the 14th bit. This time I saw address(again!) errors, starting at 077777 and below. So it looks like this method of jamming the data isn't working. I removed the jumper, reinstalled the board, and confirmed that I didn't make anything worse. I now see just the two same data errors as before.
By the way, after my first round of jumpering, I believe that I have confirmed that the left-hand post of each bank select jumper is tied to the bank select, and the right-hand post is tied to the physical row of chips. This may be useful to know since the rows are to be enabled in order (W4, then W8, then W12, then W16). If a bad chip, as I have, forced one to abandon a row of chips, one could cross-wire the posts to select banks in sequence, but still skip or change the order of the physical rows of chips.
15-Sep-2011
I've decided to just go ahead and use this troublesome memory board as is, enabling two banks (which is all I can really use anyway), and wait for the chance to pick up some MK4096 memory chips. I will still have a total of 28KW (56KB) of working memory, the maximum for this LSI-11 CPU. I've had some difficulty locating some replacement chips online without spending a lot of money.
First, though, confirmed that the fourth row(bank) of memory chips is working by jumpering [W12-left] to [W16-right] to enable that fourth row of memory as if it were in the third row (for memory contiguity) and it works fine, passing the memory test in the REV11-A bootstrap board. I removed that jumper to return the board to having just the top two rows enabled and reinstalled it after installing the first 32KB memory board.
15-Sep-2011
I also completed the re-configuration of the second RXV11 controller ("2/3") to be at the recommended CSR and Vector addresses:
M7946 etch C : RXV11 : RX01 Floppy controller : s/n AB81331523 - [marked "2/3"] - CSR 177174 (W12,W13 jumpered; W7-11,W14-17 removed) - Vector 270 (W1,W5 jumpered; W2-W4,W6 removed)
So, with the two floppy controllers installed, I now re-installed the 2nd and 3rd DLV11 SLU boards that had been removed for my memory adventures, and now have the system fully configured and operational, all but for the "0/1" RX02 dual-floppy subsystem, using the DECwriter II on a 20ma loop as a console device.
16-Sep-2011
After reading my notes from the RX01 subsystem cleanup and checkout I discovered that the first ("0/1") RX01 subsystem is working fine. Today I confirmed that the cabling between each RXV11 controller and it's partern RX01 subsystem was correct, then fired the system up to confirm that both drives of each RX01 subsystem are working. They are.
With that issue settled, I need to SYSGEN RT11 to support both RX01 controllers/subsystems. I used the Darien PDP-11/23+ running RT11 v4.0 to perform the SYSGEN. I mostly used the defaults except that I enabled:
- Single-Job Monitor - Foreground/Background Monitor - Floating point support - BATCH support - Two RX01 subsystems - TU58 support - Line Printer - Serial Printer - Two extra device slots
I had specified the output device to by DY0:.
The @SYSBLD sequence built the two monitors and device drivers. I renamed them from *.SYG to *.SYS, and these were put onto a floppy for use with this system only, designated "PDP-11/03 MONSTER". Also I put SWAP.SYS on the floppy and then installed the bootstrap loader:
. SYSGEN . @SYSBLD . COPY DL2:SWAP.SYS DY0: . RENAME DY0:*.SYG DY0:*.SYS . COPY/BOOT:DX DY0:RT11SJ.SYS DY0:
03-Aug-2014
Today while exercising the system the printing terminal just kind of froze after the first bit of output. It dragged paper, as if the pins in the printhead were not fully retracted, then lost power to the carriage motors. Checking, I found that the 2A slow-blow fuse to the carriage motors had burned out. I replaced the fuse, but found that the carriage was hanging up on the paper, and the ribbon.
I did a little simple troubleshooting and discovered that one pin (#3) was indeed not fully retracting when idle. If I turned off the power to the terminal, then the pin, along with all others, would fully retract. Hmmm...
A little investigation showed that the driving circuit for Pin #3 was always on, even when the system was powered but idling. I rounded up the maintenance printset from bitsavers.org and tried to track down the culprit.
After a few isolated attempts over the next several days, I found that the circuit (which is identical, and replicated for all other six pins) is a Darlington formation, where one transister drives another, and in this case it is a series of three transistors with the last being the big power transistor that actually controls the 42 volts that drives the printhead solonoid. It turned out that the input to the first two transistors Q3, and Q2 were off, but Q1, the power transistor was on anyway. Looking deeper, I found that there is a series of four 1N4744 zener diodes that form a sort of feedback loop from the collector to the base of the power transistor. Checking each zener (using the identical circuits for the other six pins as reference) I found what I thought was the culprit. One of the zeners, D1, was showing the ability to conduct in both directions, about 385 ohms each way. This did not agree with the other zener diodes in the series, nor with the zener diodes in the other pin's circuits. So that was a likely culprit.
After a confirmation of this analysis from my friend, Bill, I order a replacment, actually five replacements, along with other supplies from Digikey.
31-Aug-2014
While working with through the troubleshooting and repair of the LA-36 DECwriter II, the second RX-02 unit began to spontaneously engage the head engage solonoid on both drives, simultaneously, sometimes with long time spans between events, sometimes the events would occur in rapid succession. Attempts to boot or simply read from either drive (DX2:, DX3:) fail. I'm guessing something has gone wrong with the QBus controller, but it might be in the subsystem itself. Needs to be checked out soon.
Copyright © 2006-2025 Jared Blaser. All rights reserved.