Feature request [Heatmap]....

[Galahad/FLT]

Originally Posted by Toni Wilen

Probably not worth the trouble, it is easy to ignore manually.



Do you mean listing all addresses that were "hit" by copper only or audio only, blitter only (all, reads only, writes only) and so on? That could be useful.

Yes.

[Toni Wilen]

Also done.

- all chip ram and slow ram is now supported.
- visual part is now optional
- Any DMA channel (and more) accesses can be listed.

Initial enable command "vh" (enable) or "vh -1" (enable visual mode)

After enable:

vh [ratio] [number of lines] = list CPU instruction access info (like previously, but does not clear collected data anymore)
vh <name of channel> [number of lines] to list all addresses that channel has accessed

Examples:

vh cop = list all copper accesses (includes also copper writes to custom registers)
vh bltd = blitter D channel accesses only (bltdn = normal D channel mode only, bltdf = fill, bltdl = line)

CPU accesses: cpu = all, cpui = opcode fetch, cpud = data access, cpudr = data reads only, cpudw = data writes only.

and so on.

vh ? lists all possible channel modes. Same channel mode strings are also supported by memory watch break points. (Memwatch already supported most of them but some are new)

number of lines = 0: list everything.

vhc = clear collected data.

[ReadOnlyCat]

It seems like Toni is unstoppable once he has started to work on a new feature.

Btw, Toni, I cannot see any corresponding commit on the GitHub repository. I looked for available branches for this development but only master is available. I assume you are working on local branches?

I want to use the feature on OS X so would it be possible to make these commits available? A dedicated branch would be ideal I guess if you do not want to pollute the master branch with a not-yet-official code base initially?

Thanks in advance!

My plan is to merge the corresponding commits in a recent FS-UAE dev version so I can use the heatmap on OS X. Hopefully, Fröde can then pull the adaptation straight into his branch afterward.

Also, the fact that WinUAE has only a "master" branch got me puzzled: do you always work directly in master for new developments? I assume you have local branches to avoid stepping on your own toes between beta versions, fixes for the released version and various new developments but the history shows only commits to master.
Do you always merge these different histories back to master before pushing to GitHub?

[Toni Wilen]

I just hack this thing until it becomes something I want it to be (don't try to suggest anything, I won't listen), everything that is part of low level emulation code is far too inter-connected. Especially debugger which needs to connect to every part without causing extra slow down when not in use.

It is now the phase between betas where lots of major changes will be done and when I have no idea when things are stable enough again.

Anyway, next beta should be out by next sunday.

[ReadOnlyCat]

Originally Posted by Toni Wilen

I just hack this thing until it becomes something I want it to be (don't try to suggest anything, I won't listen), everything that is part of low level emulation code is far too inter-connected. Especially debugger which needs to connect to every part without causing extra slow down when not in use.

It is now the phase between betas where lots of major changes will be done and when I have no idea when things are stable enough again.

Anyway, next beta should be out by next sunday.

Ok, thanks for the info, I will grab the sources next Sunday then!

I had not realized that the "3220" commits are related to the beta versions of 3.2.2 and this just dawned on me while browsing the commits a few minutes. Silly kitty.

I asked because it is frequent to use branches to split work by functionality to make it simpler to track multiple things concurrently so I assumed that is what you did on your local Git repository. Also since the version is in beta I assumed that you would not add low level modifications which might reduce stability hence why I thought you had a local branch but everyone has their own workflow and now I understand how yours work.

Originally Posted by Toni Wilen

(don't try to suggest anything, I won't listen)

This part confuses me. What do you mean?

I am not sure if you are talking about the architecture of the code, or source control workflow, or general collaboration. I do not think you are implying that you do not welcome coordination or that you are opposed to any change by principle so clearly I must be misunderstanding what you are referring to.

Just to make myself clear in case you are referring to something I said that was not clear (and this would not be the first time I said something unclear) my interest is just to bring to get the heatmap on OS X so I just wanted to know how you managed these commits.

If you think branches are a good idea (or not) for coordinated work, well, I am sure willing to listen to your suggestions but for my use case and given that you are likely quite busy with the beta I have no need for it at the moment. I was just curious.

Thanks again for the update, I will be eagerly watching overt Github.

[Toni Wilen]

Done. debug.cpp and debug.h are the main files. Then try compiling and finding all changed calls here and there until no more errors

[ReadOnlyCat]

Originally Posted by Toni Wilen

Done. debug.cpp and debug.h are the main files. Then try compiling and finding all changed calls here and there until no more errors

Nice! Thanks.

After a cursory look, the heatmap code seems simple enough to isolate from the rest. Now I can only hope that the FS-UAE dev version is not too distant from this last commit. I will probably create a branch from an ancestor version to the latest FS-UAE version and the beta, which I will then merge your last commit to, excising only the heatmap related code. Then if Frode wants it he will be able to pull that into the dev version.
I am not too sure it is a good idea though because I don't know Git's algorithm well enough to figure out if it would handle well potential merges back into WinUAE but that is a problem for later times.

Unfortunately I must work overtime this weekend so I won't be able to touch that today. Maybe later in the week if I can free some time in the morning.

Thanks again for the update.

[Rock'n Roll]

Please do not pay any further attention to this post at present, but perhaps in due course?
In the moment, I don't found for me the big benefit for the heatmap while debugging. (Maybe for a own group of demoeffects - heatmap demos?)
Nethertheless some points to optimize.

"offical" helptext is: vh [<ratio> <lines>] "Heat map" - but I believe this helptext is wrong?

Heatmap command in reality is: vh [ -1/?/c/d/h ] | [<channel> [<lines>]]

vh   = enable heatmap or output
vh-1 = enable visual mode (chip ram region)
vh?  = lists all possible channel modes
vhc	 = heatmap data cleared
vhd  = Heatmap disabled
vh cop		= output cop memory access (max 30 lines)
vh bpl 5	= output bitplane memory access (max 5 lines)

>vh	
 0: 00DFF000 - 00DFF1FF (512) RWI NONE			; custom chips
 1: 00000000 - 0007FFFF (524288) RWI NONE		; chip ram
 2: 00C00000 - 00C7FFFF (524288) RWI NONE		; slow ram	
Heatmap enabled

vh sets automatically three "null" memwatchpoints! Fine.
But the optional visual mode (vh-1) is only available for the chip ram. Maybe it could be expanded to vh-2 also for slow ram?
Or, another idea, like >v:

>v-1	; without visual mode
DMA debugger enabled, mode=1.
>v-2	; with visual mode
DMA debugger enabled, mode=2.
>

change to:
>vh-1	; without visual mode
Heatmap enabled, mode=1
>vh-2	; with visual mode		>vh-3 ; for slow mem region
Heatmap enabled, mode=2

and then >

vh

is only for result output after collecting some data

The list >

vh?

could be formated like this:

>vh ?
ALL NONE DMA BLT BLTD AUD BPL SPR CPU CPUD CPUI CPUDR CPUDW
COP BLTA BLTB BLTC BLTDN BLTDL BLTDF DSK AUD0 AUD1 AUD2 AUD3
BPL0 BPL1 BPL2 BPL3 BPL4 BPL5 BPL6 BPL7 SPR0 SPR1 SPR2 SPR3
SPR4 SPR5 SPR6 SPR7

colors:
CPU: brown (I see no different colors?)
I read: "separate color for CPU instruction (pink) and data accesses (brown)." but there is only brown.
copper: yellow
audio: red
bitplane: blue
blitter: turquoise
disk: white

I missed: sprite - purple and blitter - turquoise ,nothing to see:
The colors are not changeable with >vm. (The changes are only for the visual Agnus DMA Viewer.)

3,0: 00eeee00 * Copper
...
>vm 3 0000ff00
3,0: 0000ff00 * Copper		; change to green

results:

I get different percentege results if I switch between >vh and >vh-1 and back >vh and >vh-1 ... Why?

>vh
001: 00c001e8 - 00c001ff 00000017 (23) 12.57679%		; $17=23	($1ff-$1e8)
002: 00c00240 - 00c00257 00000017 (23) 10.45475%
...
>vh-1
001: 00c001d8 - 00c00207 0000002f (47) 27.73755%
002: 00c00230 - 00c0025f 0000002f (47) 22.45758%
...
>vh
001: 00c001e8 - 00c001ff 00000017 (23) 12.57679%
002: 00c00240 - 00c00257 00000017 (23) 10.45475%
... and son on

normally use order is:

>vh or > vh-1 ; enable heatmap
>x (or >g) ; collect some data
>vh ; every vh after enabling outputs now the collected percentege memory access...
>vhc ; free the collected heatmap data
>vh ; every vh after enabling outputs now the collected percentege memory access...
>x (or >g) ; collect some data
>vhd ; disable heatmap

>vhd ; doesn't close the visual heatmap
Also, it is not possible to change from vh to vh-1 (visual mode on/off) like >v-1 and >v-2.
To close the visual heatmap it is possible over the visual DMA Viewer: >v-2 and then >vo

also: enable with disable is possible?

>vhd
 0: 00DFF000 - 00DFF1FF (512) RWI NONE
 1: 00000000 - 0007FFFF (524288) RWI NONE
 2: 00C00000 - 00C7FFFF (524288) RWI NONE
Heatmap enabled

What is the default heatmap channel? With >

vh

I get a output with 30 lines.

>vh
001: 00c001e8 - 00c001ff 00000017 (23) 11.24072%
002: 00c00240 - 00c00257 00000017 (23) 8.82821%
...

If I want reduce it to maybe 3 lines, I do the command:

>vh all 3
Mask 7fffffff Name ALL
000: 00000000 - 00000007 00000007 (7) ALL
001: 00000020 - 00000027 00000007 (7) ALL
002: 00000060 - 0000006f 0000000f (15) ALL
>
or
>vh cpu 3
Mask 00000007 Name CPU
000: 00000000 - 00000007 00000007 (7) CPU
001: 00000020 - 00000027 00000007 (7) CPU
002: 00000060 - 0000006f 0000000f (15) CPU
>

but I get a completely different result?

It should be defined if and when both (visual heatmap and visual dma debugger) could be work parallel.
Or if one is enabled the other has to be disabled?