Originally posted by Sky Troopa

---

I know :
1.) Czech
2.) English (Good reading , bad listening)

Know somebody Czech too ?

_________________________________________
Try to translate this :
Ahoj , jmenuji se Sky Troopa. A kdo jsi ty?
_________________________________________

Do you understand this?

---

Originally posted by francoispress

---

Originally posted by FloBo

---

@darth mole: Uhm,... about tracing, I think there are quite many motivated hackers who just don't know how to trace efficiently.. me included. If I want to trace, I try something. And I don't succeed. Then again, I try, and nothing seems to work. When I finally get a Tracelog (like once D4S created for my Lufia-issues), I seem to be so confused that I can't get any idea on how to interpret what happens during that code-segment...

Are there no simple tutorials about how to trace data with geigers SNES-debugger?! I really do want to learn how to handle this.... But seems like I'm just too stupid...

---

Assembly is a bitch. That's why I never took to machine code. Has anyone disassembled
Super Mario World sucessfully? Is there anything in that code that looks like a subroutine?
I wonder if Nintendo's programmers used assembly when making Super Mario World. Do you think they also could have used C?

---

/ JSL instruction, you know is a subroutine (unless, of course, you were unlucky and disassembled a piece of something that was no 65c816 machine code, like, graphics data).
Disassembling, tracing, writing your own assembly code etc. is the everyday work of an ambitioned SMW hacker, you know.
As for C, I am not sure. Chances there are they did, but even if it is the case, they used an extremely optimizing compiler so, in most cases, chances to recover C code are not present.
Yet, there actually are some places in the coede that look like they originally weren't written in assembly. A good example for this is the sprite handler sub-fork routine (noticed that, in mw reconfigurator, many entirely different sprites had the same handler routine pointer?). Every sane asm programmer would have placed a location table somewhere in ROM and done indirect jumps to the actual routines. However, this piece of code looks like this:

CMP #$12
BNE #$04
JSL $123456
CMP #$13
BNE #$04
JSL $789ABC
CMP #$14
BNE #$04
...

or, transscripted as it would look like in C:

if(sprite_id==0x12) HandlerRoutine12h();
else if(sprite_id==0x13) HandlerRoutine13h();
else if(sprite_id==0x14) ...

Note that, in C code, this just looks like the work of a lazy programmer, while in assembler, the lazy programmer certainly would have chosen the pointer table variant (as it is significantly easier to code).

(This piece of code, actually, is one of the locations I am currently rewriting to make SMW capable of handling more sprites at a time. While d4s just patched most of the time-critical routines to FastROM (thus making the processor frequency the 65c816 runs at itself increase locally), I am (also) optimizing the actual SMW code by cleaning up useless process cycle wastes like this)

Geiger/Evil Peer's SNES9x tracer is mostly self-explaining. What you simply should do is:
- setting a "start address" and an "end address" in one of the dialog boxes of the "Trace Menu"
- pausing the game and clicking on "Trace" in the same menu when you reached the position you want to trace at
The tracer will wait until the 65c816 executes the code at the "start address" the first time, dump some few previously executed instructions and continue dumping every instruction executed until it reaches the "end address".