MSCP and DUP talking to RQDX3

  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.

$ mcr ncp set node negato load file dua0:[mvax1]mscp.exe

$ mcr ncp sho node negato char

Node Volatile Characteristics as of 18-SEP-2021 10:01:36

Remote node =   10.103 (NEGATO)

Hardware address         = 08-00-2B-26-2F-84

Load file                = DUA0:[MVAX1]MSCP.EXE

  Boot the MIcroVAX via network, and it should load mscp.exe

>>>B XQA0

ATTEMPTING BOOTSTRAP

                                  MSCP X02A02

                            Control-G Consultants

  You'll be prompted for the disk number. Then you get a "ribbon" of commands.

Enter disk unit number:

0

Enter command (HELP HALT INIT AVAI ONLI STAT READ WRIT CLEA HACK GETD DIRE)

 

Help - prints out a page of not particularly helpful information.

HALT - Halts the processor. Handy if you get scared, or if the control panel is not right next to you.

INIT - Initializes the RQDX3. Needed before any other command (except HELP) is used. If you don't, then it will hang.

AVAI - takes the disk offline, which makes it available to be put online again.

ONLI - takes the disk online

STAT - shows the state of things

READ - reads a block. Gotta go ONLINE first. It will prompt for a block number

WRIT  - writes a block...works like READ

CLEA - clears out the block buffer. The buffer is saved between read and write, so you could

"cut and paste" a block to another block. This clears it back out to zero, erasing anything you  previously read.

HACK - DUP command - Possibly the most interesting DUP command. This will load a block of PDP11 code into the MSCP controller and execute it as a task there. The PDP11 code is in the program between "ZAP:" and the definition of "ZAPLEN". The program included in the utility just bloinks the write protect lights. More research will show if anything useful can be run this way. It's necessary to go ONLINE before using HACK command.

GETD - DUP command - Get DUP status

DIRE - DUP command = This executes a local command called DIRECT, which will return a list of programs present on the controller. Does nothing useful here, since RQDX3's have no built in programs. But, on other MSCP cards, who knows? As is, it serves as an example of how to execute an MSCP controller built in program.

MSCP.MAR

  I should mention...this is a utility that speaks directly to the disk controller, using poorly documented and unsupported features....a disk could get hurt if things go wrong, so if you use it on a machine with good data on the disks, make sure you have a backup before ...experimenting. Don't come crying to me if you manage to erase a disk or blow the format off of it....