I don't think the game you pick matters as much as you might think it does.  I mean sure there are a few games where the code is insanely complex (Battletoads comes to mind), but barring those, I think most games are around the same 'difficulty level'.  SMB seems like a fine place to start.

The big points to understanding assembly are:

1)  Understanding language syntax and/or assembly architecture.  In the case of 6502, this equates to knowing what each instruction does, the differences between addressing modes, etc.  This is the kind of thing that you might learn from a reference doc or tutorial.

2)  Understanding programming fundamentals (what a variable is, what arrays are, what loops are used for, conditionals, subroutines, etc, etc).  This is the kind of thing that you can only really learn through hands-on experience and tinkering.  Tutorials can be a great help in guiding you, but ultimately you'll have to get your hands dirty.

3)  Understanding system architecture.  In the case of the NES, this equates to having a basic understanding of PPU registers, PRG swapping, how to perform simple tasks, etc.  This is the kind of thing you'd learn from a technical doc.


#2 is really the biggie.  Once you've been around the block with a few languages, you realize that they're all largely the same.  The same concepts that apply to 6502 also apply to other languages like Java, C, Delphi, and even QB -- they're just performed differently.  This is why people can read 6502 technical docs all day and not learn a thing since they don't pick up on programming concepts.  This is also why people that have experience in one language can pick up another relatively quickly.

#3 can be put off if you're just looking to do minor/moderate engine tweaks.  Game computations can be modified without any understanding of the system at all.  But it definitely may come in handy.


I would suggest (but I'm sure other people wouldn't agree with me) that instead of focusing on hacking 6502, you just focus on understanding it.  That is -- instead of looking at a game with the intention of changing it into something you want, look at it with the intention of understanding it.  Try to figure out what each instruction is doing.  You'll find that once you understand the code, changing it will usually be straightforward.  Whereas when you try to change it without fully understanding it, you'll end up having lots of "why the hell is it doing this?" problems -- which get very frustrating.

 Hey - if you got #1 down or most of it, then I say just dive in and start experimenting/hacking   

 It'd be nice if there was a forum section just for asm (questions/howto/examples/etc) ... but then again that might be a bad idea if it was a public section 

There's this file called asmlog.txt, which is an irc log. It's somewhere (I think the links are dead) but it's extremely useful and it taught me how to make Mario's lives go up when he dies and some other stuff

Edit: Found it!

Wow! Thanks snesmaster40. This will definitely be helpful.

Smaller does not necessarily mean simpler.

You could reverse engineer Kirby line by line too.  But it's not as popular and is larger so nobody has done it.



I was specifically speaking in terms of the NES where games were pretty much exclusively written in straight 6502 and are thus organized in a logical manner.  I understand and agree that when you extend to further generation systems like SNES where code has gone through a compiler (not to mention the assembly and architecture is much more complex) -- that things get much hairier.


I suppose. 

I always have had a hard time helping people who are just starting out because I didn't start out with ROM hacking -- I came into it with prior programming experience.  So the methods I used to learn my way around wouldn't be of any help to other people.

So I was wrong about game difficulty.  But I still stand by what I said about focusing on programming concepts first and foremost.

You should know at least how to program BASIC and C++.

Maybe, but with the SNES they didn't use a compiler.