Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!rochester!kodak!sisd!jeh
From: jeh@sisd.kodak.com (Ed Hanway)
Newsgroups: comp.sys.amiga.hardware
Subject: DMA Controllers (was Re:   GVP Trade-in)
Message-ID: <1990Aug30.195419.25644@sisd.kodak.com>
Date: 30 Aug 90 19:54:19 GMT
References: <1898@lpami.wimsey.bc.ca> <02102.123056@thiger.UUCP>
Sender: news@sisd.kodak.com
Organization: Printer Products Division Eastman Kodak
Lines: 23

In article <02102.123056@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes:
>DMA (other than bitmap) runs into heavy troubles sometimes during
>overscan-graphics (e.g.)
[...]
>i have seen no dma-controller yet, that didn't have problems.
[...]
>amigamem troughput brings the thing down to some 100 kBytes (a typical

Well then I guess that you've never seen a HardFrame. Using the Diskspeed
benchmark with DMA contention turned on, my disk transfer speeds slow from
about 800k/sec to about 650k/sec, which seems completely reasonable to me.
I don't know where you get the idea that 100k/sec is a typical bottleneck.

My question to all the DMA opponents is this: given that 4 bitplane hires
overscanned screen DMA does eat up most of the chip memory bandwidth, why
should processor-controlled I/O be any better than DMA at using the remaining
bandwidth?  It seems that you would always want to make the most efficient
use of those precious open bus cycles, and DMA will always be more efficient
than programmed I/O, although a 68030 tight loop might approach DMA
efficiency.

Ed Hanway
uunet!sisd!jeh