English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 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
Click image for larger version

Name:	DMA_Debug.PNG
Views:	34
Size:	5.8 KB
ID:	65230  

Last edited by selco; 20 November 2019 at 17:46.
selco is offline  
Old 20 November 2019, 18:40   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,360
Quote:
Originally Posted by selco View Post
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.
Toni Wilen is online now  
Old 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)
selco is offline  
Old 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
Toni Wilen is online now  
Old 20 November 2019, 22:31   #5
selco
Registered User
 
Join Date: Aug 2013
Location: Germany
Posts: 62
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
selco is offline  
Old 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)
Toni Wilen is online now  
Old 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.
selco is offline  
Old 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?
selco is offline  
Old 21 November 2019, 17:46   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,360
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.
Toni Wilen is online now  
Old 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...
selco is offline  
Old 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..
Toni Wilen is online now  
 


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

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

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 16:03.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07312 seconds with 14 queries