<The VS2000 manual states that
<- there's an 16K DMA buffer memory located at a fixed address
<- NCR5380 and HDC9224 read/write data from/to this buffer

<- the DMA counter is 14(?) bit, thus offsetting into this 16K 

I can see the possibility of the 9224 dma being truncated(it's 24bits)
and mapped to a specific space.  But it's not a general purpose DMA
and the closest it come to that is say copy from 5380 to 9224 or the 
reverse (tape to disk or disk to tape).  It's is not possible for the 
5380 to post a dma request to the 9224 for the purpose of 5280 to memory
DMA(or mem to 5380).

<- there's a set of operations which have to be done mutually exclusive,
<  since doing one might damage any other of these operations:
<	- accessing registers of NCR5380
<	- accessing registers of HDC9224

Independent devices at different adresses, seems unlikely that would be 
the case.

<	- read/write to the DMA buffer
<	- NCR doing DMA to/from the buffer

NCR using what DMA, the MV-II dma?

<	- HDC doing DMA to/from the buffer

Could be the shared 16k buffer space is the problem.  That is not a lot 
of space.  Also if the 9224s partner is used (9225 DBMU) it's dma counter 
is truncated to 15 bits.  It's possible that DEC mapped that logic into 
one of their gate array glue chips.  It is also possible to not use the
internal DMA logic as designed and fake in a different counter/adress 
register scheme in which case all bets are off.

<- thus not only it's impossible for each driver to check the state
<  of an DMA operation by reading the registers of NCR/HDC, but also
<  the two drivers have to be locked against each other, since accessing
<  registers of on controller will interrupt any pending DMA operation
<  of the other driver.

Sounds like bus contention and the fact that if you talk to those devices 
while they are actively doing transfers you can fake them into logging it
as a transfer(thereby upsetting the count).  The 5380 is programatically a
pain and the 9224 is a complex device and has some funny "you can do this 
but only when..." things about it.  Having used both independent of each 
other I have no love for either.  I also point out both offered more in 
40 pins that anything else for their time.

<Some models of 3100 have an 128K DMA buffer plus a 16K "compatibility"
<buffer. I don't know if this 16K buffer is used for/by HDC9224 on the
<SCSI/MFM daugtherboard. At least with the SCSI/SCSI option there no

Wish I had printset for the group.

<need to use the 16K buffer. DMA counters on 2000 and 3100/76 differ
<eg. in one using 1-complement and the other using 2-complement of the
<transfer size for initialization. Don't know about other models of 3100.

??? The dma in the 9224 is the same in any system(hard wired in the chip).
Could be that they are using an external DMA controller from the 9224

According to the SMC data book transfers for tape commands(not used) are 
ones comp for transfer length.  Floppy and hard disk commands transfer 
commands are number of sectors (multiples of 128/256/512/1024...) not 
numbers of bytes.

If they are doing their(DEC) own dma scheme it's likey that anything 
goes.  However the transfer length in the 9224 in either case will still
be number of sectors.  The external DMA will have to be initialized as 
some sets of values.  One clue is transfer length is 9224 register 6 and
dma address is Registers 0/1/2.  those register addresses are an index off 
the base device address.  It the DMA address or transfer length are not at 
those addresses it would indicate another DMA device(or logic) being used
and not the on chip system as expected.  

<SCSI drivers for the SCSI/SCSI option can be simpler than drivers for
<the SCSI/MFM option, since all dependencies are within on driver and
<don't cross "driver boundaries".

implmentation limitations not taken into account.  IT could complicate 
writing drivers as well.

Allison