05 January 2020, 17:12 | #1 |
Registered User
Join Date: Apr 2013
Location: paris
Posts: 133
|
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? |
05 January 2020, 17:49 | #2 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
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)
|
05 January 2020, 19:10 | #3 |
Registered User
Join Date: Apr 2013
Location: paris
Posts: 133
|
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 19:18. |
05 January 2020, 19:23 | #4 |
Registered User
Join Date: Apr 2013
Location: paris
Posts: 133
|
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? |
05 January 2020, 19:53 | #5 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
It is probably blitter idle cycle which CPU does not need (doing some internal operation). Check with 'v' command (v <vpos> <hpos>)
|
05 January 2020, 20:08 | #6 | |
Registered User
Join Date: Apr 2013
Location: paris
Posts: 133
|
Quote:
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 20:26. |
|
05 January 2020, 20:33 | #7 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
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). |
06 January 2020, 01:16 | #8 |
Registered User
Join Date: Apr 2013
Location: paris
Posts: 133
|
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 |
06 January 2020, 09:35 | #9 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
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) |
06 January 2020, 15:52 | #10 |
Registered User
Join Date: Apr 2013
Location: paris
Posts: 133
|
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) |
06 January 2020, 19:07 | #11 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
Quote:
Quote:
|
||
06 January 2020, 20:16 | #12 | |
Registered User
Join Date: Apr 2013
Location: paris
Posts: 133
|
Quote:
basically, whay isn't "black" pixel in the nasty bit mode posted previously? |
|
06 January 2020, 20:17 | #13 |
Registered User
Join Date: Apr 2013
Location: paris
Posts: 133
|
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 |
06 January 2020, 20:47 | #14 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
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. |
06 January 2020, 21:30 | #15 |
Registered User
Join Date: Apr 2013
Location: paris
Posts: 133
|
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?
|
07 January 2020, 13:56 | #16 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
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. |
07 January 2020, 14:07 | #17 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,409
|
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? |
07 January 2020, 15:32 | #18 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
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 |
|
10 January 2020, 14:29 | #19 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,602
|
There's no reason to have BLTPRI off unless the calculations are heavy and the visuals light.
|
15 February 2022, 21:23 | #20 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 49
Posts: 183
|
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) Code:
[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 |
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 00:25 |
Blitter vs CPU in BLitz | carrion | Coders. Blitz Basic | 6 | 21 July 2018 21:19 |
One "hole" in each scan line to turn off blitter nasty? | mc6809e | Coders. Asm / Hardware | 1 | 03 July 2012 12:12 |
Found nasty bug in 68030 CPU! | Oliver_A | Coders. General | 11 | 13 November 2010 15:39 |
Blitter nasty or not? | JackAsser | Coders. Tutorials | 5 | 28 March 2010 22:45 |
|
|