Questions about bitplane DMA

[Leffmann]

I'm trying to work out how much graphics I have time to blit in a single 50Hz frame, but run into some weird numbers when I estimate how much time the bitplane DMA will need.

Basically I get unexpected results whenever I activate bitplane DMA, and it seems to me that it either uses up more cycles than it needs (should it need more than 100 clock cycles per raster line for a 20 words of 5 bitplanes display?) or that it simply "locks out" the blitter from clock cycles for no reason.

If anyone knows what's going on here I would appreciate an explanation. I can also write a longer post with some numbers if anyone wants more info.

Thanks!

[Toni Wilen]

Originally Posted by Leffmann

Basically I get unexpected results whenever I activate bitplane DMA, and it seems to me that it either uses up more cycles than it needs (should it need more than 100 clock cycles per raster line for a 20 words of 5 bitplanes display?) or that it simply "locks out" the blitter from clock cycles for no reason.

No and no (at least I don't know any situation that can cause this)

What kind of blit? (not all blits use all available dma slots)

[Leffmann]

Hi

I'm measuring with a simple D=A block copy operation. I'm not much for technical documents and I might have misunderstood how the devices use the 226 clocks per raster line, any explanation would be appreciated. I could ofcourse just adjust my amount of graphics until everything runs in 50 Hz, but I'd like to know how to work the actual numbers.

[Toni Wilen]

Ok, D=A uses all cycles (as long as bltnasty is set). There are 226 slots but 4 of them are never available (refresh, as shown in HRM), perhaps this explains the difference?

[Leffmann]

It should, but I still don't get it

Maybe you can correct me here:

A 20 word by 256 by 5 D=A blit equals 102400 blitter ticks, and 2 blitter ticks are equivalent to 1 color clock cycle, am I right? With 222 clock cycles per raster line that makes out to the equivalent of ~230.5 raster lines under optimal conditions, but I get ~228.5 when measuring in UAE 1.5 with compatible settings.

I am displaying a 20 word by 256 by 5 bitmap. At the very start of the display I start a 50 word by 392 D=A blit. The blitter finishes after the equivalent of 256 full raster lines has passed, and I am assuming that the blitter and bitplane DMA together are then using all 222*256=56832 available clock cycles on these 256 lines. The blitter would need 39200 of these which leaves 17632 for the bitplane DMA, but shouldn't the bitplane DMA need 25600?

[Toni Wilen]

Originally Posted by Leffmann

A 20 word by 256 by 5 D=A blit equals 102400 blitter ticks, and 2 blitter ticks are equivalent to 1 color clock cycle, am I right? With 222 clock cycles per raster line that makes out to the equivalent of ~230.5 raster lines under optimal conditions, but I get ~228.5 when measuring in UAE 1.5 with compatible settings.

I wouldn't trust UAE too much generally but this is quite simple case that should work correctly. (cycle exact enabled?)

[Leffmann]

Cycle exact yes, the most hardware-true settings for a stock A500. I did some more tests and the results vary between OCS, ECS and AGA even under as equal conditions as possible. At least I can somewhat accurately estimate the time for a stock A500.

Thanks for your help!

[Toni Wilen]

Originally Posted by Leffmann

Cycle exact yes, the most hardware-true settings for a stock A500. I did some more tests and the results vary between OCS, ECS and AGA even under as equal conditions as possible. At least I can somewhat accurately estimate the time for a stock A500.

OCS and ECS should not have any difference. Your test code must be broken
(AGA has same blitter speed and bitplane DMA if FMODE=0 but there is no cycle exact AGA emulation)

[Leffmann]

Sorry I was tired and made a bad typo there, I meant to write "OCS/ECS and AGA", and you're right the timings only change once you set AGA. I think my mistake was to overestimate the accuracy of the emulator and the "maintain chipset timing" setting. Generally it seems the emulator is faster than real hardware, even with the most cycle exact settings, and if you need to find the limits you really need to use real hardware.

Thanks again

[Toni Wilen]

Post the code then if possible, I don't like unsolved problems.. (if it even is a problem)

[Leffmann]

There's no problem really, I will just do estimates on real hardware instead But for your interest, below is a very digested version of the test case. Granted, it resides in chipmem with all interrupts and DMA turned off prior.

I was expecting this code to take more than one frame to execute on the emulated cycle exact A500, under the assumption that there was a total of 69264 memory access cycles available and that the bitplane and blitter DMA need 69900 cycles together, not including the cycles needed by the CPU. On the emulated cycle exact A500 this code finishes with 1 raster line to spare:

(is there any way of formatting code nicely in this editor?)


lea $dff000, a6

move.l #$003800d0, ddfstrt(a6)
move.l #$2c812cc1, diwstrt(a6)
move.l #0, bpl1mod(a6)
move.w #%0101000000000000, bplcon0(a6)
move.l #copper, cop1lch(a6)
move.w d0, copjmp1(a6)
move.w #%1000011111000000, dmacon(a6)

main:
move.l vposr(a6), d0
lsr.l #1, d0
lsr.w #7, d0
cmp.w #$20, d0
bne.b main

move.l #0, bltapth(a6)
move.l #0, bltdpth(a6)
move.w #0, bltamod(a6)
move.w #0, bltdmod(a6)
move.l #-1, bltafwm(a6)
move.w #%0000100111110000, bltcon0(a6)
move.w #%0000000000000000, bltcon1(a6)

move.w #$500, color00(a6)
move.w #(443<<6)+50, bltsize(a6)

btst #6, dmaconr(a6)
waitblt:
btst #6, dmaconr(a6)
bne.b waitblt

move.w #$000, color00(a6)

bra.b main

copper:
dc.l $00e00000, $00e20000
dc.l $00e40000, $00e60100
dc.l $00e80000, $00ea0200
dc.l $00ec0000, $00ee0300
dc.l $00f00000, $00f20400
dc.l -2

[Toni Wilen]

I forgot something important, blitter can use 227 - 4 = 223 cycles. (available cycles are 0 to 226). This should fix the problem

(I already confirmed blitter can use all cycles except 4 refresh cycles when I did logic analyzer tests)