SNES Code Visualiser

SNES Code Visualiser
by mikeyz on 2009-12-03 (#53464)

Hi everyone

This post is to talk about a debugger tool I hacked together for SNES ROMs. I explain it in more detail on my blog so I will copy and paste for you :/

Hello fellow SNES lovers, this post is to discuss my SNES Code Visualiser, otherwise know as SCV. This code was hacked together very quickly, just to show an idea - it's not a finished product and I'd love to hear suggestions for improvements.

OOkay. While I was doing some FZero hacking a while back I kept wishing there was a specific debugging tool that existed to assist me. So I decided to hack Snes9x to add a very unique type of debugger. In fact (and please correct me if I'm wrong) I do not believe any debugger, for any platform, has this functionality - at least, I have never seen it.

So what is it? Basically I started thinking about what it would be like to plot the CPU program counter. I figured it would look like a 'pulse', and I even had a cool name for it, I called it the program counter pulse. In slow motion, I imagined seeing the PC going across the screen, following the same paths again and again. And occasionally new paths would be seen as player input forced different branch and jump logic to become true.

It was that point that stuck to me. What if we could visually identify specific code, as it happens?

The way I have achieved this is by taking advantage of the small ROM page size of the SNES. 16-bit addressing means page size is limited to 2^15 bytes when loROM is being used and 2^16 bytes with hiROM. If you assume the worst case scenario of hiROM, you can actually visually represent every single byte on the page in a neat 256 x 256 pixel square (256*256=2^16)!

To show you how effective this can be, I'm going to run you through an example usage, to find some really arcane code. Since F-Zero is my favourite, let's find the code that is executed everytime a car jumps onto and over a ramp.

Now keep in mind, the old way this would have worked is probably by tracing through the ROM over a couple of days, writing comments on a disassembled listing of the ROM, until you grasp the mechanics of the program enough to isolate events like jumping on a ramp. With this debugger, you can isolate the code in less than one minute.

Please see my blog which has screenshots of the process and more information http://fzerovs.blogspot.com

I will release the source code in the next day or so. I'm really interested in hearing your thoughts on this, because you guys seem to be the only ones still interested in SNES! It's a strange passion and most people just don't care so it's really great to be able to contact people like you guys!

Michael

by Dwedit on 2009-12-04 (#53467)

FCEUXD had something like that, but not graphical.

by smkd on 2009-12-04 (#53475)

wow, active F-Zero hacker. I gave up on my editor because I knew barely anyone would ever use it. I liked making it but I was working towards a fruitless end result. Atleast Fuzee guy came in to save the day, his ended up being more usable then mine would've been.

About the feature, yeah it seems nice for quickly isolating stuff. I just went ahead and did the 'grasping of the game mechanics' since it gave me a much better idea of how everything worked and how I would go about modifying / adding certain routines. If I wanted to just go in and pick out the code for some obscure action though I'd probably find your/the FCEUXD equivalent method useful. nice.

by mikeyz on 2009-12-04 (#53476)

I wouldn't call myself an active f-zero hacker, i only worked on it once, and that was kinda out of nowhere.. and I haven't done anything since, but yeah I remember seeing your post on the map editor and was disappointed by how little reception it was receiving, people aren't so interested in 15 year old games anymore :/

Anyway, thanks for pointing FCEUXD out to me. I downloaded it and found an option to "log only newly mapped code". I tested it out and indeed it does do the same thing as my code, except for NES instead of SNES, and not graphical. Oh well!

by byuu on 2009-12-04 (#53477)

mikeyz wrote:
"log only newly mapped code"

You mean trace masking? If so, I've had that forever. Does Geiger's not have that or something?

by tomaitheous on 2009-12-04 (#53481)

That's cool

On a related note, I did some hacking/investigating on a CD game for the PCE (Gate of Thunder, a shooter). When browsing the ISO/data track in a tile editor, I was able to identify patterns to the game code/levels/scripts/etc. By corresponding all the addresses with the known level offsets and the visual aid, I was able to find a hidden level in the CD (fully playable, but the script starts you off at rearranged boss) and a partially unfinished level as well. And because it was visual and in nice set patterns, I could copy blocks with the tile editor and rearrange level layouts (thus accessing the hidden level and parts of the unfinished level). Doing a binary compate from the japanese data track to the US one, I was able to see that the developers used/knew about the hidden level (but nothing about the unfinished, well - assumed because there was no modification to the code). Cool stuff

Anyway, visualization is great idea. Be it monitoring data or looking for non code specific data (it's easy to see the difference. Code almost never has a pattern - looks random. 16bit WAVE files really stand out when viewed with PCE's sprite mode. So much so and unique, that I was going to write a lossless compressor to see if it can take advantage of it). I think a large bitmap visualization of rom/ram on a play through of a game would be awesome. One color for non access, one color for read, one color for write, one color for read & write. A play through of a game would reveal unused areas of ram/rom/etc (the whole cpu external address range).

t
by mikeyz on 2009-12-04 (#53491)

byuu wrote:
mikeyz wrote:
"log only newly mapped code"

You mean trace masking? If so, I've had that forever. Does Geiger's not have that or something?

Geiger's also has functionality like in FCEUXD. I guess the difference between my tool and the above two tools is that they only log new code, whereas my tool starts logging newly generated code and then displays the total trace (not just new code), specifying the new code in green and the old code in red. An example of why this is important is say the newly generated code just modifies a memory location, and then existing code branches based on this memory location. It is important that you can see this existing mapped code in the trace, not just the new code.

Also Geiger logs to a text file which is really annoying to work with, it should be displayed on screen (maybe I haven't set the options right?).

I could not see any "trace masking" functionality in the bsnes debugger v0.055, how do I find it?

tomaitheous wrote:
And because it was visual and in nice set patterns, I could copy blocks with the tile editor and rearrange level layouts (thus accessing the hidden level and parts of the unfinished level).

That is awesome!

tomaitheous wrote:
Anyway, visualization is great idea. Be it monitoring data or looking for non code specific data (it's easy to see the difference. Code almost never has a pattern - looks random. 16bit WAVE files really stand out when viewed with PCE's sprite mode. So much so and unique, that I was going to write a lossless compressor to see if it can take advantage of it). I think a large bitmap visualization of rom/ram on a play through of a game would be awesome. One color for non access, one color for read, one color for write, one color for read & write. A play through of a game would reveal unused areas of ram/rom/etc (the whole cpu external address range).

My original idea was to have this functionality not just for ROM execution but also for ROM reads (data, constants etc) and RAM read/writes. And I was going to have each pixel fade over a given time, so things that are only accessed early on will slowly disappear from the pixel view, whereas memory allocations that are "hot" ie. always being accessed, will not fade.