[bloodline]

Originally Posted by remz

You all are extremely helpful
So if I attempt to recap, please inform me if my statements are correct:
Assuming a stock Amiga 500 with 512KB chip ram, running a lowres screen in 6bpp, NTSC or PAL doesn't matter, with interrupt disabled:
Excluding the short DMAs like disk, audio, ram refresh, for the sake of simplicity:
- During VBlank, even and odd cycles are free:
One possible usage to maximize the DMA usage could be having Copper using Even cycles, while CPU can run at full speed on the Odd cycles.

The Copper doing what though? All it can do is load chip registers. Which is useful for setting up the display in the VBlank, as you say without interfering with the CPU. But other than that the Copper doesn't have much use during a VBlank.

Another possible usage could be using Blitter, which can run at full speed using all cycles, with an option (blithog) to let CPU run once every 3 DMA: Such setting is the 'best pipelining' achievable since CPU spends half its clock cycles on DMA, and the other half on internal instruction execution: it means that CPU borrowing 1 DMA cycle every 3 cycles will slow down the blitter slightly, but essentially yields more effective 'work per clock'.

So this is a really useful feature of the odd/even memory interleaving. Both the CPU and Blitter can perform operations at the same time, but with interrupts disabled the Blitter can only do a single operation... Maybe you could time the Blitter and use the Copper to set up the blitter at specific scanlines and perform a regular set of copies (not sure how useful that would be).

- During horizontal blank: Copper can be used on Even cycles at full speed to setup sprites and stuff, and CPU and/or blitter can also use the Odd Cycles to do a bit of work

With no active disk or audio DMA, I guess the copper could do some colour palette/sprite set up, but you don't have many DMA slots before the sprites need their fetch slots. This is all very shaky.

- During display portion: Display DMA takes all Odd cycles (planes 1 to 4), and borrows half the Even cycles for the planes 5 and 6, leaving 40 cycles free. Copper can use all of those for example to change colors or reposition a few sprites. CPU would essentially be completely idle during this part.

I always think of a display fetch as a single 8-cycle operation. 6bitplane Lowres uses 6 of those cycles, leaving 2 cycles free for CPU or Blitter (very useful if you have a double buffered your display), but the Copper won't be much use here, the free cycles are not available to the Copper if I've understood the HRM diagram correctly.

One possible way to make CPU parallelize work even during fully saturate chip bus could be doing a few mul or a div instructions.

With some careful timing, the CPU could be doing almost 400 div or 1200 mul per frame essentially "for free" while the DMA is completely used by display & copper.

I always was (and still am) a terrible 68000 coder, I preferred to treat the CPU like a load/store machine so I didn't really have to worry too much about addressing modes... by using Address registers for temporary data register storage, I would try and make as much code as possible operate in the registers... so it can be done, but your code must be extremely deterministic to the point that the returns are so diminished, it's not worth the effort. Also what about interrupts?

All at the same time, 4 channel audio could be playing with less than 2% dma performance cost, and maybe even reading of a disk with a 1% dma performance cost (although I have never did a disk reading routine; it is possible that interrupts would take a much larger toll on CPU to handle copying buffers, etc.

Also if I calculate correctly, having sprite DMA active will cost 7% of dma, but just during the visible scanlines which are about 76%~82% of the total time, so real cost of sprites is approximately 5.5% per frame.

Depends how tall/multiplexed your sprites are...