🚀 go-pugleaf

In article <8911150430.AA24506@jade.berkeley.edu> GORRIEDE@UREGINA1.BITNET (Dennis Robert Gorrie) writes:
>
>I know this has been discussed alot already, but its still not completely
>clear to me.  I would appreciate any information regarding this subject.
>
>   [The Universal Question (condensed): Which is faster, DMA or non-DMA? Why?]

	All this talk of DMA vs non-DMA *has* to be because of the
Commodore A2090(A) disk controller, which is a DMA device that performs
poorly under high-chip-RAM-contention situations. So it brought DMA into
a bad light.

	First of all, "contention" is when two or more devices want to
use the same bus at the same time. Only one device at a time may use a
given bus, so when several want it, somebody has to wait. Every Amiga
has about 26 devices which want the chip RAM bus; 25 of them are in the
custom chips, amd one is the 68000.

	There are many ways in which contention can be resolved, and all
of them involve choosing one device which "wins" the bus. In the Amiga,
there are assigned priorities to chip RAM, and the device with the
highest priority wins. First comes the carefully-programmed cycles which
are never contended (bit plane, DRAM refresh, audio, sprites, floppy
disk), then comes the Copper, then the Blitter. The 68000 is last, it
only gets the chip RAM bus when the custom chips don't want it.

	Now, when you plug in a card which performs DMA, it takes it's
place in the priority scheme. In fact, bus cards will win over the
CPU, but will lose to the custom chips. This is only for the chip RAM
bus, however; when contending for fast RAM, a DMA device will always win
over the CPU which is the only other contender (unless there are other
DMA devices; then Busteer picks a winner based on slot number I think).

	There are times when the custom chips want the chip RAM bus a
LOT; high res overscanned 4 bit plane with the Blitter and Copper
running, for example, in which case you may not win the bus for a WHOLE
FRAME, which is about a hundredth of a second. That's a LONG TIME. If
your DMA device is a disk, then the data comes off the disk at the rate
that the disk is spinning. The disk will *not* stop and wait for the bus
to become available. So the DMA device has to be able to do something
else with the data.

	The A2090(A) has a 64 byte FIFO, which is a place to hold 64
bytes of a transfer while waiting for the bus. This is good, but not
good enough, since a whole sector is 512 bytes; at the speed of an ST506
disk, 512 bytes will arrive in less than a thousandth of a second. So
the A2090(A) will *lose* that sector. The device driver is smart enough
to try again, after the disk revolves around again, but this takes
another 60th of a second. This is the real reason that the A2090(A) will
run soooo slooooow when in a bad situation like this.

	Now, a properly designed DMA device will be able to handle the
situation where it can't get the bus for a LONG time, and to do this
it'll have a FIFO big enough to handle at least one sector (512 bytes).
More FIFO is better. When it does win the bus, it can then transfer
everything into RAM quickly (DMA's forte is fast transfers). The
Microbotics HardFrame disk controller is designed this way; therefore it
is the fastest available Amiga hard disk controller, and does not have
problems with chip RAM contention.

	Another note: SCSI disk drives have FIFOs built into them, big
enough for a sector. This is good enough to handle the problems of DMA
contention. Commodore's new A2091 DMA controller actually has a
*smaller* FIFO than the A2090(A), and they depend on the SCSI
disk drive's FIFO to keep them out of trouble. There are "handshaking"
wires on a SCSI connector that lets the computer tell the SCSI disk
drive how fast it can accept data from the disk drive. Why then does the
A2090(A) have contention problems with SCSI disk drives, just like it
has with ST506 drives? Because they botched the A2090's SCSI adapter. It
doesn't properly use the available handshaking to slow the SCSI disk
drive down when it's FIFO fills. They have fixed this on the A2091, and
so they don't need such a large FIFO. (Incidentally, the A2091 doesn't
have an ST506 controller.)

	On non-DMA controllers: These devices (like the GVP controller)
move disk drive data to a built-in RAM chip first. Since this movement
does not need the Amiga's bus at all, and so are never affected by the
chip RAM bus. When the built-in RAM is filled, the 68000 CPU copies
that RAM to the place in system RAM where the data's really needed.

	Now, with this design, the contention problem is solved.
However, it's using your CPU to move the data, and while it's doing that,
it's *not* running your applications. So you may get acceptable IO
performance, but your Amiga's CPU is being penalized. I dislike this,
personally; I think it goes against the Amiga's high-performance IO
philosophies.
 
	Well, I hope this helps everyone in their understanding of the
Amiga and DMA. To sum up: the A2090(A) has given DMA a bad name, which
it does not deserve. The A2090(A) deserves the bad name; DMA is still
the fastest possible way to perform IO, even on the Amiga.