Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!gem.mps.ohio-state.edu!apple!voder!dtg.nsc.com!waggoner
From: waggoner@dtg.nsc.com (Mark Waggoner)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Bus Latency
Summary: Questions about how DMA in the Amiga works and how chip memory access
	 affects time to acquire the bus.
Keywords: bus dma latency
Message-ID: <329@berlioz.nsc.com>
Date: 18 Nov 89 06:36:04 GMT
References: <322@blenheim.nsc.com> <128061@sun.Eng.Sun.COM>
Organization: National Semiconductor, Santa Clara
Lines: 88


Combining some threads:

Chuck McManis writes:
> waggoner@dtg.nsc.com (Mark Waggoner (me)) writes:
> > ... The recent postings about dma vs. non-dma disk controllers mention 
> > that dma can be locked out for a long time when an overscan screen is 
> > being displayed, but how long is "a long time?"
> 
> Given a 704 X 440 screen with some sprites, audio, copper and blitter 
> activity I'm pretty sure it is possible to lock out DMA for one full frame, 
> 14mS at 60Hz. 
>    Frame time = 16.6 mS but chip activity is concentrated during
>    the (220lines/frame)/(60 frames/second * 262.5 max lines/frame)
>    which equals 13.9 mS. 
> 
> That would be slightly longer for PAL systems. 


> in article <1989Nov16.185706.29328@sjsumcs.sjsu.edu>, 33014-18@sjsumcs.sjsu.edu (Eduardo Horvath) says:
> 
> >     Can you DMA directly into FAST RAM, 
> 
> Yes.  In fact, it's greatly preferred and recommended.
> 
> >     If a controller DMA'd into FAST RAM, wouldn't that solve the problem 
> > of contention with the custom chips?
> 
> It can solve most of the problem.  There are two components to the DMA transfer.
> DMA to Fast memory will solve the second, which is the basic transfer rate for 
> whatever block size the controller transfers in one chunk.  The first problem is
> what I call "DMA lag", or how long it takes from the time your controller asks
> for the bus to when it actually gets the bus.  In order to acquire the bus, the
> CPU bus be finished with a bus cycle.  If the CPU is in wait states, waiting for
> access to the chip bus, the DMA controller will have to wait for the CPU to
> finish it's cycle, (eg, wait for the chip bus to be free), before it can take
> over the bus.  DMA controllers often transfer a whole block (512 bytes) in
> several DMA passes, so it's actually possible to incur this lag several times for
> each block, if your CPU is doing lots of stuff with video memory.  Also, if you
> have an autoboot controller of any kind that copies it's code to RAM before 
> using it, you get slowdowns if your autoboot card is the first one in the machine,
> since that code will get copied into chip memory.  So, unless you know your code
> is running from ROM, or you have something like an A2620/A2630 that puts autoconfig
> RAM in before your device is configured, it's best to put a memory card in before
> your device.  Hopefully all-in-one memory/disk cards autoconfig the memory before
> the disk.
> 


I am not sure I understand all of this.  Some questions:
(Perhaps I should RTFM)

  1. Can the CPU be locked out of chip memory for long periods of
     time?  I thought it alternated cycles with the video dma.

     If it DOES alternate cycles, it should be able to complete any
     operation within a few cycles.  Then, the amount of video dma
     shouldn't affect the latency in acquiring the bus by more than a
     couple of bus cycles.  
     
     If it DOES NOT alternate cycles and can be locked out of chip memory,
     then "fast" memory is indeed fast only in that you can perform your
     dma bursts faster.
    
  2. When a peripheral is dma'ing to/from chip memory, what
     restrictions are placed on it in terms of burst size.  Can it use
     consecutive cycles?  How is this handled?

  3. 14 mS of latency is a VERY long time.  Doesn't this mean that
     almost any peripheral will have to have local buffer ram?  Take
     Ethernet, for example (something I can talk about without getting
     too confused).  In 14ms, you could receive
       14mS / (800nS/byte) = 17500 bytes of data.
     Of course, this is neglecting the fact that you shouldn't get packets 
     that big and packets can't come back to back.  But still, there is no
     way you could ever count on getting hold of the system bus in time to
     buffer a packet unless you had either a FIFO or local memory big 
     enough to hold at least 20K.  This makes peripherals much more 
     expensive.  Could you even transfer 20K over to the system memory
     in the time between video frames?  (OK, so you aren't likely to
     get a burst of packets like that, but it IS possible).

Any clarifications would be appreciated.

-- 
 ,------------------------------------------------------------------.
|  Mark Waggoner   (408) 721-6306           waggoner@dtg.nsc.com     |
 `------------------------------------------------------------------'