bobp@amiga.UUCP (Robert S. Pariseau) (11/03/85)
This is a (slightly updated) copy of a message I posted on BIX a while back. -------------------- The 68000 CPU used in the Amiga has about a 50% duty cycle. By that I mean that it spends about half its time on the memory bus and the other half doing internal processing. The quoted clock figures for the Amiga are stated with respect to the CPU. In fact, the Amiga uses an internal clock with twice that speed (yielding ~14.4MHz). The custom chips do 16 bit transfers in one of those cycles. That means that the custom chips can do one heck of a lot of transfers in the "off" cycles where the 68000 is twiddling its thumbs internally. The bus arbitration is handled, again, within the custom chips. Each of the 25DMA channels has its own slots in the timing which let it get its work done without interfering with the 68000. What all this boils down to is that you can have a 320x400x4 display with 4 audio channels going, the disk going, the sprites going, and the 68000 going all at the same time. The 68000 will see NO CONTENTION! NONE! It doesn't even think those DMA channels are on the bus! The blitter is a cycle stealing device. It will use whatever cycles are not taken up by the other DMA channels and it will use the cycles normally reserved for the CPU. In normal blitter operation, it is set up to yield whenever the CPU tries to access memory on that bus. This means that the CPU can get in to process interrupts (for instance) even if the blitter is in the midst of a large transfer. The upshot is that blitter ops happen as fast as the memory can go, with 16 bit transfers continuously going at twice the memory bandwidth of the 68000 not even including any 68000 processing time that would be involved if you used it instead of the blitter. This is why the machine really screams for blitter supported operations such as area-move, area-fill, and line draw. The display coprocessor is also a cycle stealing device. It allows raster-beam synchronized control of ALL the custom chip functions of the machine WITHOUT requiring the 68000 to take the time to perform an interrupt context switch. This is why we've got enough horsepower to slide screens around in real time while animation and graphics rendering is going on in the screens. It is possible to set up the display such that the 68000 sees contention. The worst case is a four plane high-res image, where the video bandwidth blocks the 68000 except during horizontal and vertical blanking intervals. Note however that the 68000 can only see contention on the internal RAM. Never on the Writeable Control Store RAM or on ANY external RAM (this is why the external RAM is referred to as "fast" RAM). You can avoid contention by going to fewer bit planes -- for instance Workbench and the CLI use two planes of high-res yielding no (that's 0!) contention -- or by reducing the vertical size of your image such as by using the Intuition screens to make most of your display be at some other resolution. Note that Interlace is not an issue here. Yes there is twice as much data to display, but remember that the machine takes 2 frames to display it. The next rev of the hardware manual will include detailed info on the DMA priority and time-slot allocations for all you guys who want to run right at the edge. The only (charitable) explanation I can come up with for someone to say that the Amiga custom chips slow down the 68000 by 70% in normal operation is that someone misread the DMA allocation chart showing the allocation of DMA channels to the off cycles and assumed that the 68000 was in fact capable of using those cycles. An 8MHz 68000 can't. Anybody got a 16MHz 68000 they'd like to loan me?