Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!imagen!atari!jwt
From: jwt@atari.UUCP (Jim Tittsler)
Newsgroups: comp.sys.atari.st
Subject: Re: Help with Hard Disk Interface
Message-ID: <897@atari.UUCP>
Date: Tue, 1-Dec-87 12:55:56 EST
Article-I.D.: atari.897
Posted: Tue Dec  1 12:55:56 1987
Date-Received: Sat, 5-Dec-87 12:37:33 EST
References: <1226@vaxb.calgary.UUCP>
Organization: Atari Corp., Sunnyvale, CA
Lines: 29
Summary: ACSI DMA Quanta

In article <1226@vaxb.calgary.UUCP>, crash@calgary.UUCP (Glen ) writes:

> In the developers docs it says "transfer data in 16 byte increment
> blocks" [ACSI Application Notes, page 11]. What happens after 16 bytes???

The DMA controller in the Atari ST series contains two 16 byte deep FIFOs.
(In the "programmer's model", this logically looks like a single 16 byte
deep FIFO.)  This FIFO provides some timing elasticity and also
improves performance by buffering byte transactions on the ACSI and
turning them into mulitple word transactions on the ST bus.  During the
course of a normal DMA transaction, the operation on the ACSI bus will
appear seamless (i.e. there will be nothing particularly special after each
16 bytes).

In DMA output mode (ST -> ACSI), the FIFO is transparent to the device.
When DMA is enabled the DMA chip will (immediately) fill its FIFO and
will feed the bytes to the ACSI device as it requests them.  Even if the
peripheral device requests fewer than (a multiple of) 16 bytes, the fact
that there are some bytes "leftover" in the FIFO is not a problem.

In DMA input mode (ACSI -> ST), the FIFO will wait until it has received 16
bytes before it requests the ST bus to actually write the bytes to RAM.
There is no way to force a partially full FIFO to be written to RAM, so the
peripheral should always generate a multiple of 16 bytes in order to make
certain the data gets written.  (Note:  It is possible to generate multiple
DMA ACSI transactions that add up to at least 16 bytes without resetting the
DMA chip to effectively pad the data to the next FIFO flush boundary.)

Jim Tittsler, Atari Corporation		{ames, portal}!atari!jwt