Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!usc!rutgers!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Bus Latency
Message-ID: <8652@cbmvax.UUCP>
Date: 20 Nov 89 18:57:45 GMT
References: <329@berlioz.nsc.com>
Organization: Commodore Technology, West Chester, PA
Lines: 64

in article <329@berlioz.nsc.com>, waggoner@dtg.nsc.com (Mark Waggoner) says:
> Keywords: bus dma latency
> 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.

It depends on what you've told the video chips to do.  With some video
resolutions, there's no video fetch contention ever.  With others, the
CPU must be locked out for as long as video is being fetched.  It's
possible to set up the blitter such that it uses every available cycle
to complete it's work (so called "blitter-nasty" mode), but typically
blitter activity can use free time on the video bus without getting in
the CPU's way.  Other video bus activity, like floppy DMA, sprite
fetches, Copper programs, audio fetches, etc. can cut down on the
available time granted the CPU.  Most of the time they don't cut into
the CPU time at all, but if you push things hard enough, they can.

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

Fast memory is called "fast" exactly because it is never locked by the 
Amiga chips.  It isn't any faster, on a per-cycle basis, than chip memory,
but the CPU always has access to it.

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

It's a good idea for any peripheral to have local buffer RAM or FIFO
in any case, just because you don't want a device to interrupt the 
CPU just to grab a single word, and you don't want a DMA device to
take over the bus just to dump one word into memory.  The amount of 
FIFO depends on the device.  If you're dealing with something that
has it's own local buffer, like a SCSI device, the controller's FIFO
can be only a few words long (the 2090 FIFO is 32 words, the 2091
FIFO dis 16 words).

>      This makes peripherals much more expensive.  

Certainly a little more expensive.  But it adds performance in any
case.

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

With fast memory and DMA, you only need one cycle to chip memory, at
worst, to get unrestricted access to fast memory at full bus speeds.
With CPU driven I/O, you'll need a few cycles, since interrupt
vectors are currently stored in chip memory, but it's not that bad.
Some devices may not work at acceptible rates with hires 4 plane
overscan screens if you only have chip memory.  With a little fast
memory, there's not a big problem.	

> Any clarifications would be appreciated.

> |  Mark Waggoner   (408) 721-6306           waggoner@dtg.nsc.com     |

-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough