• Please review our updated Terms and Rules here

Documentation for DEC DUP protocol as used by DEC diagnostics such as XXDP on RQDX3

Oldcoder

Member
Joined
Feb 28, 2021
Messages
49
Some MSCP Controllers (eg RQDX3) also support DUP for diagnostics.

The RQDX3 Controller User Guide mentions 2 DUP functions:

Execute local program - runs a program stored in ROM.
Execute supplied program - loads a program into RAM and starts executing it.

In the glossary of supported commands but alas provides no further details.

Does anyone know where DUP is documented?

Thanks

Peter
 
DUP is a protocol that DEC never seem to have released any information about. Sadly... Also, if it comes to executing downloaded programs, then there was no standard for how those downloaded programs would look like, or target. For example, DSSI with any RF disk, you can use DUP to connect to the disk itself and talk interactively with it, run a directory utility to list which diagnostics are available on the disk, and run any of them. Exactly what platform RF disks were running I don't know, but I'm pretty sure it wasn't any PDP-11. Same thing with HSC controllers over CI. With the SDI controllers (such as UDA50, KDA50 and so on), I don't think there were as much functionality over DUP, but DUP was still used for bad block replacement as well as for formatting the disks. And these controllers were based on AMD2901 bitslice and logic that made up the system.
I'm sortof impressed (surprised) to hear that the RQDX3 even had the ability to download anything and run. But you are still stuck in that even if you find the full specification of DUP, you still also need the full information about the RQDX3 environment if you were to ever write any software for it.

Bascially, this is pretty much a dead end. Noone managed to do it in the last 30 years. Information required are now most likely not even available in any archives inside of what remains of DEC.
 
bqt,

Many thanks for all your input. I had unearthed a reference to the UDA50 Programmer's Documentation kit but not found it. Thanks I'll give it a read.

Peter
 
Note that the UDA50 programmers documentation kit have several things in there, and even so it's probably not complete.

The basic disc handling have several subsections deleted. Basically everything related to bad block handling for example, is not in. DUP is in a separate manual, that was uploaded much later than the basic stuff.
And of course, this is all dealing with things at the MSCP and DUP level, and don't even go into any information about the internals of the UDA50, which you would need if you planned to write your own application for that controller.

And you are trying to do something very different than what DUP is there for. You want to hook into the MSCP functionality to serve a different type of disk on the floppy port. I should remind you that the MSCP server is still running, so you cannot just take over that piece. Also, those processes are owning the floppy port and controller, which you need to stop them doing if you plan to use that port. And then, of course, you need to have your application interact with the whole MSCP system. Not to mention that any OS still would probably be rather confused if presented with something like an RX01 on an MSCP controller, because that didn't exist.

And I don't even know if the system will properly serve MSCP fully while DUP is running something.

And finally, this documentation deals with the UDA50. As soon as you look under the hood, the RQDX3 is a completely different controller.
 
And finally, this documentation deals with the UDA50. As soon as you look under the hood, the RQDX3 is a completely different controller.
Yup. In particular, the Q-bus MSCP controllers used host-initiated bad block replacement, while the Unibus ones (and HSC, and presumably BI, etc.) use controller-initiated BBR. That's the reason RQDXn support wasn't simply a matter of taking the UDA50 driver and making it work in a 22-bit address space.

Reading the source listings for the MSCP driver in the various PDP-11 operating systems might be somewhat informative (as I recall, the RSTS port driver had a bunch of comments like "Is this an RDRX?") but likely won't provide enough information.
 
Back
Top