[Simh] Origins of MSCP

[Johnny Billquist]

Thanks for that insight, Bob.

I wasn't anywhere near DEC when this happened, but it do match my 
perceptions of the whole thing very well.

MSCP was definitely an improvement on Massbus in pretty much every way. 
Possibly with the exception of if you wanted to throw together some 
small piece of code to just control the drive. MSCP always requires a 
bit more plumbing.

But it is nice that I can still throw new drives onto my "old" RSX 
system, and with MSCP it just works, and I can use all the capacity of 
that new drive... Noone probably even dreamed of 8G drives on a PDP-11 
back then... But it works fine. No changes to anything needed.

   Johnny

On 2019-06-25 17:43, Bob Supnik wrote:
> 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
> 
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol