06 January 2016, 22:22 | #21 |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 9,033
|
|
07 January 2016, 15:37 | #22 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,609
|
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. |
08 January 2016, 13:56 | #23 |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
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? |
08 January 2016, 14:55 | #24 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,609
|
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. |
09 January 2016, 06:26 | #25 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
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. 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. |
|
09 January 2016, 17:39 | #26 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,609
|
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
|
10 January 2016, 15:11 | #27 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
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. Last edited by ReadOnlyCat; 10 January 2016 at 15:17. Reason: Added Git possible operations.. |
|
25 June 2024, 15:13 | #28 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 50
Posts: 214
|
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>]] Code:
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 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: Code:
>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 vhis only for result output after collecting some data The list > vh?could be formated like this: Code:
>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 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.) Code:
3,0: 00eeee00 * Copper ... >vm 3 0000ff00 3,0: 0000ff00 * Copper ; change to green I get different percentege results if I switch between >vh and >vh-1 and back >vh and >vh-1 ... Why? Code:
>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 >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? Code:
>vhd 0: 00DFF000 - 00DFF1FF (512) RWI NONE 1: 00000000 - 0007FFFF (524288) RWI NONE 2: 00C00000 - 00C7FFFF (524288) RWI NONE Heatmap enabled vhI get a output with 30 lines. Code:
>vh 001: 00c001e8 - 00c001ff 00000017 (23) 11.24072% 002: 00c00240 - 00c00257 00000017 (23) 8.82821% ... Code:
>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 > 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? |
06 July 2024, 03:01 | #29 |
Registered User
Join Date: Jun 2024
Location: Uruguay
Posts: 29
|
I would like it to have an option, with an image with guide lines of the image box of the actual field of vision of the Commodore Amiga, that is, the real edge of vision marked with lines and in the center of the screen as you should see at the edges , if due to some bad configuration you do not see those lines you are losing field of vision and you do not know it. (It happened to me, I realized because videos of x games on YouTube that I played showed a more complete image)
Another issue would be to be able to move the list of configurations up and down within the list to access them more easily. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Feature request | TenLeftFingers | support.FS-UAE | 12 | 08 April 2014 20:41 |
Feature request | Galahad/FLT | support.WinUAE | 5 | 12 February 2013 19:38 |
feature request | Mad-Matt | support.WinUAE | 4 | 25 January 2007 09:22 |
Feature Request | Npl | request.UAE Wishlist | 5 | 02 August 2004 21:43 |
Feature request | Fackamato | support.WinUAE | 48 | 26 February 2004 17:23 |
|
|