Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!udel!rochester!kodak!uupsi!grebyn!ckp
From: ckp@grebyn.com (Checkpoint Technologies)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: ALSO seeking DMA peripheral controller example!
Message-ID: <1991Apr6.144654.10699@grebyn.com>
Date: 6 Apr 91 14:46:54 GMT
References: <1991Apr5.110637.1@happy.colorado.edu>
Organization: Grebyn Timesharing
Lines: 23

In article <1991Apr5.110637.1@happy.colorado.edu> kskelm@happy.colorado.edu writes:
>     It seems like I read somewhere in the docs that one should NOT take
>over the bus [for any length of time?].  If I built a card with a DMA
>controller, can I be certain that I am not goofing up, say, some OTHER device
>(like a HD) by taking the bus over for, say, (worst case) 128,000 cycles (a
>large RAM transfer)?

"Should not" is really in the light of being a good neighbor.  There's
nothing in the Amiga system that I've seen that gets hurt if you keep
the bus permanently, except that no further work gets done.  You can't
take over the chip bus, that's always owned by the custom chips, your
DMA device only steals some cycles.  There are no refresh cycles for DRAM
sent out on the bus, DRAM cards must generate their own, so they're OK.
Most DMA hard drive adapters (significant exception: A2090A) must
tolerate being unable to get on the bus for LONG periods, because of the
chip RAM contention thing.  And the motherboard has no logic for timing
out a takeover and throwing you off (this might have changed for the A3000,
I'm not sure).
-- 
First comes the logo: C H E C K P O I N T  T E C H N O L O G I E S      / /  
                                                ckp@grebyn.com      \\ / /    
Then, the disclaimer:  All expressed opinions are, indeed, opinions. \  / o
Now for the witty part:    I'm pink, therefore, I'm spam!             \/