Dear Bertram,
   
   You wrote:
> On KA410 the drivers for NCR and HDC use a shared 16K buffer for DMA
> (ie. data transfer).
   
   I hope everyone agrees with this by now.
   
> According to the KA410's manual
> - access to this buffer
> - access to the registers of NCR and/or HDC
> - NCR or HDC doing DMA operations
> have to be mutually exclusive.
   
   This is probably a miswording in the manual. It is very likely that
instead of one mutual exclusion, we have two or three independent ones. The
first mutual exclusion is between CPU, HDC, and NCR accessing the buffer.
The second one is between CPU accessing NCR's registers and NCR accessing
the buffer. The third one, which may not exist, is between CPU accessing
HDC's registers and HDC accessing the buffer. In any case I agree with
Allison that a mutual exclusion between CPU accessing HDC's registers and
CPU accessing NCR's registers is very unlikely.
   
> In vsbus.{h,c} there's implemented some quick-and-dirty software locking
> which is mainly used to block one driver from the other.
   
   and
   
> Since accessing the buffer has to be exclusive, I've decided that each
> driver uses the complete 16K, always starting at offset zero. It would
> have been possible to reserve lower 8K for one and upper 8K for the
> other, but I didn't see any real gains in that. Thus I've implemented
> that "brute-force" attempt which locks the complete buffer and blocks the
> other driver during the complete operation.
   
   I would imagine that this is what VMS and Ultrix do.
   
> BTW: From the docs I have it seems that HDC9224 is at the same address
>      for all VAXen, same holds for NCR-1 and NCR-2, for SCSI-DMA and for
>      interrupt-registers. Thus at least some parts of the existing
>      drivers should be usable for other models 3100...
   
   Sure they are! If the addresses were different, Ultrix would be broken
miserably.
   
> In "hdcmatch()" it would be fairly easy (IMHO) to add support for HDC9224
> on other VAXen [...]
   
   It surely is! The way the hdc driver checks for KA410 and refuses to
load if it's something else smells like (heaven forbid!) artificial
blocking... :-)
   
> What's also missing from the driver is bad-block-handling. This is mainly
> due to fact that my disk didn't have bad spots [...]
   
   This is the first time I see a good disk being a disadvantage. :-)
   
> PS: In the meantime I think it could have been better to have to
> different implementations for NCR-drivers, one for KA410 and one for
> KA43.
   
   In general this would be a bad idea, since the differences are really
minor and the vast majority of the 5380 control code is the same (it is not
even tied to DEC, NCR's chip is generic). However, in NetBSD's case this
code is already sequestered out into the MI portion, and the MD portion
deals mostly with DMA, so in this particular case using different MD
drivers may be OK.
   
   Some personal comments. Your description mostly coincides with what I
have discovered by studying your code, and both lead to the same
conclusion: the problems that these drivers are plagued by are a result of
the extremely quick-and-dirty way in which they have been written. Trial-
and-error and "I have no idea why this works" never lead to robust
software. To make sure that my work goes in the right direction, I won't
even start writing any code until I get a complete and perfect
understanding of the hardware involved. First I'll read all of the
available manuals, and then I'll fill in the missing pieces by reverse-
engineering Ultrix.
   
   But apparently you had at least some technical info. When you were
writing the hdc driver and the MD portion of the ncr driver, you had to
have the info on them. Had you got it all from the MV2000/VS2000 technical
manual? Did you use the datasheets from SMC and NCR?
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu