Visual DMA debugger requests
 

Some requests for the visual DMA debugger:
- plot the 'hidden' Copper cycles ('awakening' of WAIT instruction and 3rd cycle of SKIP instruction);
- plot the lost $E0 cycle (when lost);
- ability to disable visual DMA debugger when enabled
(maybe already possible but I've not find the command..).

Thanks, bye,
ross

Can be done but I am not sure if there are enough different shades..

Perhaps some kind of bitmask is good idea to enable switching off specific visual DMA channels?

Regarding the number of shades, are you worried about them being hard to distinguish or are there other constraints? Because even with the current shades I have to use tools* to get anything other than a quick overview (which is of course still great). This isn't a criticism by any means, mostly just wondering.

I also second the request for turning off the visual debugger :) It's great for getting an overview of what's going on, but it's a bit annoying to have to restart WinUAE afterwards. Is this the sort of thing the WinUAE project (=you?) would accept via a pull request on github? I can totally understand if they/you prefer not to have to deal with all the hassle of random internet idiots code, but if there's already an established process I might just code it myself.

*) Most of the time the "tool" is a simply an image editor where I use the color picker on a zoomed image or run a cropped screenshot through a simple color counter. Here being able to tell two colors apart by eye helps, but isn't paramount.

Why even use visual debugger if you need to use image editor? It isn't meant for detailed view. Any detailed info should be checked using console DMA debugger.

Off option will be added.

The spacebar keeps me warm! More seriously because I'm not too good friends with the debugger window (yet), maybe it's my inexperience, screen resolution or perhaps I should switch to the console version.

So far I've used the visual debugger in the following ways:
1) Get a quick overview of where time is spent: Does it match my expectations? Any weird frame-to-frame variations (this is where it's extremely helpful compared to checking the console DMA debugger)?
2) Inspecting specific issues: End of line problems / interference between various DMA consumers. This is where I grab a screenshot and zoom in on various points of interest. It's nice to be able to quickly compare how different scanlines are handled without having to think about how ddfstrt etc. relates to actual DMA slots (yet).
3) When I already have a saved screenshot from one of the above steps, I sometimes process it to get a DMA dma slot allocation stats for that frame. There's probably a way to get that from the debugger I just haven't learned yet.

The visual aspect is also useful for quickly ensuring that I'm really looking at the right data and being able to press print screen, save an image containing most relevant data for later study is also nice.

Awesome :cool

Anyway thanks from a happy user of the feature.

A different brightness of the basic color (yellow) may go well.
It can be useful in some situations, but the real strength of visual DMA debugger is in giving you a glance in real time of the used slots.

For a first look is outstanding and only later the detailed info of the console debugger come in hand (a necessity if you copy/paste somewhere or for an 'offline' study).
But often I realized, as paraj (hi!), that I copy the screen and zoom into with an image editor ;)

Thanks Toni, another happy user.

Feature creep here :)
It would be interesting to have the DMA debugger exactly superimposed to the pixels where it happens.
Also useful to have another layer with the vblank, hblank.

Nice idea (at least in theory) and it probably would look cool :) Unfortunately hblank and vblank regions are never visible on screen (Blank area is blank, there is nothing there, not even background color). Overlaying it on top of visible part should be possible.

It is always possible to show more virtual pixels. E.g. 1024 x 1024 and accommodate the screen, hblank, vblank, color burst and so on in these time units.

Yes but i meant that from custom chipset emulation point of view it does not exist and "overlay" needs to be done in that context, before filtering etc.. makes it impossible to map pixels back to original positions.

I second the request for a bigger 'virtual window view' (i'm wrong or is now fixed at 800x600 in PAL mode?).
With 908x625 You can map and overlay all DMA slots, but a bigger window would not be bad (some fun in programmable beam mode :D).
An initial 'DMA 0 point' could be an option (x and y start in virtual window) or calculated for standard resolution.
(I hope I made it clear what I meant :rolleyes)

[EDIT: and yes, pixels in blank does not exist but You can define a 'virtual color' (selectable in options) and 'overlay' in this virtual pixels]

Bye,
ross

I don't think you understood. Only the fully visible part of scanline exists in memory. Extending/supporting it would lower the performance of emulation, even when not in use. Not going to happen.

I figured that only the visible part was in memory and I was aware that the change would slow emulation.
But absolutely understandable that the change could be ignored. A rough calculation leads to a drop in speed >25%.. Too much :rolleyes
It was just an idea ;)

Thanks Toni,
ross

Following updates added:

Perfect, thank you very much!
:cool

:great Looking forward to giving it a spin

You can already do it if you do some looking around :)

I must be dense, because the latest build I could find was was public beta 5?

Anyway, managed to build latest winuae from github (despite your warnings in this thread http://eab.abime.net/showthread.php?p=1152902) so please feel free to ignore the below comments (I'll recheck in next public beta). Overall it works pretty well, so these are just tiny issues (and it's very likely that the PEBKAC).

* 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)
* It looks like it's not possible to mask idle cycles?
* 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.
* Very very low on the list: the debugger help text hasn't been updated :)

But great work as usual.

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

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

DamienD beated me :)

Same here.

The 'overlay' is positioned few lines down from line 0, giving the problem.

And I like more the yellow copper :p

Great work Toni!
:great