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-requ...@trailing-edge.com wrote:
Message: 8
Date: Tue, 25 Jun 2019 08:10:08 -0400
From: Paul Koning<paulkon...@comcast.net>
To: Timothe Litt<l...@ieee.org>
Cc: SIMH<simh@trailing-edge.com>
Subject: Re: [Simh] Limits on MSCP controllers
Message-ID:<81262a49-f410-432c-8c00-4aa9ac585...@comcast.net>
Content-Type: text/plain; charset=us-ascii
On Jun 24, 2019, at 5:27 PM, Timothe Litt<l...@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
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
