News:

Don't forget to visit the main site! There's lots of helpful docs, patches, and more!

Main Menu

[ALTTP, SNES] Dissasembly Project

Started by wiiqwertyuiop, November 28, 2011, 09:52:18 PM

Previous topic - Next topic

wiiqwertyuiop

Hello I'm looking for a few people to help me disassemble The Legend Of Zelda A Link To The Past. For those of you who dont know what it means to disassemble a game, it basically means taking the assembled code of a game, and putting it in its raw format, in this case 65816. Which means you'll need SNES ASM knowledge to help with this. So far I have a few RAM Addresses written done (note: these are subject to change), along with a decent start on this dissasembly itself: Link. Here are the ways you can help:

1. Finding out what ram address do, and posting them here.
2. Choose a bank and disassembling it.
3. Commenting on things that haven't been commented on.

I would also like the format to be this when disassembling:

CODE_XXXXXX: YY YY ...  ZZ... {tab} {tab} {tab} ; Any comments you might have.

The X's are the snes address. The Y's are the opcodes in assembled format. ZZ's are the opcodes.

Also note that we are using the snes9x debugger to do this, since its the best on I could find, and its not that great so make sure you do a little at a time, and to check over things that to make sure they make sense. Well thats it, please help if you can, as a zelda hacking community might start from this!

Edit: Also note that its preferred if it were in xkas format, since thats what it will be converted to in the end, but feel free to use other assembler formats.

Edit2: WIP VRAM Map!

MathOnNapkins

I don't really advertise it anymore, but I've done basically that for years, and I'm about done with it. At least, the code aspects of the rom, not all the data portions, but I have made some progress on those too. I'll do a diff of all the docs I have on various machines to try to get together a latest revision so you can take a look. The code is intended to be xkas v0.06 compatible, but is not finished yet as it's a very large amount of stuff to sift through. If you'd like to work in tandem on finishing it please let me know.

wiiqwertyuiop

Oh, yeah defiantly. Have you commented on any parts? And have you got any RAM addresses? Whatever is needed I can try to help with.

P.JBoy

What you can do is run a trace with the 'trace once' option in Geiger's snes9x and play through as much of the game as you care.  You can also dump the usage file, which will give you what of the ROM and RAM is data and what is code (or mixed) (that has been used)
...

wiiqwertyuiop

#4
Updated the links. Also started a WIP VRAM Map!

MathOnNapkins

#5
Documentation

Source

Please have a look at these before you go any further. I know you might be having fun but I'd hate to see you waste time on stuff that's been known for years.

edit: Some may wonder why I included Anomie_Reg.log in the documentation. The reason for this is that even though it's not my document, I have updated it somewhat with new information I've found and clarifying explanations in select places. People familiar with the anomie doc may find a few things of interest in it if they run a diff between it and the original.

Also, I should clarify some of the documents' purposes.

-Zelda_3_SRAM.log describes all the variables found in each save slot, such as which items you have obtained.

-Zelda_3_RAM.log describes the rest of the game's variables. That is, it attempts to describe all locations from $7e:0000 to $7f:ffff, even noting where there is unused RAM. sections that are unused are conventionally labeled as "free ram" for consistency and ease of locating them by a search.

-Zelda_3_ROM.log Attempts to describe data sections of the rom that would be more useful for an editor to access and manipulate. It hasn't been updated as much as the other documents, so some of the information may be incorrect or incomplete.

-Zelda_3_VRAM.log A brief document that explores the typical layout of VRAM, expressed in byte addresses rather than word addresses. As a reference it works well enough, as these settings don't ever really change throughout the game. One thing not explored is Mode 7 (as in, the game's overworld map), but if you know anything about Mode 7 graphics it really doesn't change anything in this document. Once the game pops out of Mode 7 these settings remain the same.

-dungeon_objects.log is a document that tries to sort out some of the more infuriating aspects of the dungeon object system. It's not essential knowledge, but may be mildly informative if you're interested in how some of that stuff works.

-Zelda_3_Special_Effects.log is another "attempting to sort out insanity" document that is probably not that useful to most. The special effects in question are a class of usually inanimate (in a real world sense) game objects that act as supplementary sprites. Examples of these include the hookshot sprites, the boomerang, Link's bombs, Link's bed spread at the beginning of the game and his sleep 'Z's, the flute bird, the weathervane explosion, etc. My more modern term for these things is "special objects". As you can probably guess, this document has not been kept up much, and it was mostly used to explore how to rewrite Link's bombs from scratch.

-65816info.log thrown in there for the hell of it. I don't remember if this one is any good or not as a 65c816 tutorial.

-65816.html Old 65c816 synopsis I found on the internets years ago. Perenially useful for looking up opcodes and cycle counts.

P.JBoy

Woah, how long have you been working at that, MathOnNapkins?
...

MathOnNapkins


wiiqwertyuiop

Wow, this is really great! I think what I'm going to do is organize some things, make some things clearer, and so on. I aiming for a all.log type dissasembly, but this will definitely be helpful.

P.JBoy

Separate documents would be much more useful; I would suggest making all the subroutine calls link with HTML though, maybe even add some javascript for hiding sections of text, such as raw data
...

MathOnNapkins

Quote from: wiiqwertyuiop on November 30, 2011, 11:42:23 AMI aiming for a all.log type dissasembly, but this will definitely be helpful.

Holy crap, that thing is ginormous! Incidentally, I started off doing something like this until I ended up with an RTF file that was so large I had trouble scrolling around it or even adding lines to it. That's when I decided to split it into banks. I was doing all the coloring of syntactic elements manually in the RTF files. Eventually I got away from that and converted them to .asm files with the intention of making a reassembleable xkas v0.06 project. That's still WIP, obviously. If you want syntax highlighting for these, I'd use something like Notepad++ or a similar high powered text editor. I can export my settings for that if you want. One of the themes looks this.

wiiqwertyuiop

Well, do you think we can talk on the IRC sometime, to plan what we are going to do? I added a few thing to the RAM map, but i think that could use some fixing up.

wiiqwertyuiop

Well, i'll be willing to do what ever the next step is, so what ever we need to do next just tell me.

Qactis

Quote from: wiiqwertyuiop on November 30, 2011, 11:42:23 AM
I aiming for a all.log type dissasembly

I plan to start something along these lines for Super Metroid very soon, using PJBoy's disasm log

wiiqwertyuiop

#14
Bunch of releases:

The first one i'll show is the one I want to be the main focus of the thread: Link.


Yep thats right, a complete dissasembly of ALTTP. It took me over three months to complete and I have been done with it for about two month. It hasn't been commented on a whole lot yet but I plan to do more and hopefully I can get some people to help as well.

Edit: Smaller download.




Next I have this. This is a status bar editor made by Vitor Vilela so I really would like to give most credit to him (all I did was give him addresses that needed to be changed). Here are some screen shots:




(I hope that first one isn't too big...)




For my third item I have this. It is a custom sprite inserter I made by myself, and I must say I am quite proud of it (considering its the first helpful tool I made). There is a tutorial I made here on how to use the sprites, as well as making them, if you are interested in using it.



Video.




Last I have this. Basically this is a patch which enables a code to run every frame in a level, and a per level basis. It also has the ability to make a code run once during level fade-in.

And thats about it. I also have a forum here if you are interested (you can also find a few other things I made there). Hopefully more people will start hacking the game!

If you are interested in helping with the dissasembly, even if it is just a small routine, or just want to talk to me about something feel free to join #zelconst on EsperNet. Thats it, enjoy!

MathOnNapkins

While I do think your disassembly is a neat alternative to mine, and I can probably learn a thing or two from it, have you considered compressing it before uploading it? It's an 11 megabyte text file, after all :neutral:. A quick test showed that 7zip, even with just normal zip mode can get it down to about 1.6 megs (13% compression ratio).

ICB

Oh, please please PLEASE work support for the sprite tool into black magic.  :grin:

wiiqwertyuiop

Quote from: MathOnNapkins on May 04, 2012, 05:41:26 PM
While I do think your disassembly is a neat alternative to mine, and I can probably learn a thing or two from it, have you considered compressing it before uploading it? It's an 11 megabyte text file, after all :neutral:. A quick test showed that 7zip, even with just normal zip mode can get it down to about 1.6 megs (13% compression ratio).

Well if i'm just looking at the file I usually just look at it through my web browser. But I could compress it I suppose and supply both download links.

QuoteOh, please please PLEASE work support for the sprite tool into black magic.

I hope he does, his editor is the only one still currently being worked on.

XaserLE

This is very interesting. Good to see that there are still people working on alttp.
I decided to use SePH's ROM "Gates of Darkness" and see how far i can come with editing. It would nice to make use of your knowledge for some asm things to implement a few things known from "Parallel Worlds" like making BG1 or 2 disappear by pressing some buttons, refill the magic meter automatically and prevent the bosses from giving a heart container.
I find editing with hyrule magic much easier since i use my extender for the room header. I also implemented the planes yesterday and that brings me to MathOnNapkins ZeldaDocs.
@Math: Maybe you know it now, but if not --> in the ZeldaDocs the planes are not clearly described and i read that plane 3 is eventually unsecure. I figured out that the planes are important for the position of the door. Plane 0 and 1 belong to BG1 and plane 2 and 3 belong to BG2. You can position a door at the edge or a small piece before (in that case you have a second wall/edge that makes the room look deeper). Plane 0 is for the door that is at the edge and plane 1 for the door a small piece before the edge cause this door is more near to the room center and so the engine puts link to the right position. Same goes for BG2 but vice versa. Here plane 2 is that one for door a small piece before the edge and plane 3 for the door at the edge.