Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!cbmehq!cbmger!danube!thiger!skraw
From: skraw@thiger.UUCP (Stephan von Krawczynski)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: DMA Controllers (was Re:   GVP Trade-in)
Message-ID: <02243.130825@thiger.UUCP>
Date: 23 Aug 90 16:38:25 GMT
References: <1898@lpami.wimsey.bc.ca> <02102.123056@thiger.UUCP> <1990Aug30.195419.25644@sisd.kodak.com>
Organization: THIndustries Software Development
Lines: 39

>In article <1990Aug30.195419.25644@sisd.kodak.com> jeh@sisd.kodak.com (Ed Hanway) writes:
>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.

i said "some 100 kBytes", some meaning several (= more than 1).

>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?

i don't know, i just give it a try, and it comes out better.

>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.

have you cross-checked this with several controllers?

>Ed Hanway
>uunet!sisd!jeh

--
best regards, 
stephan von krawczynski 

UUCP : ...!cbmvax!cbmehq!cbmger!danube!thiger!skraw
PHONE: +49 9938 1664
FAX  : +49 9938 1598