[Simh] Origins of MSCP

[Bob Supnik]

True. My first assignment at DEC was managing the "New Disk Subsystem" 
(NDS) advanced development project, which led eventually to both the 
HSC50 and the UDA50. Among the goals of the project were

1. To move ECC correction off the host and into the disk subsystem, so 
that much more powerful and complex ECC codes could be used.
2. To move bad block replacement off the host and into the disk subsystem.
3. To provide a uniform software interface for radically different disk 
drives.
4. To abstract away all device geometry information.
5. To implement command queuing and to perform all performance 
optimization, particularly seek optimization, in the disk subsystem.

 From my recollection, the Massbus was actually regarded as the 
counterexample. First, the Massbus cables were massive and unwieldy; the 
radial drive interconnect for the RA-class drives were a direct 
reaction. Second, the Massbus exposed drive geometries, which made it 
impossible to implement a new disk type without a driver update; with 
MSCP, the subsystem reported capacities, and the operating system could 
set up a file structure accordingly... sometimes.

What the two protocols had in common was standardizing the format of the 
software [register (Massbus) / packet (MSCP)] interface. All Massbus 
disks used the same register sets... except when they didn't (the RP/RM 
divergence). All MSCP disks used the same packet formats... except for 
errors. But it was a lot better than the "every disk is unique" 
nonsense. DG had a standardized disk interface from the get-go.

/Bob

On 6/25/2019 8:10 AM, simh-request at trailing-edge.com wrote:
> Message: 8
> Date: Tue, 25 Jun 2019 08:10:08 -0400
> From: Paul Koning<paulkoning at comcast.net>
> To: Timothe Litt<litt at ieee.org>
> Cc: SIMH<simh at trailing-edge.com>
> Subject: Re: [Simh] Limits on MSCP controllers
> Message-ID:<81262A49-F410-432C-8C00-4AA9AC585210 at comcast.net>
> Content-Type: text/plain;	charset=us-ascii
>
>
>
>> On Jun 24, 2019, at 5:27 PM, Timothe Litt<litt at ieee.org>  wrote:
>> As is often the case, things turn out to be complicated.  Here's a more detailed version.  In an off-list note, Bob pointed out that MSCP originated in a project he managed that was to develop the "next generation" disk controller - a forerunner of the UDA.   ...
>> However the similarities came to pass, I found viewing DSA as an evolved Massbus to be a useful model, with a lot of support for that perspective in the specifications.  MSCP contains the high-level protocol of Massbus drivers (and much more) through the drive control logic/formatter.  SI replaces the DCL/formatter to drive "bus" of Massbus -- SI is serial, ruggedized and capable of quite long runs.  But it carries much the same low level drive commands.  (Note that there's a long history of serializing parallel buses as technology evolves, e.g. PCI -> PCIe -> CSI, a.k.a. quickPath). The host ports (UQSSP,KLIPA,etc) replace the registers and DMA channels.  Command and function names from Massbus spec & drivers often appear in the MSCP spec versions that I used...
> Very interesting.  I never thought of MSCP as a descendant of earlier DEC storage architectures.  Perhaps because all I really saw was what the UDA50 exposes, which from the programmer's point of view is radically different from, say, the RP04 or RK05.
>
> On the host ports and message based I/O, that same approach appears earlier in the KMC11 and its derivatives such as the DMC11 network controller.  Were those an influence on the message based host port design?
>
> 	paul