old thread

Renewal of SMAS Disassembly

This thread will be used for signups and suggestions for the SMAS disassembly project.

Roy and I decided to accept new people to this project. We both agreed that this has been long, long, long overdue, and that's an understatement. I apologize for this because I was kind of a terrible project leader and kept thinking that Roy and I were enough. Obviously I was wrong.

ROM and RAM maps

The ROM and RAM maps will be available to the public. We have to arrange someone to host the ROM and RAM map publicly, however. Until then, the ROM and RAM maps will remain inside the SMAS disassembly project directory. Once we have an online ROM and RAM map, we will be ditching the 'local' ROM and RAM maps and update the online ones: a resource accessible to anyone.

Update: Online ROM and RAM map

Progress

The SMAS disassembly is mostly done. There's still some work to do though, especially the disassembly of the 2nd half of the ROM. The documenting has to be done entirely, too.

Sign-ups, procedures and guidelines

The SMAS disassembly project consists of a Dropbox directory. Saves will be automatically synchronized with other people. The only limitation is that simultaneous editing is not possible, otherwise you'll get conflicting copy files.

This means that you'll have to download Dropbox in order to participate in this project. It is also recommended that you have some sort of instant communication available. We might create an IRC channel for that.#smasdis is already taken, that is for those who are truly a part of the project.

The IRC channel is the general SMAS hacking IRC channel: #smas on irc.caffie.net

Being part of the project means that you'll be working on various things. This includes disassembling bytes into assembly code, distinguishing tables and pointers, and documenting everything.

The format of the SMAS disassembly will be the same as all.log. This means no tabs. We might turn the disassembly into an assemble-able one in the long run (I like the idea), but it should happen near the end of the project when the documenting is finished.

For those who want to sign up:
1. We'd like to know why you want to help with the project. (This isn't mandatory though)
2. We'd like to know how you could help with the project. What kind of contribution could we expect from you?

Here are the guidelines for joining the SMAS disassembly project. Don't worry, it's nothing scary:
1. Do NOT leak the disassembly files under any circumstances! We don't want multiple versions of the disassembly floating around the internet.
2. Make sure your documentation is correct (of course). If necessary, ask for verifications from other project members.
3. There is no set deadline for this project, so feel free to take your time. I don't want the project members to burn-out themselves.

I'm looking forward to your applications. Even if you think you'll only be a burden to the project, I urge you to give this project a try if you have adequate ASM skills (enough to understand all.log).

To discuss this project start-up, please use this thread instead of the IRC for the sake of archiving ideas and suggestions.

I would be interested in helping with this. I for one would certainly like to see SMAS fully disassembled and documented (and more easily hackable). I'm not sure what I'd do, though...I have not done much in the way of ROM disassembly, and since pretty much all disassembling I've done was done by hand using a hex editor, I have almost no experience with any disassemblers. I'm okay with doing it that way if you are, though.

(And what's the report on MushROMs anyway, if you have any information?)

well of course I'm interested I just don't how useful I'll be. This is one on my favorite games and I would love to help but I don't know what I need to know to be qualify to count as being useful thus my asm skills are just very basic.

I know this won't be for a long time but I would like your to know your thoughts on how you'll make it were you'll be able to hack all the games in all stars because I think I remember there being a size issue.

Okay, I've decided something: We should use something other than RATS tags for marking protected areas once SMAS hacking really takes off. They've worked for a while, but they have their flaws, and frankly, I think we can do better. We could use something that allows more than 0x10000 bytes to be blocked off, for one, or forgo the tags in the ROM altogether and specify protected areas in an external file, like an XML document (naturally, tools would update this as well).