> I'm going to have to disagree with you a bit here. The DSSI bus is a 
> separate bus just as the SCSI bus is a separate bus. Consider for a moment 
> that existing SCSI disks on the VS3100 series appear as "sd0 ... sdn" and 
> "attach" to scsibus0, scsibus1, etc. MSCP disks on the other hand attach to 
> the mscpbus and are labels ra0, ra1, etc. Now there are DSSI disks that 
> connect to the MSCP bus using the KFQSA, but that is no different than SCSI 
> disks that attach to the MSCP bus through a SCSI to MSCP adapter.

MSCP is not a bus, it is a networking protocol. MSCP can be spoken over 
many buses: Qbus, Massbus, XMI, Unibus, CI, BI, and so on. DSSI only 
resembles SCSI electrically and in the mechanical specification: logically
it is totally different. The DSSI protocol is a subset of CI. Like i said 
beofre, this is why DSSI in the later-model machines is done with SHAC, 
which is the ci-adapter-on-a-chip chip. 

> 
> So as an I/O bus, the DSSI bus on the KA640 is a separate bus just like 
> SCSI, therefore I plan to treat it like SCSI and give it its own config 
> lines. (think along the lines of:

But the DSSI is a CI bus. do a straight CI support and DSSI as one of the 
things that goes over it. DSSI itself is just using some of the 
facilities of the CI protocol. CI adapters are nexi themselves, like any 
other kind of bus adapter. so you should have:

ci0 at nexus
hsc? at ci0 
ra? at hsc? 

since the logic in a DSSI disk acts like an HSC. you could differentiate
between a 'real' HSC and a faked on in the DSSI device's logic, perhaps
by doing
dssi? at ci0 
ra? at dssi? 
or by even covering the abstraction with some glue and doing 
ra? at ci? 
but thats not exactly kosher.. 
DSSI is CI, plain and simple. CI is a complex protocol, which is why 
support for it is not going to be very simple! 

> 
> dssibus*   at sii?
> dd*        at dssibus? target?
> dt*        at dssibus? target?
> 
> For now I've added a KA640 CPU type that will control the enabling of this 
> code.
> 
> Now, as for your assertion that DSSI protocol is a subset of CI, I can't 
> say that I know enough to understand that statement as made. The KA640 does 

Read the Ultrix sources. If you want access to the ultrix sources, lemme 
know, i keep them online. 

> _not_ use the SHAC chip like the KA660 and KA670 does, instead it uses 
> something called the SII chip in the docs. (the KA670 docs call the SHAC 

SII is a programmable chip, there is other stuff elsewhere which 
configures it as what it needs to be: it handles all the elctrical 
interface, though, which is why it is used for SCSI as well as DSSI in 
some systems. 

> chip the SHAC chip.:-) And in the KA670 docs the SHAC chip is identified as 
> being able to operate both a CI bus _and_ a DSSI bus, although they aren't 
> shown or discussed as proper (or even improper) subsets of each other.

this is because DSSI is essentially just some set of the features of CI. 
It's a full CI bus, just that if you only use the DSSI features, many 
folks called it a 'dssi bus'. Clustering was done through the DSSI channel
just like any other CI, except that there's no star coupler in the 
middle. 

> 
> Further, while the KFQSA appears to treat each DSSI disk as a single 
> virtual controller, the SII chip on the KA640 is more like SCSI that can 
> talk to several targets through a single controller.

the sii does more in software and fudges some things to get it all right. 
the sii is way lower performance than the SHAC, which can halde the full 
70 mbit/sec bus. 

> 
> And this statement
>  > In any case the language spoken over this CI is MSCP.
> 
> Is fairly bold and spicy but I can't find any indication that it is true in 
> either manual. Both refer to DSSI as having its own set of opcodes with 
> targets, arbitration phases, data phases and such like, (very SCSI like) 
> and neither mention anything or reference MSCP anywhere (except in the 
> discussion of Q-bus peripherals)
> 
> I guess what I'm saying is that I don't intend any disrespect but I can't 
> reconcile these statements with the documentation. There must be something 
> I'm missing here.

Contact me off-list in private email and i'll give you an account on my 
system, where I keep Ultrix 4.2 sources. There's a hierarchy that is so 
simple it is beautiful, which really shows how well DEC thought the whole 
VAX architecture out, including how the hardware and software are so 
closely intermingled and symbiotically interdependent. There are a few 
generic protocols that bind a VAX together: the means of clustering them 
are just an extension of the same theme, all following from the concept 
of the equals-among-peers nexi at the very core of a system. Nexi all 
exchange information purely through manipulation of memory directly (an 
indicator of how memory-centric the VAX architecture is) and all things 
in the end go through a nexus. Processors, memory, bus adapters, these 
things are nexi. Sometimes other things are nexi, too. All XMI devices are,
for example. SGEC and sHAC are. There is a lot of overhead in this, since 
these devices can only communicated via paged virtual-addressed 
scatter-gather DMA. Lots of silicon needed, but it is very high 
performance. On smaller VAXen, the only nexi you might see , say in a 
microVAX, are the processor and a Qbus adaptor. (and of course memory 
controller) Bigger VAXen, like 780s or 750s or the BI&XMI machines, there 
are more nexi. The SBI on a 750 is a nexus interconnect, for example. 
Anyway, from a nexus there flows the core of interconnection and moving 
of information. CI adapters are nexi. they then have a protocol called 
GVP which runs over them, and everything is within this protocol. CI 
itself lives within it. GVP is an abstraction to thenexus interconnect to 
try to make the nexus scheme more easily used in operating system code, 
since communicating with a nexus is a very complicated thing. 
MSCP and so on are all things which live within these layers of protocol. 
In some cases more of this work is done by hardware than in other cases. 
In the case of a DSSI disk attached to an XMI DSSI (CI) adapter, it is 
_all_ done by hardware, you have an example of the entire protcol from 
bottom to top implemented in hardware all the way down to the DSSI/CI 
adapter, which is a nexus, manipulating page tables and modifying memory. 
(yes, nexi manipulate page tables themselves. this is one of the reasons 
that 25 to 30% of _every_ XMI board is dedicated to the 'XMI corner' 
interface logic which includes a microVAX processor to handle the work!)

isildur