I have a few BA23 systems here. Among others, one is an 11/73, and the other is a MicroVAX I (I have a taste for minimalism). They each have RQDX3 cards in them to access MFM disks.
MFM disks...as the bosun said in GC Edmondsons's "The Ship That Sailed The Time Stream", regarding batteries, "They ain't diamonds" - meaning, they aren't forever. I've gone through a lot of RD54s, RD53s, RD32s and RD31s. The ones I have left that still work howl like banshees, running on their square dry bearings.
So they needed to be replaced, before I was left with what is usually my favorite thing...nothing. Enter David Gesswein's MFM disk emulators. These are great products. Quiet and dependable. I bought six of them and figured, I'd have the RD53/54s replaced in a day. One pair went into my PRO380 and worked great as two RD53s. The only wrinkle there is that you have to extend the power off/shutdown timing in their parameter settings, and power the PRO on twice, since the PRO disk controller doesn't give the emulators time to start up before deciding there's no disk present. But, the second time, it works great....and really quiets down the PRO.
The 11/73 and the MIcroVAX 1, different story. No fault of the emulator cards, though - I had a series of cascading failures. An RQDX3 failed in one of them, and two of my spares were also bad. A new drive cable I was using turned out to be bad. And, while plugging and unplugging the drive cables repeatedly, I managed to bend pins in two of the BA23's sockets. Those pins are soft as butter. As well. a couple of RD32s I was using to test with turned out to be bad. This made for a lot of linear combinaitons of parts that wouldn't work....and it got worse as the parts were swapped around between systems trying to test.
While these struggles were going on, I was using VMS and XXDP to test the results of the swapping around, looking for the faults. They each took a middlin' amount of time to test with. I wanted something that would give me a quick pass/fail sort of answer as to the health of the controler, cabling and hard drive or emulator.
A few blog posts back. I detailed how to talk MSCP to an RQDX3 in a downloadable image, for loading software via ethernet. It was the work of a moment to hack that program around to where it just issued MSCP commands to the RQDX3 and disk, sufficient to see if anybody was home. I won't bore you again with the details of how to do that - see the previous blog post if you're interested.
But, while trying to get the two systems running again, I became far more interested in working on this utility. With a little work, I realized I could make it into a useful tool for poking at MSCP controllers and disks, beyond just seeing if they were alive or dead. I added the ability to do several MSCP functions as well as testing for life. While doing that, I became curious about DUP. DUP stands for Diagnostic/Utility Protocol. It is mentioned in scant detail in the DEC doccos about MSCP. It is used to load and control diagnostic and utility programs in MSCP controllers - thus the name DUP. The doccos do spell out the format of messages used to request DUP functions - the format is essentiially the same as MSCP control message format - but none of them that I could find spelled out how to actually send these commands to DUP.
I finally puzzled out the answer. The command packet format is the same as MSCP (although with different opcodes and success status values) - but it turns out that the two words BEFORE the command packet determine which protocol is used. For example, here's part of a a typical MSCP command packet.
31 0
+-------------------------------+
| command reference number | 0
+---------------+---------------+
| reserved | unit number | 4
+---------------+-------+-------+
| modifiers | rsvd | opcode| 8
+---------------+-------+-------+
| unit flags | reserved | 12
+---------------+---------------+
| reserved | 16
+-------------------------------+
What nothing in the usual sorts of doccos tells you is that the two words previous to it determine who gets it. The packet is actually two words longer, with the top two words referenced as a negative offset from the start of the command packet. I finally found this little bit of info in a diagram in the MSCP patent application. Here's how it looks on a command packet.
31 0
+------+--------+---------------+
| Type | MT & CR| pktlen | -4
+---------------+----------_----+
| command reference number | 0
+---------------+---------------+
| reserved | unit number | 4
+---------------+-------+-------+
| modifiers | rsvd | opcode| 8
+---------------+-------+-------+
| unit flags | reserved | 12
+---------------+---------------+
| reserved | 16
+-------------------------------+
"Pktlen" is a word, and "Type" and "MT&CR" are bytes.If the packet length and the protocol type fields (pktlen and Type) are zero, then MSCP will handle the packet. If the packet length is correct for the opcode specified, as a DUP opcode, and the type field is 2, then DUP will handle it. By blind good luck, my previous MSCP programs worked just because by happy accident, the two words before the command packet just happened to be 0, so I got MSCP successfully.
The credits and msgtyp bytes are used for more complicated schemes involving simultaneously active IOs. They're always 0 for my usage.
Anyway, enough prattle about figuring out how to invoke DUP. Let's talk about this utility. The utility works like the disk installing software in a previous blog post, via DECnet MOP download. No software or OS required on the target machine.
