English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 05 January 2020, 18:12   #1
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 40
blitter nasty bit vs cpu

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?
leonard is offline  
Old 05 January 2020, 18:49   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,569
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)
Toni Wilen is offline  
Old 05 January 2020, 20:10   #3
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 40
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

Last edited by leonard; 05 January 2020 at 20:18.
leonard is offline  
Old 05 January 2020, 20:23   #4
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 40
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?
leonard is offline  
Old 05 January 2020, 20:53   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,569
It is probably blitter idle cycle which CPU does not need (doing some internal operation). Check with 'v' command (v <vpos> <hpos>)
Toni Wilen is offline  
Old 05 January 2020, 21:08   #6
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 40
Quote:
Originally Posted by Toni Wilen View Post
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)

Last edited by leonard; 05 January 2020 at 21:26.
leonard is offline  
Old 05 January 2020, 21:33   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,569
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).
Toni Wilen is offline  
Old 06 January 2020, 02:16   #8
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 40
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?

Code:
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
leonard is offline  
Old 06 January 2020, 10:35   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,569
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)
Toni Wilen is offline  
Old 06 January 2020, 16:52   #10
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 40
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)
leonard is offline  
Old 06 January 2020, 20:07   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,569
Quote:
Originally Posted by leonard View Post
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)

Quote:
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.
Toni Wilen is offline  
Old 06 January 2020, 21:16   #12
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 40
Quote:
Originally Posted by Toni Wilen View Post
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 is offline  
Old 06 January 2020, 21:17   #13
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 40
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
leonard is offline  
Old 06 January 2020, 21:47   #14
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,569
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.
Toni Wilen is offline  
Old 06 January 2020, 22:30   #15
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 40
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?
leonard is offline  
Old 07 January 2020, 14:56   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,569
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.
Toni Wilen is offline  
Old 07 January 2020, 15:07   #17
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,578
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?
roondar is offline  
Old 07 January 2020, 16:32   #18
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,417
Quote:
Originally Posted by roondar View Post
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
ross is offline  
Old 10 January 2020, 15:29   #19
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,818
There's no reason to have BLTPRI off unless the calculations are heavy and the visuals light.
Photon is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Cpu or blitter? geldo79 Coders. Asm / Hardware 6 17 November 2019 01:25
Blitter vs CPU in BLitz carrion Coders. Blitz Basic 6 21 July 2018 22:19
One "hole" in each scan line to turn off blitter nasty? mc6809e Coders. Asm / Hardware 1 03 July 2012 13:12
Found nasty bug in 68030 CPU! Oliver_A Coders. General 11 13 November 2010 16:39
Blitter nasty or not? JackAsser Coders. Tutorials 5 28 March 2010 23:45

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 02:59.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09564 seconds with 13 queries