http://fzerovs.blogspot.com/

Sounds like a neat technique.

I have a few comments on this.

1. If you actually read what this does, it doesn't bring anything new to the table. You can already do the same thing with Geiger's debugger. Start the ROM running a trace log with trace once checked. Get up to the ramp point. Turn the trace off. Start a new one. Surprise, you now have a trace log with ONLY those instructions relevant to the ramp. The exact same results minus red and green pixels which are completely unnecessary and irrelevant. The visual portion is nothing more than novelty. It doesn't aid in any additional functionality or methodology. It's process of elimination either way you look at it.

2. Speaking of the methodology. This reminds me of ZSNES cheat finder. It's the same concept. Process of elimination until you are left with only relative information. It also suffers from the same issue when it comes to practicality in it's usefulness to ROM hacking. It's only going to work for trivial items. You're not going to do much remotely complex with it.

3. Speaking of practicality, an experienced ROM hacker could also just use some smart breakpoints and also find those two lines of code in a few minutes. The difference being the traditional methods work on both trivial and non trivial issues.

4. This also reminds me of ROM corruption. Yes, it certainly CAN work, but it's limited in practical application and ultimately the payoff of the traditional skills far outweigh any skill developed with corruption or visualizing when it comes to complete projects and scope of work.

I've been there. I remember what it was like to try and do things without knowing any code and using corruption, pattern finding in a hex editor, process of elimination etc.. Developing skills that can be applied to definitively solve all situations such as traditional debugging skills and hardware knowledge has proven to be far more valuable and ultimately increased my efficiency exponentially.

I can see the value in 'other' methods when you don't know any code or hardware and realistically aren't going to be (or have no desire to) learning it anytime soon. However, here, you have to know game code anyway to do something with the trace file you end up with, so I just don't see any added value in red and green byte pixels other than putting yourself in the Christmas spirit!  :laugh:


MathOnNapkins:

Absolutely. I agree. A source line debugger would be useful. We have those for all assembly programming we do for embedded chips here at work. Debugging dis-assembly of your work and debugging your actual work are very different.

I know for SNES programming I typically have to keep my source window up with the debugger to 'sync' the two to effectively get my own mental source line debugger going.

I certainly agree the more code you get, the more painful it becomes.

The method of visually tracing code reminds me of this (I attended a presentation at DEFCON by the guy who did this):
http://www.offensivecomputing.net/vizsec09/dquist-vizsec09.pdf

It was made for Malware analysis and is kinda useful (for newbies) for identifying unpack loops / main run loops.  If you're trying to analyze anything that's executed once (and quickly, like a single value change)...then you're probably SOL using this technique alone.  It's surely pretty neat and interesting.  The technique is just not ready for prime time use.