DMA when using 640x200 (4 bpl)

[VladR]

I'm thinking of using 640x200 with 4 bitplanes on an OCS, with a 25/30 fps lock (2 full frames).

While browsing through Amiga HW Ref Manual, I noticed the following:

During a horizontal scan line (about 63 microseconds), there are 227.5 “color clocks”, or memory access cycles. A memory cycle is approximately 280 ns in duration. The total of 227.5 cycles per horizontal line includes both display time and non-display time. Of this total time, 226 cycles are available to be allocated to the various devices that need memory access.

The time-slot allocation per horizontal line is:
4 cycles for memory refresh (assigned to odd-numbered slots)
3 cycles for disk DMA
4 cycles for audio DMA (2 bytes per channel)
16 cycles for sprite DMA (2 words per channel)
80 cycles for bit-plane DMA (even- or odd-numbered slots according to the display size used)

And here comes the offending part:

If you specify four high-resolution bit-planes (640 pixels wide), bit-plane DMA needs all of the available memory time slots during the display time just to fetch the 40 data words for each line of the four bit-planes (40 x 4 = 160 time slots).

This effectively locks out the 68000 (as well as the blitter or Copper) from any memory access during the display.

I understand that I would only have CPU available for RAM access only during horizontal blank period each scanline, correct ?

But, does that mean that the HW would basically not be able display the standard HW sprites (16px wide) ?
Would it glitch or just not display them at all ? I was thinking 4 sprites, which is nothing, but perhaps it's a problem in this mode ?

On the other hand, I guess I could use that time to do all 3D transformations (instead of look up tables), as the cost of MUL and DIV becomes free, basically.
Meaning, I could load the (X,Y,Z) during HBlank, then invoke MUL/DIV and during next available HBLank store the results and repeat for next vertex.
That should work, right ?

[Rotareneg]

The sprite data registers are loaded before bit-plane DMA starts. You can lose a few sprites if you use overscan and/or horizontal scrolling.

[VladR]

Originally Posted by Rotareneg

The sprite data registers are loaded before bit-plane DMA starts. You can lose a few sprites if you use overscan and/or horizontal scrolling.

Alright, so for a static non-scrolling HiRes 4bpl, all sprites will be visible.

When they mention Copper is locked out - this means that the Copper List would only run during HBlank period per each scanline ?

How many registers can Copper change during HBlank ? I doubt it's 16/32, especially when it will be fighting for DMA with 68000...

[roondar]

Originally Posted by VladR

Alright, so for a static non-scrolling HiRes 4bpl, all sprites will be visible.

When they mention Copper is locked out - this means that the Copper List would only run during HBlank period per each scanline ?

How many registers can Copper change during HBlank ? I doubt it's 16/32, especially when it will be fighting for DMA with 68000...

Yes, you get all 8 sprite channels available.
The Copper is available in HBlank. It can change 16 registers per HBlank because it has priority over the 68000 and interleaves* with the other DMA sources.

*) Like the 68000, the Copper can only access every other DMA cycle. It's been designed so that the cycles it uses are the odd cycles, whereas disk, Sprite and audio only use the even cycles.