Re: Working on a new Jace debugger feature

[BLuRry <brendan.robert@gmail.com>]

Ok, I've finished the initial implementation of the heatmap thanks to a rather dull hour-long status call that didn't really involve me. ;-)

This thing is BEAUTIFUL!!!

Now all the loose ends are tied up and I'm ready to post a build, but I need some volunteers for some user testing so I can promote it only once I'm sure it's rock-solid. For now this only focuses on active ram, so anything doing bank-switching will show up but only in the sense that you see what is changing to active ram, meaning it doesn't separate activity of aux ram from activity of main ram.  This wasn't really a preference of mine, but I'm too lazy to re-implement this to accommodate for the different banks -- but maybe I will if there's sufficient interest later.

How it works: You configure the metacheat feature from the config page (F4) on the computer (apple //e) node.  The heatmap/memory spy is accessed by pressing the HOME key.  You can select if you want to see activity or values.  If you select activity, you will see a fury of color: More red means that the byte was recently written.  More green means recently read.  Yellow indicates a combination of read/write.  More blue means recently executed (meaning it was read while the program counter was nearby.)  If you see purple blips, you just found self-modifying code!  In order to get a more responsive view you can trim the start/end of the range being watched as well as set the overall zoom factor of the display.

Hover over a square to see its address and value.  Click on it to add a watch to the metacheat search view (press END and flip to the search tab.)  This lets you get a list of watches very conveniently!

Other observations: 
Large swaths of green flashing memory are very likely to be lookup tables.  (Anyone up for re-skinning games?  Well, this makes it stupid-easy.)

Being a visually-oriented person, I'm completely floored.  I mean, I wrote the darn emulator but I didn't realize how busy this thing was all the time.  Even moon patrol, when sitting at the title screen, is going ape with large code loops and memory usage!  Even while paused it's updating its count-down timers and executing large chunks of code.  Amazing.  I could have figured this out in disassembly, but this makes it all so much clearer.

You can also see what happens during a load sequence or a de-crunch.  It's just CRAZY!

-B


On Monday, July 30, 2012 12:19:34 AM UTC-5, BLuRry wrote:
> Heatmap is actually working and the emulator doesn't seem to slow down that much at all!  There's still a bit of tweaking and tuning of the user experience to make it really useful but it's really cool to see what parts of the zero-page go crazy and what parts don't ever change.  It is really awesome to see the effect of a loader and watch large chunks of memory get populated.  Still so much to do here, but now I know I can do it without things getting massively slow so I'm willing to be a little more brave about trying some more ideas before releasing into the wild.
> 
> 
> 
> On Sunday, July 29, 2012 12:32:26 PM UTC-5, BLuRry wrote:
> 
> > Eventually I'll have some way of showing live disassembly that doesn't cause the emulator to slow down as much (full speed disassembly would be impractical not to mention just outright too demanding).  However there is one feature I think I can pull off that won't slow down the emulator too much: Active memory monitoring.
> 
> > 
> 
> > 
> 
> > 
> 
> > Basically, you pick a range of memory addresses and it will update a few times every second to show you either the amount of activity in a heatmap fashion, or a value map indicating what values are stored at each address.  Addresses are laid out in a grid fashion so that if there is a really busy address you'll see it flicker or just stay hot.
> 
> > 
> 
> > 
> 
> > 
> 
> > Of course you would have to be able to move the mouse over the grid to get the information about each cell: address, value, etc.
> 
> > 
> 
> > 
> 
> > 
> 
> > If I can get this working then the next step is detect if the memory being read or written and if it is within 3 bytes of the program counter.  That way I can show read (green), write (red), program (blue) so that you can get a nice colorful outlay of what the program is doing.  For example, self-modifying code would show up as purple!
> 
> > 
> 
> > 
> 
> > 
> 
> > So far I have the overall UI laid out and hooked up to code, as well as the core framework to track activity and update at 30 frames/second.  All that's left is drawing the grid and updating individual cells (redrawing the whole grid would be too much extra work.)  If I'm lucky, it will be a few hours.  If I'm on par with my norm it will be a few weeks of off and on tinkering and maybe a few hair pulling rounds of "why isn't this working yet?!"
> 
> > 
> 
> > 
> 
> > 
> 
> > -B