> Date: Fri, 22 Nov 2002 18:08:12 -0500
> From: "Charles H. Dickman" <chd_1@nktelco.net>
> To: port-vax@netbsd.org
> Subject: Re: NetBSD/vax QBUS IDE?!
> 
> der Mouse wrote:
> 
> >>The proper way is to design a Q-bus IDE controller which speaks
> >>MSCP/UQSSP.
> >>    
> >>
> >
> >For what value of "proper"?  I feel confident I could (upon digging up
> >Qbus and IDE documents) design a dumb IDE interface, like the one chd
> >built.  I do not feel competent to design anything that speaks MSCP
> >without some onboard CPU, which would, I would estimate, at least
> >double the chip cost and greatly increase the hair involved.  Even
> >then, I'd need MSCP documentation, and I have no idea where to find
> >that.  (I don't know where to find Qbus and IDE specs, either, but them
> >I've seen and thus I'm confident they exist.  MSCP docs could be made
> >of unobtanium for all I know, and given DEC's aversion to publicly
> >documenting its hardware protocols very well may be.)
> >  
> >
> I agree. I would rather have an interface in hand than a discussion of
> what would be better that came to nothing. Talk about IDE/QBus adapters
> has been ongoing for at least 3 years. It usually progresses like this:
>
> "Gee, an IDE drive on my VAX/PDP-11 would be cool because my RD53
> just siezed."

> "An IDE/QBus adapter would be trivial. I could do one next weekend,
> if I had the time."

> "But then there would be no driver compatibility. If it was MSCP then
> it would work for everybody, on all platforms, and all OS's."

> Silence......

> Somewhere in the middle, disparaging remarks are made about how bad
> IDE is as a disk I/O standard.

> I am not trying to be flippant, but each time this is discussed,
> the proposition of the ideal is used to stamp out the practical,
> and then nothing happens.

> The interface that I designed was purely for my own education. It has
> some definite limitations. For use with my PDP-11, these limitations
> were acceptable.

> In the last year, though, the possibility of an MSCP based disk
> controller has been vastly increased by the existance of an RQDXn
> simulation in the computer simulator written by Mr. Supnik. The fact
> that it is able to fool the PDP-11 OS's, NetBSD, and VMS indicates
> that it is a reliable prototype for implemenation. But, as has been
> suggested, this would require a much more complex interface, including
> a processor.

> Even more critical issues exist beyond the character of the controller.
> QBus interface chips for the most part are obsolete. National still
> makes some devices, but these are very expensive. There are always
> discrete transistors, I guess......

1) the generic DEC design for a Qbus interface can be gleaned out
of the chipkit users manual, which is scanned and online at
< http://www.brouhaha.com/~eric/retrocomputing/dec/doc/chipkit.pdf >

Extension to more than 16 bits of address is found somewhere in the
MicroNotes, for which I don't immediately have a URL.

2)  You don't have to duplicate the original interface chips, just
their functionality.  A quick look at a current catalog shows the
TI 74LVT logic series.  It looks to me like this satisfies both the
bus receiver and bus driver specifications of the original TTL parts.
Except I can't tell from a one-line description whether open-collector
(or whatever is the CMOS equivalent) is available.

Some more catalog scanning makes me believe that any of the logic
families with CMOS inputs will satisfy the bus receiver requirement
for low current drain, and the Schmitt trigger units will have the
hysteresis for noise rejection.

It's been too many years since I was designing Qbus interface circuits,
but I'll toss this in anyways.

    carl
-- 
    carl lowenstein         marine physical lab     u.c. san diego
                                                 clowenst@ucsd.edu