blitter nasty bit vs cpu

[leonard]

Hi,

I surely missed something here. I though that if setting the blitter nasty bit ON, then the CPU has no chip mem slots available while blitter is running.

But using WinUAE DMA debug view ( btw this debug view is *awesome* ) I can see many "CPU activity pixels" during a very large blitter FILL.

I guess it's expected, but I don't understand why. Why the CPU is still executing some chip meme cycle during blitter fill & nasty bit?

[Toni Wilen]

Some channel combinations (for example D=A) add one idle cycle in fill mode. (EDIT: you can see it if you use v command to list DMA slot details)

[leonard]

oh ok make sense. Looking at the map, for a blitter FILL ( filled polygon ), I can see 2 cycles blitter, and 1 cycle CPU ( everything is repeating with a 3 cycles period). This is when bitplans are OFF. And this is the exact same behavior whatever nasty bit is.

Now when bitplans are active ( 3 bitplans in my case ) I can see a small difference. When nasty bit is OFF, in each block of 48 pixels ( so 24 DMA cycles ) I can see:

Nasty OFF, cycle repeat on 24 cycles
-8 cycles of blitter FILL
-9 cycles of bitplans
-6 cycles of CPU
-1 cycle of "nothing" ( black pixel )

Nasty ON
-10 cycles of blitter FILL
-9 cycles of bitplans
-5 cycles of CPU

That DMA debug view is really nice, thanks a lot for that Toni

[leonard]

btw what is this "unused cycle" (black pixel) in first case? ( 24 cycles, 3 bitplans ON,nasty bit OFF )
Why this cycle isn't filled with either a CPU or Blitter cycle?

[Toni Wilen]

It is probably blitter idle cycle which CPU does not need (doing some internal operation). Check with 'v' command (v <vpos> <hpos>)

[leonard]

Originally Posted by Toni Wilen

It is probably blitter idle cycle which CPU does not need (doing some internal operation). Check with 'v' command (v <vpos> <hpos>)

the CPU is executing a bunch of large movem.l clear ( so I guess CPU is requesting chip mem bus each cycle ). ( ie large tower of "movem.l dn-an,offset(an)" )

Btw what's the easiest method to spot the right vpos/hpos to use with v command? ( I "see" the black pixel every 48 pixels in the screenshot, but no easy way to look at this pixel using v command)

[Toni Wilen]

There is no simple way, only way is to keep looking line by line until you find cycle that is not used. Should be quite easy to find if it repeats multiple times/scanline.

MOVEM should not have any idle cycles except if addressing mode is (d8,An,Xn).

[leonard]

Where can I find any info about the "v" command? Here is a good spot ( 100,100).

The "empty" cycle seems to be located at hpos $72, $8a and $a2 in this shot. What does mean the "B"?
Also what does mean "N" in some other slots? And what is CPU-WW?
And last, when nothing is written (like pos $65, $67 etc), what does it mean?

v 100 100
Line: 64 100 HPOS 64 100:
 [64 100]  [65 101]  [66 102]  [67 103]  [68 104]  [69 105]  [6A 106]  [6B 107] 
 BLT  000       114    CPU-WW       110    CPU-WW  BLT  074  BLT  000       112 
     FFFF      0007  N   0000      0000  B   0000      0104      FFFF      FFFF 
 00058B54  000439B8  00040966  0004398C  00040968  00058B50  00058B52  0007BCDE 
 07635400  07635600  07635800  07635A00  07635C00  07635E00  07636000  07636200 

 [6C 108]  [6D 109]  [6E 110]  [6F 111]  [70 112]  [71 113]  [72 114]  [73 115] 
   CPU-WW       114  BLT  074       110  BLT  000    CPU-WW                 112 
 B   0000      FFFF      0000      0000      FF03  N   0000  B             FFFF 
 0004096A  000439BA  00058B4E  0004398E  00058B50  0004096C            0007BCE0 
 07636400  07636600  07636800  07636A00  07636C00  07636E00  07637000  07637200 

 [74 116]  [75 117]  [76 118]  [77 119]  [78 120]  [79 121]  [7A 122]  [7B 123] 
 BLT  074       114    CPU-WW       110  BLT  000    CPU-WW  BLT  074       112 
     0000      FFFF  N   0000      0000      FFFF  B   0000      0000      FFFF 
 00058B4C  000439BC  0004096E  00043990  00058B4E  00040970  00058B4A  0007BCE2 
 07637400  07637600  07637800  07637A00  07637C00  07637E00  07638000  07638200 

 [7C 124]  [7D 125]  [7E 126]  [7F 127]  [80 128]  [81 129]  [82 130]  [83 131] 
 BLT  000       114    CPU-WW       110    CPU-WW  BLT  074  BLT  000       112 
     FFFF      FFFF  N   0000      0000  B   0000      0000      FFFF      FFFF 
 00058B4C  000439BE  00040972  00043992  00040974  00058B48  00058B4A  0007BCE4 
 07638400  07638600  07638800  07638A00  07638C00  07638E00  07639000  07639200 

 [84 132]  [85 133]  [86 134]  [87 135]  [88 136]  [89 137]  [8A 138]  [8B 139] 
   CPU-WW       114  BLT  074       110  BLT  000    CPU-WW                 112 
 B   0000      FFFF      0000      0000      FFFF  N   0000  B             FFFF 
 00040976  000439C0  00058B46  00043994  00058B48  00040978            0007BCE6 
 07639400  07639600  07639800  07639A00  07639C00  07639E00  0763A000  0763A200 

 [8C 140]  [8D 141]  [8E 142]  [8F 143]  [90 144]  [91 145]  [92 146]  [93 147] 
 BLT  074       114    CPU-WW       110  BLT  000    CPU-WW  BLT  074       112 
     0000      FFFF  N   0000      0000      FFFF  B   0000      0000      FFFF 
 00058B44  000439C2  0004097A  00043996  00058B46  0004097C  00058B42  0007BCE8 
 0763A400  0763A600  0763A800  0763AA00  0763AC00  0763AE00  0763B000  0763B200 

 [94 148]  [95 149]  [96 150]  [97 151]  [98 152]  [99 153]  [9A 154]  [9B 155] 
 BLT  000       114    CPU-WW       110    CPU-WW  BLT  074  BLT  000       112 
     FFFF      FFFF  N   0000      0000  B   0000      0000      FFFF      FFFF 
 00058B44  000439C4  0004097E  00043998  00040980  00058B40  00058B42  0007BCEA 
 0763B400  0763B600  0763B800  0763BA00  0763BC00  0763BE00  0763C000  0763C200 

 [9C 156]  [9D 157]  [9E 158]  [9F 159]  [A0 160]  [A1 161]  [A2 162]  [A3 163] 
   CPU-WW       114  BLT  074       110  BLT  000    CPU-WW                 112 
 B   0000      FFFF      0001      0000      FFFF  N   0000  B             FFFF 
 00040982  000439C6  00058B3E  0004399A  00058B40  00040984            0007BCEC 
 0763C400  0763C600  0763C800  0763CA00  0763CC00  0763CE00  0763D000  0763D200 

 [A4 164]  [A5 165]  [A6 166]  [A7 167]  [A8 168]  [A9 169]  [AA 170]  [AB 171] 
 BLT  074       114    CPU-WW       110  BLT  000    CPU-WW  BLT  074       112 
     0000      C000  N   0000      0000      0000  B   0000      0040      FFFF 
 00058B3C  000439C8  00040986  0004399C  00058B3E  00040988  00058B3A  0007BCEE 
 0763D400  0763D600  0763D800  0763DA00  0763DC00  0763DE00  0763E000  0763E200 

 [AC 172]  [AD 173]  [AE 174]  [AF 175]  [B0 176]  [B1 177]  [B2 178]  [B3 179] 
 BLT  000       114    CPU-WW       110    CPU-RW  BLT  074  BLT  000       112 
     0000      1FE0  N   0000      0000  B   07FF      0000      FFC0      FFFF 
 00058B3C  000439CA  0004098A  0004399E  00C6A3EE  00058B38  00058B3A  0007BCF0 
 0763E400  0763E600  0763E800  0763EA00  0763EC00  0763EE00  0763F000  0763F200

[Toni Wilen]

Cycle is unused because CPU memory access takes 4 cycles (=2 DMA slots). It can't do back to back memory accesses, there is always one DMA cycle between accesses.

68000 memory access is basically in two parts, first half sends address, second half transfers data. CPU can always do first part of access, even if bus is currently in use. When second part is about to start, if bus is not available, Agnus/Gary won't complete the cycle and CPU simply thinks it is accessing memory with (possibly lots of) wait states.

For example slot $72: $71 was CPU data transfer (second half of CPU memory cycle, first handle is always invisible. #$0000.W -> $0004096C). This means CPU can't use slot $72 (it may use it for first part of next cycle). It is also blitter idle cycle.

B = blitter needed this cycle but it is also available for CPU if CPU needs it. (=blitter idle cycle which means blitter did some internal operation but it didn't need bus hardware = CPU can still access chip bus)

N = bus cycle given to CPU due to blitter nasty not enabled. Note that logic of blitter nasty is not what you probably think it is: If CPU waits more than 3 cycles, it gets next blitter cycle. ANY DMA cycle counts, it does not need to be blitter cycle, only requirement is that blitter is also active. In this case result was 1 lost cycle, CPU got cycle that was originally going to be blitter idle cycle which CPU would have gotten automatically. But because priority was given to CPU, blitter couldn't use it..

CPU-WW = CPU Write Word.

Cycles without extra text: DMA transfer, for example $65 = $0007 written to $0114 (BPL3DAT)

[leonard]

thanks for so much details! I have better picture now. Anyway I still have some questions to fully understand future DMA map I could look at.

So CPU can't use two DMA successive slots ( for instance with v command I should never see two CPU-WW next to each other). Fair enough.

Now if you look at pos $72. Blitter is in idle mode, meaning that it's doing internal stuff ( but no chip mem access). So why this cycle is displayed as "black" in the DMA view? Because the blitter is "really" doing something right? ( internal, but it's doing FILL, or did I miss something)

[Toni Wilen]

Originally Posted by leonard

So CPU can't use two DMA successive slots ( for instance with v command I should never see two CPU-WW next to each other). Fair enough.

Yes. CPU can only use every other cycle (but note that there is no other restrictions, CPU can use both odd and even cycles)

Now if you look at pos $72. Blitter is in idle mode, meaning that it's doing internal stuff ( but no chip mem access). So why this cycle is displayed as "black" in the DMA view? Because the blitter is "really" doing something right? ( internal, but it's doing FILL, or did I miss something)

It is considered free because cycle is not "used" and it is available for CPU if it wants it and adding yet another color would not help much in my opinion.

[leonard]

Originally Posted by Toni Wilen

It is considered free because cycle is not "used" and it is available for CPU if it wants it and adding yet another color would not help much in my opinion.

not another color but the standard blitter FILL color ( as blitter is really working as filling a polygon). If you consider the previous mode where nasty is ON, you don't see any "black" pixel ( so blitter is filling all the gaps ). Blitter should also have some cycle where he's doing some work but not chip mem access.

basically, whay isn't "black" pixel in the nasty bit mode posted previously?

[leonard]

so if we look at my first post:

Nasty OFF, cycle repeat on 24 cycles
-8 cycles of blitter FILL
-9 cycles of bitplans
-6 cycles of CPU
-1 cycle of "nothing" ( black pixel )

Does it make sense to say that instead of that, real thing is:

Nasty OFF, cycle repeat on 24 cycles
-9 cycles of blitter FILL ( one is "black pixel", but blitter is really doing work)
-9 cycles of bitplans
-6 cycles of CPU

[Toni Wilen]

Yes but it it meant to show only DMA slot usage (DMA data transfers). Extra letters are used to show some special conditions.

No data is transferred when blitter does internal stuff. Many normal block move blitter operations and line mode also includes idle cycles that most likely do some hidden internal operations too and they are also not included.

[leonard]

I get it, but in this case why isn't "black" pixel in nasty ON mode? I mean, the blitter in FILL mode also have some cycle without doing memory access ( ie real line or fill computation). These cycles should also appears black when nasty is ON right?

[Toni Wilen]

Because CPU can always use it in that case. (As I already explained above)

Nasty on: blitter always has priority. Blitter gets the idle fill cycle but because it was idle cycle, it is also usable by the CPU. (This does not violate CPU can't do back to back transfers because idle cycle is always followed by at least 2 blitter cycles, CPU has enough time to start new memory access before next idle cycle)

Nasty off: CPU has priority if CPU has waited at least 3 cycles: CPU completely steals the cycle from blitter, even if it is blitter idle cycle. Blitter needs to wait for next cycle. EDIT: and CPU can't use this because it would mean back to back CPU cycle.

It is easy to waste both CPU and blitter time by not enabling blitter nasty if you aren't careful.

[roondar]

If I understood the above correctly, that is interesting to know.

So just to be clear, have I got this correctly: If the Blitter is running and not in nasty mode and the CPU has waited at least 3 cycles, the CPU gets the next available cycle (Blitter idle or not). If this happens to be a Blitter idle cycle, the Blitter still has to do an extra idle cycle directly afterwards, which wastes cycles because the CPU can't use it.

Or have I misread that?

[ross]

Originally Posted by roondar

If I understood the above correctly, that is interesting to know.

So just to be clear, have I got this correctly: If the Blitter is running and not in nasty mode and the CPU has waited at least 3 cycles, the CPU gets the next available cycle (Blitter idle or not). If this happens to be a Blitter idle cycle, the Blitter still has to do an extra idle cycle directly afterwards, which wastes cycles because the CPU can't use it.

Or have I misread that?

I completed a glenz routine that used 5 bitplanes and initially I hadn't set the nasty bit because I thought it would leave me more cycles for the polygonal calculations superimposed on the blitter operations.
Instead in the end, after some real use check, I realized that setting BLTPRI it required fewer video lines for the whole.

So I really think that's the reason, especially when there are CPU operations that can potentially 'steal' blitter cycles and that even if started later don't create slowdowns in the end times (for example shift/mul/div that in any case leave bus free for some time, combined with blitter operations with idle cycles).

Do not take for granted which is the best option, try in the field and prepare to dynamically change the use of the bit

[Photon]

There's no reason to have BLTPRI off unless the calculations are heavy and the visuals light.

[Rock'n Roll]

I analysed a the blitter-cycle sequence from a clear operation with the blitter
with the dma-debugger and get for me a strange result.

I expected the blitter cycle sequence: D0 - D1 - D2 (only channel D is used)
But the last BLT-D isn't in this order. I know this bus arbitration is complex.
But maybe there is a rule that could explaine a little bit?

There is a b and D. What does it mean?

Then one improvement suggestion for the dma-debugger. It would helpful if I
can go forward with a >v to show the next bus-cycles. (like for >m or >o)

[A8 168]  [A9 169]  [AA 170]  [AB 171]  [AC 172]  [AD 173]  [AE 174]  [AF 175]
   CPU-RW  BPL2 112  BLT-D 00  BPL1 110    CPU-RW  BPL2 112  BLT-D 00  BPL1 110
 B   5000      0000      0000      0000  B   66EC      0000      0000      0000
 00026430  0001F36C  00014FC8  0001A36C  00026432  0001F36E  00014FCA  0001A36E
 E70E2600  E70E2800  E70E2A00  E70E2C00  E70E2E00  E70E3000  E70E3200  E70E3400

 [B0 176]  [B1 177]  [B2 178]  [B3 179]  [B4 180]  [B5 181]  [B6 182]  [B7 183]
   CPU-RW  BPL2 112  BLT-D 00  BPL1 110  BLT-D 00  BPL2 112    CPU-RW  BPL1 110
 B   0839  b   0000      0000      0000  D   0000      0000      0006      0000
 00026434  0001F370  00014FCC  0001A370  00014FCE  0001F372  00026436  0001A372
 E70E3600  E70E3800  E70E3A00  E70E3C00  E70E3E00  E70E4000  E70E4200  E70E4400

>>H 10
 0 0002642c 0c80 0000 5000           cmp.l #$00005000,d0
 - A8 CPU-RW B   5000 00026430
 - A9 BPL2 112     0000 0001F36C
 - AA BLT-D 00     0000 00014FC8
 - AB BPL1 110     0000 0001A36C
 - AC CPU-RW B   66EC 00026432
 - AD BPL2 112     0000 0001F36E
 - AE BLT-D 00     0000 00014FCA
 - AF BPL1 110     0000 0001A36E
 - B0 CPU-RW B   0839 00026434
 - B1 BPL2 112 b   0000 0001F370
 - B2 BLT-D 00     0000 00014FCC
 0 00026432 66ec                     bne.b #$ec == $00026420 (F)
 - B3 BPL1 110     0000 0001A370
 - B4 BLT-D 00 D   0000 00014FCE
 - B5 BPL2 112     0000 0001F372
 - B6 CPU-RW     0006 00026436
 - B7 BPL1 110     0000 0001A372