Interpreting DMA-Debugger output

selco · 20 November 2019, 14:31

Hi Toni,
I try to underdstand the blitter and therefore play with the dma debugger.
Before going to the blitter itself I wanted to start with something simpler(?) and more intuitive. So I wanted to look at/interprete the mouse pointer data first.

I use WinUAE 4.2.1.
Naked OS3.1.4.1, 16 Color Hires Interlace Workbench. The mouse-Pointer is at the very top left corner of the Workbench Screen.

Shift F12 for console debugger.
v-4 for DMA debugger.
v 44 to show contens of first(?) visible line. (Here I see the DMA fot the Bitplanes for the first time)

Here I want to inspect the Mouse Pointer.

Code:

[10  16]  [11  17]  [12  18]  [13  19]  [14  20]  [15  21]  [16  22]  [17  23]
                                                   SPR  140            SPR  142
                                                       C000                4000
                                                   00014B58            00014B5A
 4AA1DA00  4AA1DC00  4AA1DE00  4AA1E000  4AA1E200  4AA1E400  4AA1E600  4AA1E800

How to Interpret this data?
SPR 140 and SPR 142 are $dff140SPR0POSSprite 0 vert-horiz start pos data $dff142SPR0CTLSprite 0 position and control data

But if I look to these Data (C000 4000) and look also to the following lines, this seem to be the Bitmap-Data an not SPRxPOS data?
What are the Values below (00014B58 00014B5A)? The Chipmem-Address where C000 and 4000 are stored?

And Finally: What the 8digit values in the last line? Kind of counter or timestamp? What are they good for? What can they be used for?

One last Qustion?
Are there all DMA-Slots printed? I miss some bitplane-DMA. Ist the printed list to short?

[Edit] Ah, seems that the [<hpos>] is for! OK... One question less.

Toni Wilen · 20 November 2019, 18:40

Quote:

Originally Posted by selco

SPR 140 and SPR 142

Yes.

Quote:

But if I look to these Data (C000 4000) and look also to the following lines, this seem to be the Bitmap-Data an not SPRxPOS data?

How would I know what is it?

Quote:

What are the Values below (00014B58 00014B5A)? The Chipmem-Address where C000 and 4000 are stored?

Address where the data was loaded. Current data may be something else if it was modified between DMA fetch and when debugger was entered.

Quote:

And Finally: What the 8digit values in the last line? Kind of counter or timestamp? What are they good for? What can they be used for?

It is internal cycle counter (one cycle = 512 units)

Quote:

Are there all DMA-Slots printed? I miss some bitplane-DMA. Ist the printed list to short?

Yes. Make sure cycle exact mode is enabled. It won't work correctly in any other mode.

selco · 20 November 2019, 20:52

>>But if I look to these Data (C000 4000) and look also to the following lines, this seem to be the Bitmap-Data an not SPRxPOS data?
>How would I know what is it?

I looked at these data in Line 44, 45 and so on and wrote them bit-wise on grid-paper. These date are the Mouse-pointer Pixel-data, i.e. the Mouse pointer graphics.

But therefore I thougt the values above should be
144 SPR0DATA Sprite 0 low bitplane data
146 SPR0DATB Sprite 0 high bitplane data

instead of 140 and 142??? (See picture in my first posting)

Toni Wilen · 20 November 2019, 21:10

Oops, Sprite registers were swapped in debugger output

selco · 20 November 2019, 22:31

OK.

Now to the blitter. I wanted to copy a rectangle from an off-screen Bitmap into another Rastport and hat issues calculating the needed time. I calculated much less than I measured afterwards ;-)

But we have your DMA-debugger to loock what is actually going on...
Sometimes I see a lonely "B". What does that mean?

Code:

>v 32 80
Line: 20  32 HPOS 50  80:
 [50  80]  [51  81]  [52  82]  [53  83]  [54  84]  [55  85]  [56  86]  [57  87]
   CPU-WW                                          BLT  072  BLT  070
     3B0C            B         B         B             0000      F800  B
 00DFF058                                          0002B268  0001B498
 02F10E00  02F11000  02F11200  02F11400  02F11600  02F11800  02F11A00  02F11C00

 [58  88]  [59  89]  [5A  90]  [5B  91]  [5C  92]  [5D  93]  [5E  94]  [5F  95]
           BLT  072  BLT  070  BLT  000    CPU-RW  BLT  072  BLT  070  BLT  000
 B             0000      0000      F800  B   0003      0000      0000      0000
           0002B26A  0001B49A  0001B498  00C480E0  0002B26C  0001B49C  0001B49A
 02F11E00  02F12000  02F12200  02F12400  02F12600  02F12800  02F12A00  02F12C00

 [60  96]  [61  97]  [62  98]  [63  99]  [64 100]  [65 101]  [66 102]  [67 103]
   CPU-RW  BLT  072  BLT  070  BLT  000    CPU-RW  BLT  072  BLT  070  BLT  000
 B   0D08      0000      0000      0000  B   0002      0000      0000      0000
 00C480E2  0002B26E  0001B49E  0001B49C  00C1DFF0  0002B270  0001B4A0  0001B49E
 02F12E00  02F13000  02F13200  02F13400  02F13600  02F13800  02F13A00  02F13C00

 [68 104]  [69 105]  [6A 106]  [6B 107]  [6C 108]  [6D 109]  [6E 110]  [6F 111]
   CPU-RW  BLT  072  BLT  070  BLT  000            BLT  072  BLT  070  BLT  000
 B   0EE8      0000      0000      0000  B             0000      0000      0000
 00C1DFF2  0002B272  0001B4A2  0001B4A0            0002B274  0001B4A4  0001B4A2
 02F13E00  02F14000  02F14200  02F14400  02F14600  02F14800  02F14A00  02F14C00

 [70 112]  [71 113]  [72 114]  [73 115]  [74 116]  [75 117]  [76 118]  [77 119]
           BLT  072  BLT  070  BLT  000            BLT  072  BLT  070  BLT  000
 B             0000      0000      0000  B             0000      0000      0000
           0002B276  0001B4A6  0001B4A4            0002B278  0001B4A8  0001B4A6
 02F14E00  02F15000  02F15200  02F15400  02F15600  02F15800  02F15A00  02F15C00

 [78 120]  [79 121]  [7A 122]  [7B 123]  [7C 124]  [7D 125]  [7E 126]  [7F 127]
   CPU-WW  BLT  072  BLT  070  BLT  000    CPU-WW  BLT  072  BLT  070  BLT  000
 B   00F9      0000      0000      0000  B   998E      0000      0000      0000
 00C1DBB2  0002B27A  0001B4AA  0001B4A8  00C1DBB4  0002B27C  0001B4AC  0001B4AA
 02F15E00  02F16000  02F16200  02F16400  02F16600  02F16800  02F16A00  02F16C00

 [80 128]  [81 129]  [82 130]  [83 131]  [84 132]  [85 133]  [86 134]  [87 135]
           BLT  072  BLT  070  BLT  000            BLT  072  BLT  070  BLT  000
 B             0000      03FF      0000  B             0000      F800      03FF
           0002B27E  0001B4AE  0001B4AC            0002B2B8  0001B4E8  0001B4AE

Toni Wilen · 20 November 2019, 22:51

B = blitter idle cycle. Cycle that blitter needs to be free but blitter does not use it and it is available for the CPU (Blitter start has always 2 idle cycles, purpose unknown)

selco · 20 November 2019, 23:45

I see. Nice!
So the blitter takes all slots he can get. Even Sprite or Bitplane-Slots, if they are not used. I was confused because I have a book here that explicitely states "The blitter only uses the even bus cycles."

OK. What I am investigating is a call to BltBitmapRastport() with Mintern 0xC0. I wanted a simple copy. The debugger shows always the following repeating sequence:

Code:

[80 128]  [81 129]  [82 130]  [83 131]  [84 132]  [85 133]  [86 134]  [87 135]
           BLT  072  BLT  070  BLT  000            BLT  072  BLT  070  BLT  000
 B             0000      03FF      0000  B             0000      F800      03FF
           0002B27E  0001B4AE  0001B4AC            0002B2B8  0001B4E8  0001B4AE

So 81 to 83
072 (0000 from Address 0002B27E) -> BLTBDAT Blitter source B data reg
070 (03FF from Address 0001B4AE) -> BLTCDAT Blitter source C data reg
000 (0000 from Bitter to Address 0001B4AC ??? -> BLTDDAT Blitter destination data register

Ok. He probably reads a word (0000) from 0002B27E (Source?), then reads 03ff from the target? 0001B4AE, combines both values and then stores the result 0000 to the target. Am I right? But why differ the two target addresses by two?

[Edit] Ah, this two bytes offset above seem to be the effect of the pipelining.

selco · 21 November 2019, 14:40

But another understanding issue:

I use the blitter via BltBitmapRastport() and Minterm 0xf0.
I would like a simple plain copy D=A.

In the DMA-Debugger I always see 070, 072 and 000, i.e,

$dff070 BLTCDAT Blitter source C data reg
$dff072 BLTBDAT Blitter source B data reg
$dff000 BLTDDAT Blitter destination

but never a 074 for Source A? I should see the Source A somewhere, shouldn't I?

Toni Wilen · 21 November 2019, 17:46

Minterm and active channels are totally independent. A channel probably is used as a static mask (BLTADAT is loaded with CPU).

Quote:

I was confused because I have a book here that explicitely states "The blitter only uses the even bus cycles."

Yes, it is wrong. Both blitter and CPU can use any available cycle.

selco · 25 November 2019, 11:56

Thanks for the eplainations.
DMA-Debugger is really a nice feature to understand the Amiga!

Would it be possible to list or save the whole contents of all slots and all lines with one command? I think of a textfile that I can process further, for instance via scripts or in an external editor. That would make it easy to measure timings or even to grap graphics or sprites from the DMA-Listing...

It would also be interesting to know the rasterline-number from the visual DMA-Display. For instance I see a Blitter copy starting around the half of the visual display (i.e. green area in the visual DMAdisplay). When I now try to inspect that line with v <y-pos>, I need to find this line number...

Toni Wilen · 27 November 2019, 21:48

You can use -blitterdebug 1 to enable blitter log messages which should help to find out when blitter was started and used parameters.

Current (and previous frame) output to text file debugger command sounds useful..

20 November 2019, 14:31	#1
selco Registered User Join Date: Aug 2013 Location: Germany Posts: 62	Interpreting DMA-Debugger output Hi Toni, I try to underdstand the blitter and therefore play with the dma debugger. Before going to the blitter itself I wanted to start with something simpler(?) and more intuitive. So I wanted to look at/interprete the mouse pointer data first. I use WinUAE 4.2.1. Naked OS3.1.4.1, 16 Color Hires Interlace Workbench. The mouse-Pointer is at the very top left corner of the Workbench Screen. Shift F12 for console debugger. v-4 for DMA debugger. v 44 to show contens of first(?) visible line. (Here I see the DMA fot the Bitplanes for the first time) Here I want to inspect the Mouse Pointer. Code: [10 16] [11 17] [12 18] [13 19] [14 20] [15 21] [16 22] [17 23] SPR 140 SPR 142 C000 4000 00014B58 00014B5A 4AA1DA00 4AA1DC00 4AA1DE00 4AA1E000 4AA1E200 4AA1E400 4AA1E600 4AA1E800 How to Interpret this data? SPR 140 and SPR 142 are $dff140SPR0POSSprite 0 vert-horiz start pos data $dff142SPR0CTLSprite 0 position and control data But if I look to these Data (C000 4000) and look also to the following lines, this seem to be the Bitmap-Data an not SPRxPOS data? What are the Values below (00014B58 00014B5A)? The Chipmem-Address where C000 and 4000 are stored? And Finally: What the 8digit values in the last line? Kind of counter or timestamp? What are they good for? What can they be used for? One last Qustion? Are there all DMA-Slots printed? I miss some bitplane-DMA. Ist the printed list to short? [Edit] Ah, seems that the [<hpos>] is for! OK... One question less. Attached Thumbnails Last edited by selco; 20 November 2019 at 17:46.

20 November 2019, 23:45	#7
selco Registered User Join Date: Aug 2013 Location: Germany Posts: 62	I see. Nice! So the blitter takes all slots he can get. Even Sprite or Bitplane-Slots, if they are not used. I was confused because I have a book here that explicitely states "The blitter only uses the even bus cycles." OK. What I am investigating is a call to BltBitmapRastport() with Mintern 0xC0. I wanted a simple copy. The debugger shows always the following repeating sequence: Code: [80 128] [81 129] [82 130] [83 131] [84 132] [85 133] [86 134] [87 135] BLT 072 BLT 070 BLT 000 BLT 072 BLT 070 BLT 000 B 0000 03FF 0000 B 0000 F800 03FF 0002B27E 0001B4AE 0001B4AC 0002B2B8 0001B4E8 0001B4AE So 81 to 83 072 (0000 from Address 0002B27E) -> BLTBDAT Blitter source B data reg 070 (03FF from Address 0001B4AE) -> BLTCDAT Blitter source C data reg 000 (0000 from Bitter to Address 0001B4AC ??? -> BLTDDAT Blitter destination data register Ok. He probably reads a word (0000) from 0002B27E (Source?), then reads 03ff from the target? 0001B4AE, combines both values and then stores the result 0000 to the target. Am I right? But why differ the two target addresses by two? [Edit] Ah, this two bytes offset above seem to be the effect of the pipelining. Last edited by selco; 21 November 2019 at 14:40.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Visual DMA debugger feature request	roondar	request.UAE Wishlist	4	06 June 2019 12:35
Visual DMA debugger requests	ross	request.UAE Wishlist	33	23 April 2017 01:27
visual DMA debugger crash and questions	selco	support.WinUAE	4	28 April 2015 10:53
DMA debugger and 14Mhz 68K	ovale	support.WinUAE	3	10 June 2014 16:10
Error while interpreting script	Makkinen	support.Apps	1	15 October 2004 16:58

20 November 2019, 20:52	#3
selco Registered User Join Date: Aug 2013 Location: Germany Posts: 62	>>But if I look to these Data (C000 4000) and look also to the following lines, this seem to be the Bitmap-Data an not SPRxPOS data? >How would I know what is it? I looked at these data in Line 44, 45 and so on and wrote them bit-wise on grid-paper. These date are the Mouse-pointer Pixel-data, i.e. the Mouse pointer graphics. But therefore I thougt the values above should be 144 SPR0DATA Sprite 0 low bitplane data 146 SPR0DATB Sprite 0 high bitplane data instead of 140 and 142??? (See picture in my first posting)

20 November 2019, 21:10	#4
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 44 Posts: 23,360	Oops, Sprite registers were swapped in debugger output

20 November 2019, 22:51	#6
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 44 Posts: 23,360	B = blitter idle cycle. Cycle that blitter needs to be free but blitter does not use it and it is available for the CPU (Blitter start has always 2 idle cycles, purpose unknown)

21 November 2019, 14:40	#8
selco Registered User Join Date: Aug 2013 Location: Germany Posts: 62	But another understanding issue: I use the blitter via BltBitmapRastport() and Minterm 0xf0. I would like a simple plain copy D=A. In the DMA-Debugger I always see 070, 072 and 000, i.e, $dff070 BLTCDAT Blitter source C data reg $dff072 BLTBDAT Blitter source B data reg $dff000 BLTDDAT Blitter destination but never a 074 for Source A? I should see the Source A somewhere, shouldn't I?

25 November 2019, 11:56	#10
selco Registered User Join Date: Aug 2013 Location: Germany Posts: 62	Thanks for the eplainations. DMA-Debugger is really a nice feature to understand the Amiga! Would it be possible to list or save the whole contents of all slots and all lines with one command? I think of a textfile that I can process further, for instance via scripts or in an external editor. That would make it easy to measure timings or even to grap graphics or sprites from the DMA-Listing... It would also be interesting to know the rasterline-number from the visual DMA-Display. For instance I see a Blitter copy starting around the half of the visual display (i.e. green area in the visual DMAdisplay). When I now try to inspect that line with v <y-pos>, I need to find this line number...

27 November 2019, 21:48	#11
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 44 Posts: 23,360	You can use -blitterdebug 1 to enable blitter log messages which should help to find out when blitter was started and used parameters. Current (and previous frame) output to text file debugger command sounds useful..

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