-
-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory heat maps #827
Comments
@dirkwhoffmann coppenheimer is the name of the web port 🤓 the person behind this seems to be @losso3000 |
Wow, that was fast! :) (Thanks to both of you for your stellar emulator and browser work, by the way.) A little remark: In Coppenheimer, I didn't really implement a heatmap in the traditional sense (or in the way WinUAE does it with the "vh" debugger feature, highlighting the most recent blitter, bitplane, audio and CPU access locations). Assuming you're talking about the smaller memory overview section, I'm just using sparsely sampled memory contents here to crudely map them to different colors. That was easy to do, looked pretty, and even helps to distinguish different data blocks a bit. |
@losso3000 Before you mentioned it in your post about Coppenheimer, I'd never heard about the heatmap feature in UAE. I cannot try it out since I don't have easy access to Windows machines. Do you know, by chance, if there is a YouTube video showing how it looks in practice? I want to gather some ideas about how a pleasant heatmap could look. |
Sure: https://heckmeck.de/winuae-vh.mp4 (audio crackling b/c my machine is too slow) |
Some preliminary findings: The 1D/2D issue could be solved by rearranging the address space, e.g., by doing the same as Karnaugh-Veitch diagrams do in Boolean minimization (there, a 1D truth table is mapped to 2D in a way that assures certain neighboring properties). A corresponding mapping can be achieved like this (code is for a 64KB address space): for (isize i = 0; i < 65536; i++) {
isize x = 0, y = 0;
if (i & (1 << 15)) y += 128;
if (i & (1 << 14)) x += 128;
if (i & (1 << 13)) y += 64;
if (i & (1 << 12)) x += 64;
if (i & (1 << 11)) y += 32;
if (i & (1 << 10)) x += 32;
if (i & (1 << 9)) y += 16;
if (i & (1 << 8)) x += 16;
if (i & (1 << 7)) y += 8;
if (i & (1 << 6)) x += 8;
if (i & (1 << 5)) y += 4;
if (i & (1 << 4)) x += 4;
if (i & (1 << 3)) y += 2;
if (i & (1 << 2)) x += 2;
if (i & (1 << 1)) y += 1;
if (i & (1 << 0)) x += 1;
// (x,y) is the coordiante of address i in a 256x256 texture I've already done some experiments with VirtualC64 to see what happens when a heatmap is overlayed on the emulator texture (similar to the DMA debugger approach). I have to admit, the result looks 🤢 heatmap.movGiven the unsatisfactory results, I've made the decision to discard the overlay idea. Instead, I will now focus on integrating the heatmap within the memory panel of the inspector. Let's see how it unfolds... |
Update: This is how the new prototype implementation looks like in VirtualC64 5.0b1. Looks much better than the texture overlay... heatmap.mov |
I've just come across this new web port of vAmiga by @coppenheimer, which looks very promising.
One of its standout features is memory heat maps, a feature that could greatly enhance vAmiga's capabilities if supported natively.
There are two main reasons for this project:
The text was updated successfully, but these errors were encountered: