Patching SNES9X to simplify MSU1 hacking...

Hi !

I am looking at doing the following changes to Snes9x and create a version allowing to make MSU1 patches more easily.

I looked at the tutorial videos and here the following ideas I have :

- Put a time stamp and log all the jump subroutine / return sub routine instruction.
(= know the call stack at anytime, including register state dump for each jump)

- Put a time stamp (time + emulation clock) for each APU write access and LOG the callstack when it happens.

- Tell the tool that the BGM have changed manually, or that a SFX has been played.

Dump the data into a file, which is loaded by another tool (or we could plug some DLL, whatever...)

By playing the game a few minutes, it should give enough information to track down the playing routines. Display those information into a GUI with a timeline, it will be easy to make the difference between data transfer and call to the play routines.

Do you think my approach is too optimistic and that it will not work, do you foresee any pitfall (the one I could foresee is stack messed up by NMI and other IRQ) ?
Anyway, if people with hand-on experience would give me a feedback on what could be automatically tracked, what is missing from my list, that would be nice...

Cheers.

Seems like something you'd want to ask @qwertymodo.

*edit- and apparently tagging doesn't work on here...

These kinds of debugging features would be much better suited for bsnes-plus, which already includes a debugger. But honestly, most of this is far more complex than necessary. A stack trace would certainly be handy, but a breakpoint on $2140:3 will get you 90% of the way there. I can certainly understand where you're coming from, but you're proposing hours of work to save minutes.

Hi Qwertymodo !

Thanks for your follow up and opinion (and sorry for my late reply, been busy for a while)

I watched a tutorial video posted here, and saw the person spending like 2 hours and still did not complete finding easily the routine playing the audio. Sure there are may be skills difference between person too...

I also agree that it is an investment in time (a few days of coding indeed), but :
- I do it for fun, and it does not bother me much.
- It makes the job easier for people who can not read super fluently asm code on the fly...

Anyway, I generated a graph for the execution log of F-Zero and I post the PDF here.
I colored the box in R,G,B when PPU (red) / APU (green) / CPU (blue) registers are touched (read or write for now).

Blue line are JSR call => A blue line indicate a function call.
Yellow line are conditionnal jumps.
Black line are straight jumps.
Dotted line are "label" (a jump splitted a block in two).

I think it allows anybody to very quickly pin-point where the APU is adressed (green), and where the function start and how it is called (from other function, etc...)

My code is still buggy (look at RTS having multiple arrows ;-) ), and still generate assert in my check logic sometime. It is also not optimized at all and get slower and slower over time being O(n) but I can easily make it O(1) once everything will be in place.

Anyway, I hope that, even if you don't find it really usefull, at least you enjoy the code flow. ;-)

Cheers.

EDIT : AHH... MY ACCOUNT IS LIMITED TO 0.2 MB ! CAN NOT UPLOAD THE PDF :-(

I'm not sure if the board is set to block links from new members or what, but I can't find any link to your PDF.

Ok, FF6 boot screen generate a PDF less than 200 kb.
GREEN is PPU. Enjoy !

The presentation (ordering of nodes ) is not really good, I do not give priority to the adress but the order of code execution / discovery. But I think it has some potential...
Easy to see subroutine, block of coding touching the APU (and only APU if green component ALONE).
(Reminder : PPU is red component, CPU reg is blue component)

I raised the allowed file size from 200kb to 1MB, but keep in mind that this forum is restricted to 20 MB in total (since we luckily deal with retro games where files don't get large generally and pics are stored extern we are at 33% - 0r 7MB somewhere now).

But if Users overstrain the space too much I will be forced to delete the larger files sometime in the future, so better is to post small files in general or store larger files somewhere extern. Or best, users delete their large files themselves if they done their duty and the persons of interest have seen them.

Thank you. I will manage to post my files on googledrive on something and put links only then. Did not know you were running with such limitation, sorry for disturbing you with such petty things.

Anyway, thanks for the upgrade. I will try to give you back the space anyway soon and repost with links instead.