Visual DMA debugger requests

[ross]

[OT]
@Toni: why DMA cycle 0 is always used (extra cycle used by copper)?
[/OT]

[paraj]

Originally Posted by DamienD

http://www.winuae.net/files/b/winuae.7z

This is where Toni always uploads test builds to...

thanks, so obvious in retrospect...

anyway "luckily" my observations still stand

[Toni Wilen]

Originally Posted by paraj

* When switching off the visual debugger / changing modes the area outside the display window is not cleared (actually it looks like it's not cleared until something "actively" draws there, i.e. enabling then disabling the visual debugger under amigados i have to use the mouse to remove the old debugger output)

Done

* It looks like it's not possible to mask idle cycles?

What do you mean? Why is there any need to mask cycles that don't exist?

* This isn't a new issue for me, but has now become extra noticeable with the great -5/-6 modes: When in "big mode" (-4/-5/-6) I can't seem to find a display configuration that let's me see DMA for the final scanlines. This is very likely just my own incompetence.

Tall modes moved to top of screen but you still lose some lines.

* Very very low on the list: the debugger help text hasn't been updated

It is only done when/if new parameters are finished enough.

Originally Posted by ross

[OT]
@Toni: why DMA cycle 0 is always used (extra cycle used by copper)?
[/OT]

Perhaps you confuse it with CPU interrupt level bar? It is not part of DMA channels. (yellow = level 3)

[paraj]

Originally Posted by Toni Wilen

Done


What do you mean? Why is there any need to mask cycles that don't exist?

After executing v -5 / vm 0 0 / vm 1 0 / ... / vm 8 0, I expected the screen to look normal (only interrupt level overlay visible) instead every other vertical line is black, there also seems to be some other "miscoloring" which looked like they might correspond to when DMA is IDLE (which is why I guessed at that as the cause).

See attached screenshots (apart from the black lines there's also a distinct pattern noticeable). Mode is 5 and "vm" reports the following:

0,0: 00222222 -
1,0: 00444444 Refresh
1,1: 00444444 Refresh
1,2: 00444444 Refresh
1,3: 00444444 Refresh
2,0: 00a25342 CPU
2,1: 00ad98d6 CPU
3,0: 00eeee00 Copper
3,1: 00aaaa22 Copper
3,2: 00666644 Copper
4,0: 00ff0000 Audio
4,1: 00ff0000 Audio
4,2: 00ff0000 Audio
4,3: 00ff0000 Audio
5,0: 00008888 Blitter
5,1: 000088ff Blitter
6,0: 000000ff Bitplane
6,1: 000000ff Bitplane
6,2: 000000ff Bitplane
6,3: 000000ff Bitplane
6,4: 000000ff Bitplane
6,5: 000000ff Bitplane
6,6: 000000ff Bitplane
6,7: 000000ff Bitplane
7,0: 00ff00ff Sprite
7,1: 00ff00ff Sprite
7,2: 00ff00ff Sprite
7,3: 00ff00ff Sprite
7,4: 00ff00ff Sprite
7,5: 00ff00ff Sprite
7,6: 00ff00ff Sprite
7,7: 00ff00ff Sprite
8,0: 00ffffff Disk
8,1: 00ffffff Disk
8,2: 00ffffff Disk

Originally Posted by Toni Wilen

Tall modes moved to top of screen but you still lose some lines.

Originally Posted by Toni Wilen

It is only done when/if new parameters are finished enough.

Totally understandable, just mentioning it for completeness.

Also I just noticed a small annoyances with the debugger (Perhaps I should open another request thread?): When pressing shift+f12 with the debugger window already open, it'd be nice if it (the debugger window) was activated.

[Toni Wilen]

Originally Posted by paraj

After executing v -5 / vm 0 0 / vm 1 0 / ... / vm 8 0, I expected the screen to look normal (only interrupt level overlay visible) instead every other vertical line is black, there also seems to be some other "miscoloring" which looked like they might correspond to when DMA is IDLE (which is why I guessed at that as the cause).

See attached screenshots (apart from the black lines there's also a distinct pattern noticeable). Mode is 5 and "vm" reports the following:

Background blank and nothing here blank was different. Now they are same.

Also I just noticed a small annoyances with the debugger (Perhaps I should open another request thread?): When pressing shift+f12 with the debugger window already open, it'd be nice if it (the debugger window) was activated.

It does exactly that and works for me.

[ross]

Originally Posted by Toni Wilen

Done
Perhaps you confuse it with CPU interrupt level bar? It is not part of DMA channels. (yellow = level 3)

No, i mean the very first DMA cycle in line 0.
See attached image (a zoom in visual DMA debugger).

An empty copper list with CEND

[Toni Wilen]

Originally Posted by ross

No, i mean the very first DMA cycle in line 0.
See attached image (a zoom in visual DMA debugger).

An empty copper list with CEND

You said "cycle 0" previously, nothing about being specific to line 0

Copper does that extra cycle at vblank startup, it is useless looking read from previous line's last copper pointer. I guess this cycle does cop1 pointer to internal copper pointer copy. (Note that it is not same cycle sequence that COPJMPx access does)

Following cycle is first "normal" read.

[paraj]

Originally Posted by Toni Wilen

Background blank and nothing here blank was different. Now they are same.


It does exactly that and works for me.

I forgot to specify that I was talking about the GUI debugger - it works fine for the console debugger. But now that I think about it, the real solution is for me to always use the console version - it's only because the gui one is the default, that I've come to use it.

[Toni Wilen]

Originally Posted by paraj

I forgot to specify that I was talking about the GUI debugger - it works fine for the console debugger. But now that I think about it, the real solution is for me to always use the console version - it's only because the gui one is the default, that I've come to use it.

GUI debugger is unsupported. I didn't make it and I don't use it.

[ross]

Originally Posted by Toni Wilen

You said "cycle 0" previously, nothing about being specific to line 0

My bad

Copper does that extra cycle at vblank startup, it is useless looking read from previous line's last copper pointer. I guess this cycle does cop1 pointer to internal copper pointer copy. (Note that it is not same cycle sequence that COPJMPx access does)

Following cycle is first "normal" read.

Thanks as usual

[paraj]

Originally Posted by Toni Wilen

GUI debugger is unsupported. I didn't make it and I don't use it.

It shall never be mentioned again. If it isn't already perhaps it (= the console debugger) should be made the default for new configurations?

Anyway, I have no more issues to report. Great work and response time

[DamienD]

Originally Posted by paraj

thanks, so obvious in retrospect...

...not obvious really, I just know where it is located after years of Toni hosting there

Originally Posted by paraj

Great work and response time

Master Wilen; the man that never sleeps!!!

[paraj]

All changes work for me in the just posted 3410b6.7z

Though every other vertical line is still black in mode 5 when all channels are masked. No big deal as the visual debugger can now be turned off but personally I'd prefer those lines to just be transparent if it isn't much extra effort. Again no big deal and thanks for the work.

(I've attached a screenshot and my configuration just in case it's relevant. EDIT: it's the same using the quick start configurations)

[paraj]

Low priority crash bug report:

In latest beta (3410b7, commit 4009d994ca75b80baec0eff703e9396b54926dd1) and probably earlier it's possible to crash winuae by enabling the visual debugger before dma_record (in debug.cpp) is (re-)initialized.

To reproduce enter the debugger "very quickly" after startup. Easy to do when debugging from MSVC, otherwise chose a (new?) quick start configuration, press "start" and then quickly enter the debugger. In the debugger enter "v -3"<enter>"g"<enter> -> crash.

I can provide dmp-file / other info if needed.

Example callstack on crash (dma_record is {nullptr,nullptr}):

 	winuae.exe!debug_draw_cycles(unsigned char * buf=0x0e3f8ca0, int bpp=0x00000004, int line, int width=0x00000118, int height, unsigned int * xredcolors=0x04c34578, unsigned int * xgreencolors=0x04c34978, unsigned int * xbluescolors=0x04c34d78) Line 1389	C++
	winuae.exe!debug_draw(unsigned char * buf=0x0e3f8ca0, int bpp=0x00000004, int line=0x00000008, int width=0x000002f0, int height=0x0000023e, unsigned int * xredcolors=0x04c34578, unsigned int * xgreencolors=0x04c34978, unsigned int * xbluescolors=0x04c34d78) Line 1466	C++
 	[Inline Frame] winuae.exe!draw_debug_status_line(int) Line 3497	C++
 	winuae.exe!finish_drawing_frame() Line 3788	C++
 	winuae.exe!vsync_handle_redraw(int long_field, int lof_changed, unsigned short bplcon0p=0x0000, unsigned short bplcon3p=0x0c00) Line 3961	C++
 	winuae.exe!vsync_handler_pre() Line 7801	C++
 	winuae.exe!hsync_handler() Line 8674	C++
 	winuae.exe!do_cycles_slow(unsigned long cycles_to_add=0x00000000) Line 124	C++
 	winuae.exe!m68k_run_1() Line 4192	C++
 	winuae.exe!m68k_go(int may_quit) Line 5615	C++
 	winuae.exe!do_start_program() Line 990	C++
 	winuae.exe!real_main(int argc=0x00000000, wchar_t * * argv=0x06cc69c8) Line 1162	C++
 	winuae.exe!WinMain2(HINSTANCE__ * hInstance=0x000c0000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x06ca29e0, int nCmdShow=0x0000000a) Line 6283	C++
 	winuae.exe!wWinMain(HINSTANCE__ * hInstance=0x000c0000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x06ca29e0, int nCmdShow=0x0000000a) Line 7104	C++