Bringing up RL01/RL02 drives

The RL02 is a disc drive with changeable platters (“packs”), it can save 10 MB. Its older siblings is the RL01,  physical identical but can only save 5MB. DEC used them as big floppy drives: Small operating system can run directly from one or two RL01/RL02 drives. The RL02 was later used for software distribution.

Here are two in my office:



The RL01/02 drives are very common: almost every collection with a PDP-11 has those drives too. Here is a picture of a RL disk assembly line (slow link).

My 11/44 also came with a RL02 and a RL11 disc controller. I wanted to get the RL02 running first, because after that I could run all XXDP diagnostics from disc instead from simulated TU58 cartridges.

Making a cable

You can connect four RL02 to one RL11 controller in a daisy-chain fashion. I had a cable terminator, but no the special RL cable, and neither a “bulk head”: this is separate mechanical adapter which has a RL cable female at one side and a connector to the RL11 controller flat cable on the other. But I noticed that the RL11 controller has a 40 pin Berg connector on it, and inside the RL02 data was also routed by 40 pin flat cables. So I tried to connect directly RL11 controller and RL02 mother board with a 40 pin flat cable.

I’m very bad in geometry, so I attached signal tags to every cable side and the board connectors. So if the tags align, there’s no twist.



After that I was sure my cable connection was good. A first success was: after I powered the 11/44 on, the red FAULT lamp on the drive turned off, meaning the drive got clock from the RL11 controller in my PDP-11. But neither READY nor LOAD lamp ever lightened up. I checked all four light bulbs: READY and LOAD were burnt out. I replaced them, and disk packs could be loaded and removed by operating the RL02 as documented.

After that I ran the XXDP-diagnostics for RL drives. Result was negative: I could not made any contact to the drive, all diagnostics dumped out “OPI” errors. The same do you get, if the cable is not connected at all. Clearly a cable problem?

Testing the drive with an 11/53

I could not get the proper cables and bulk heads, but something much better: My computer club "CCG" had an PDP-11/53 with RL01/02 controller: a RLV12 with an attached cable! I connected this machine to my RL02: I got contact to the drive this time, but every read or write operation failed. So I had to conclude: my cable is trash, and/or my drive is trash. Hurray.

Getting a replacement drive, but somebody was faster

The C-C-G has an 11/34 with two RL01 drives in his collection.



So I planned to borrow there RL11 controller and RL01 drive and test my setup. When I opened the 11/34 box, I saw immediately that empty UNIBUS slot and a well known 40 pin cable ending in the air. Somebody else grabbed the RL11 out of that machine!

I got the drive and connect it to the 11/53 (a setup which did not contain ANY of my own parts). The result was the same: no read, no write.  So the 11/53 was defective too! And I moved RL drives through the house again and established the last combination: the RL01 on the 11/44. Same as with the RL02. Conclusion: no error ever moved with the drives, they stay with the PDP-11’s.

I really needed some positive results at this point, so I ran the XXDP diagnostics on an SimH -simulation of my machine. At least this indicated a good “drive”, so I was sure my setup and XXDP work.

Working smarter, not harder

With distance of a week I realized what had to happen next: learn to debug TTL logic.  As my experience with the 11/44 cpu showed me: If there are to many bad components floating around, this “swap-and-test” procedure leads to no results. Of course you can spend time and money to borrow or buy parts endlessly. But even if you “repair” machines this way, you do not really understand what you’re doing. A chimpanzee can be drilled to perform swap -and-test too!

So I got a little USB logic analyzer. You can get 34 channels with 500MHz sampling for $400, the company I work for payed it (since I can also use it for kernel mode driver development). And I read documentation again. Incredible, suddendly all the manual pages with “Detail function operation” and schematics and part positions on printed circuit boards and timing diagrams were filled with meaning. This was the right way!

Watching traffic on the RL11-RL02 cable

At first I monitored all wires from the RL cable while performing XXDP tests. Working with the logic analyzer was quite different from what I expected. Planing a test and setting up the probes may take more than an hour. Recording signals and interpreting them is a matter of minutes, even seconds.

First result was: the RL11 controller did not transmit any commands to the RL02 drive. The DRIVE COMMAND wire was always inactive.

Into the board

So I looked at the RL11 controller: were did the drive commands come from? I learned that a drive command is written to a 16 bit register and then serialized by a 16:1 multiplexer driver with a counter. The multiplexer (TTL IC 74150N) interested me most, and I clipped the logic analyzer on it.



A direct hit: The output of the multiplexer (signal “MUX OUT DRV CMD”) looked very ill! You see four parallel inputs at D0..D3, and the counter signal at CNT0..CNT8. MUX OUT should show the bits D0..D3 sequentially as CNT counts forward, but it shows a copy of CNT 1 with random noise!

Testing before repairing

I searched for a 74150 multiplexer. They are rare now, but I could get one from Conrad Electronics as easy as if I’d searched for a 7400. And as I waited for delivery, I got through Manfred’s 11/44 part box once again, and it struck me: There was another RL11 controller! I plugged it in, and with this one my RL02 run fine!

RL11 surgery

Finally I replaced the 74150 16:1 multiplexer.



On the left you see the old chip (“7923” means: made in 23th week of 1979), cut out. On the right you see the RL11 board, the new chip is in a socket now.

Now I had two working RL11 controller. I donated one back to C-C-G’s 11/34, where it was missing.

What I learned:

  • The “swap a bad part” approach fails, if you swap in a bad part too.
  • Sometimes you need a complete 2nd computer system to pick parts from.
  • If you have too much stuff, you may not know that you have the 2nd system already.
  • A logic analyzer does not analyze logic, it forces YOU to analyze it.