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