Super
Mario
World
D\
I| Disassembly
S/
+
Commentary

Definition

This project is going to strive to comment on as much as SMW as we can, so patches are considerably easier. With this, you can see what is going on around you to cancel out or hijack off of. We use this for uploading and commenting on SMW.

History

This project came around early in my ASM career, when I started use the ROM map as a reference point on where to hijack. However, once me and all.log reached where I wanted, I still found myself lost as I had no idea what the code was doing around me and how I would affect it. This has been brewing in my head for a while now.

Joining

Of course, anyone who thinks they have the skills to comment on this jumbled heap of the first real game on the SNES is free to join and pick a spot to comment on. However, you should know that SMW is not as laid out as most sprites and blocks are today. There are going to be a lot of multi use adresses and code spiraling around itself. But if you're up to the challenge, just post where you are going to comment (I would start with <500 bytes) and go for it.

Tactic

There is a art to commenting. You can see it here:
LDA #$02;\ Make mario have a feather/cape
STA $19 ;/
^GOOD^

LDA #$02;\ load 02
STA $19 ;/ to the powerup status
^BAD^

The big defining factor in wether it's a good comment or a bad one is if you can find the intention or overall function of whatever that code is.

LDA #$03;\ load 03
STA $19 ;/ to the powerup address (or worse yet, simply saying "to $19")
(Intention: Uh. Loading 03 into the powerup address? :\
Function: Uh. Loading 03 into the powerup address? :\)

LDA #$03;\Make mario have a flower
STA $19 ;/
(It is easily identifiable what the intention and fuction is.
Intention: Make mario fire mario
Fuction: Give mario the flower, so he can shoot fireballs

The first example provides no insight for future coders, while the latter does. Try as much as you can to keep your code informative.

Optionally, you will find a table:
DATA_00FF93: .db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
.db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
.db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
.db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF

Like that. You could note the beginning byte like so:

DATA_00FF93: .db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
DATA_00blah .db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
DATA_00blah .db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
.db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
and so on.

Completion

Hosting/Process

Format:
Copy/Paste the all.log code and then comment on it for the dissassemble and commentary.
Currently, SMWDISC uses etherpad to host all.log, commented.

- Please DO subroutines, as well. If we can identify every subroutine, the rest of the code is just connnecting them together.
Exceptions apply when it is a complicated code, or you have RL things to attend to, etc.
- You can edit any page of SMWDISC as you see fit, for commenting and corrections OF comments.

But that above policy is a tentative one. If you think we should change it, great. I think we should be more than willing to discuss exceptions, changes, etc.

Currently Finished

This does not supply specific completions, but general places that have been commented. We have a repositiory of stuff not uploaded to etherpad here:
Currently all is updated at the etherpad!

Contributors

Contributions by:
People who have commented code but do not come by often/are new/didn't do a large amount of code-yet. Also those who helped with the project in general.
Smallhacker (Hosting ideas, constructive criticisms, etc)
1024
lolcats439
Roy
YoshiCookieZeus
Imamelia
Nicol Bolas
Buster Beetle
Gekko
Kernigh

Contributors:
People who visit regularly and comment on code often.
Maxx
Edit1754
Alcaro

etherpad.com/SMWDISC can supply a updated list of what people are doing!

Events:

5/30/09: Project Started
6/29/09: SMWDISC offically moves to etherpad
If you have a dedicated server, we could use one- but we have etherpad so it's not serious.
Hopefully this project will flourish, and we can benefit avid SMW hackers in the future. That's our goal.

Contact:

-There is #SMWDISC, a IRC channel on caffie.
-PM any of the really important users on this project
-This thread
-PM me for my email

Supporting

Usually I don't support the fanboy sort of vibe this gives off, but this project could use some propaganda.
Support it in your signature if you'd like.

HTML:
<a href="http://www.smwcentral.net/?p=thread&id=19777"><img src="http://i373.photobucket.com/albums/oo178/alcaroops/541244571966Fixed.png" alt="SMWDISC" title="SMWDISC"></a>
(Credit to Alcaro)

Mod edit: We're not on Badnik anymore.

Before this project begins, I would like to make a suggestion to make it harder.

Nobody makes hacks from the SMW ROM anymore; we all make hacks from the ROM as modified with a bunch of Lunar Magic hacks. Any ASM hack someone makes needs to know about these hacks so that they can avoid/work with them as needed.

It'd be great if this could also list LM's added code.

I am already gathering a list of commented LM ASM hacks, so you could eventually leave that part to me.
Expect a thread in SMW Data Repository (or a post) soon.

(I'll show them regardless of whether you want to include them, or not.)

I'd like to help with anything else about this project, but seeing as I'm still into SMAS dis, I do not have the time for that.

---

--------> Don't follow "Find Roy's Dignity", my hack. Because it's pretty outdated. <--------

I may be interested in helping. Although, it seems a bit disorganized. For one thing, I'm a bit concerned regarding the use of pastebin. Sukasa and I started a similar project a long time ago and we made some progress, but I think most of that information is obsolete. However, we had a pretty solid way to do it: MoonEdit, a real-time collaborative text editor ("multiplayer notepad"). I suggest that someone acts as a MoonEdit (or similar program) server that the others connect to to add/edit stuff. To avoid too big files, we also split the project into one file per bank which worked pretty well.

My Advanced ROM Map on SMWiki (find a backup somewhere) contains disassemblies of a number of routines with varying levels of comments. You can use it as the basis for documenting some routines. I also recommend using that structure for the disassembled code.

One thing annoys me, though:

You've gotta be kidding me. Someone hogging an entire bank (and possibly the most important bank in the ROM too) for almost a year?! If I do join the project, I have no intention to respect this claim.

There should be a limit to the amount of bytes, or even better, the amount of subroutines one can claim at any given time.

When it comes to the amount of subroutines, maybe... somewhere between 5 and 10? It depends on how long the routines are. Maybe really short subroutines (just a few lines long) shouldn't be counted towards the amount of claims... unless it's abused and one claims all the short routines at once.

Although, there's no practical way to make sure people follow this, so maybe it should be a guideline and not an actual rule.

So, my suggestion is having a guideline saying that one shouldn't claim more than 10 subroutines. If the subroutines are really long, one shouldn't claim more than about five.

IIRC, Etherpad doesn't handle big files too well.

I'm here to whine.

1) Lack of seriousness in some places.
(I mean, seriously: "AW JEAH HEAR WE GO"?! "I DON'T KNOWLLLLLOOOLLLLL"?!?!)

2) If you don't know what something does, either don't write anything or figure it out.
"I don't even know what Y is loaded with!"
"again, unknown purpose."

3) Lack of research, even when it's close to obvious on how to find the information.

Yes... Completely sprite-dependent... except this routine is ONLY used by the growing pipes. Hell, even THE LABEL tells you that.

4) Misunderstanding of commonly used programming methods, especially in SMW.

Waste of time? No. What that piece of code does is to push the bank number, push 0x02, pull bank number, jump to subroutine and pull bank number. In other words, it sets the bank number to 0x02 while preserving the old one. This is the standard way of changing the bank number. Didn't you even count the amount of pushes/pulls?

There are probably other things to whine about, but that's all I've got for now.

I just hope you take this strictly as constructive criticism and not a personal attack.

See, the thing is that I'd like to see a professional-looking and as-accurate-as-possible documentation of the SMW source code.

Although, that's just my personal opinion. Since I'm not in charge of the project in any way, I'm just giving my opinion (i.e. whining) and leaving the deciding up to the ones actually leading/working on the project.

Smallhacker is doing the same thing with Xka Shack. It's quite the project, hope you're up for it.





Excellent. I'm glad to see we have a candidate to come give us a hand here.


Okay guys, (all three of us, :p) I have a question: which should be do?

CODE_02B236: 29 01 AND.B #$01 ;\
CODE_02B238: A8 TAY ;|
CODE_02B239: A5 1A LDA RAM_ScreenBndryXLo ;|Enter from either left or right
CODE_02B23B: 18 CLC ;|
CODE_02B23C: 79 B8 B1 ADC.W SIDE_ENTER_XGEN,Y ;|
CODE_02B23F: 95 E4 STA RAM_SpriteXLo,X ;/


or

CODE_02B236: 29 01 AND.B #$01 ;\ Check random value if it is odd or not
CODE_02B238: A8 TAY ;| Odd or not is in Y
CODE_02B239: A5 1A LDA RAM_ScreenBndryXLo ;|Screenboundry+
CODE_02B23B: 18 CLC ;|
CODE_02B23C: 79 B8 B1 ADC.W SIDE_ENTER_XGEN,Y ;| Side to enter from according to the table above
CODE_02B23F: 95 E4 STA RAM_SpriteXLo,X ;/ is the sprite Xpos.


I figured that if you are using all.log you should be able to figure this out for yourself, but not all of us know exactly what that code did, even with basic ASM training. So should we go that in-depth? Should it be an option? Should be not? I don't know if I mind either way, so...

Comments in the code should explain what the code is trying to do. Statement-by-statement commenting is only necessary where the code is unclear. For example, the 3rd statement doesn't need a comment; everyone can clearly see that it is loading the Screen boundary byte into the accumulator. Similarly, the last statement doesn't need a comment, as it clearly says "SpriteXLo".

If it were loading from an "unknown" memory address, then a comment would be appropriate.

Whether you use Gobby or MoonEdit is a matter of taste.

Come to think of it... Maybe Gobby actually is better suited for something like this? Actually, I think it is.

Should I just try a small subroutine to see if this is something I'm capable of, and if I like it, continue? I've never tried disassembling stuff, but I might want to at least try it on for size. Maxx (or anybody else...is there a section of code you'd recommend for me?

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

I have a function that I've commented that I'd like to submit. It has to do with overworld movement from a level tile. It even covers how hard-coded paths work. How do I go about submitting it?