🚀 go-pugleaf

in article <1988Dec7.095943.21876@gpu.utcs.toronto.edu>, anakin@gpu.utcs.toronto.edu (Anakin Research) says:
> Checksum: 21609

> Dave Haynie makes a valid comment about DMA. I put DMA support on the LUCAS 
> board and I have had one report of LUCAS working fine with a home-brew DMA 
> hard disk controller. I have no DMA devices an haven't properly tested this
> feature. Seeing as one report does not confirm that LUCAS supports DMA is 
> there anyone else out there who has a LUCAS board who can confirm or deny 
> this. I hope I have understood Dave's comments correctly, if I'm missing 
> something perhaps Dave will enlighten me.

There are actually two DMA-related issues.  The first of these is basically,
will the '020 card respond to a DMA request in a 68000 compatible way.  In
other words, will it grant bus mastership to a DMA card without causing any
problems.  While on the surface the 68000 and 68020 DMA mechanisms look the
same, there are some synchronization and timing issues that may have to be
addressed, depending on the board design.  All the commercial 68020 boards
are designed to allow DMA to occur.

The other question, and the one I was really commenting on, is the "can
a DMA device talk to my 32 bit memory".  This feature definitely complicates
the design of the memory board, in that it requires the memory be able to
act as both 32 bit wide memory (during CPU access) and 16 bit memory (during
DMA access).  Neither the CSA nor the Ronin board allow 16 bit DMA into
32 bit RAM; the A2620 does, but it most definitely made the A2620 RAM
design more complex.  My feelings on the autoconfig issue is that, if your
memory is in the 24 bit address space of the 68000 (as is all autoconfig
memory), it should allow 16 bit DMA.  CSA put their RAM outside of the
24 bit space, which I think is a good solution to the non-DMA memory.  This
lets you easily tell DMA device drivers which memory they can and can't
access.  Ronin allows their memory to show up in the autoconfig space
without allow DMA, and that makes configuration more complicated.  In fact,
their suggestion is to confine DMA to CHIP RAM, which is a definite 
performance hit.  While it's possible to do better than that, and as a
hacker project, the folks doing this will certainly be better informed on
system setup issues than the average street Amiga user, this is still 
something to consider.

>                                         Brad Fowles
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession