Acmlm's Board - I2 Archive - Rom Hacking - Allright. Im ready to learn ASM.
| User | Post |
DarkPhoenix
Posts: 7/31 |
I don't think getting a good conceptual foundation is anywhere as strange an idea as asking a person to learn something completely irrelevant to his ultimate goals (C++), or for that matter, as cruel as telling them to jump headfirst into material that college CS students often have trouble with, with only amatuer tutorials and reference manuals, regardless of which is theoretically faster (jumping headlong into 6502) or which would provide for the most theoretical background (C++).  Ideally one would go straight to 6502, but I've yet to see a 6502 document that's anywhere near as thorough, or for that matter comprehensible as a book on x86. Sure, it's another language, and it's not exactly like the 6502, but the concepts are the same, and there's some good professionally written material on it that's more appropriate for those with no prior programming experience. I think learning x86 strikes a rather happy medium between learning C++ first, and going in with no prior experience at all, and I think the time spent learning x86 would only be replacing time wasted with confusion from incoherent, deficient, or otherwise incomprehensible material. So in short, I think a person starting with x86 would be less prone to giving up. |
Dish
Posts: 364/596 |
Originally posted by Revenge
http://www.zophar.net/tech/files/6502.txt <-- This is very helpful. I have this bookmarked.
This doc does cover things nicely, however it does have the occasional error/misprint, so for the technical stuff (opcode lists, cycle counts, stuff like that), use the link Para provided instead.
Some problems with 6502.txt and other things I feel like bringing up:
6502.txt documents Relative addressing mode all wrong. It implies that a branch of $FE is a branch of -126 when it's really a branch of -2. Relative addressing mode arguments branch in the usual "two's compliment" fashion: $FF = -1, $FE = -2, $FD = -3 ... $80 = -128, $7F = +127, $7E = +126, etc. Not the method covered in 6502.txt.
6502.txt refers to the high status bit as 'S' (Sign flag), whereas pretty much every other doc on the planet refers to it as 'N' (Negative flag).
There isn't really a 'B' status flag -- or an 'unused' status flag. When processor status gets pushed to the stack (via IRQ/NMI/PHP/BRK) -- the bit representing the 'unused' status flag is always set, and the 'B' bit is set on BRK/PHP (and cleared on IRQ/NMI) -- however the status of these bits aren't tracked as the CPU runs (so the only "real" status flags are C, Z, I, D, V, N)
The V flag is not explained very well at all usually. On ADC: V is set when Positive + Positive = Negative, or when Negative + Negative = Positive. Under all other circumstances V is cleared. On SBC: V is set when Positive - Negative = Negative, or when Negative - Positive = Positive. Under all other circumstances V is cleared. Other instructions that change V don't rely on any such logic (BIT/CLV/PLP/RTI -- all pretty straightforward) |
Rockman
Posts: 197/250 |
I agree with Disch. Start out with 6502, and stick with it for a little while. Practice some hacks, and learn what you can learn. And if this happens to be your first language, stick with it for a good while. When you are comfortable with it, move on to 65816. Then, by this time around, you should have a good understanding, and you can read up on another language and probably grasp it easily. One of the things that are very helpful in learning assembly languages in hacking games, is a debugger. I can't get over how useful they really are. It is possible to hack without one, but it would probably be too difficult for a new person. If you are interesting in ASM hacking for the NES, use FCEUXD. You can't go wrong. But, if you feel comfortable with 6502, and want to move on to Super NES hacking, check out Geiger's SNES debugger. If you have taken a computer science class before, and have an understanding of how programming works, you shouldn't have too much trouble getting into ASM hacking. I for one though, had a very difficult time. I gave up a lot. So, I documented what I learned to make it a little easier to start out.
http://www.zophar.net/tech/files/6502.txt <-- This is very helpful. I have this bookmarked.
Also, you can check out my tutorials. These tutorials actually walk you through ASM hacks. (Thanks to Chill Penguin for hosting them)
http://www.geocities.com/bjb138/rockmanXasm/asm1.html
http://www.geocities.com/bjb138/rockmanXasm/asm2.html
Use your resources, and ask questions when you are stuck. There are also other ASM hacking-related threads on this board. Check them out!  |
Dish
Posts: 363/596 |
I don't know how/why x86 got introduced here, but I have to say it's a strange idea -- and I'm not sure it will really benefit S&T much for what he's trying to do. I mean the whole reason he's learning a different assembly language before 65816 (which is what he ultimatly wants to learn) is to soften the blow with an easier language. x86 would just intensify that blow -- not to mention it doesn't share the similarities 6502 has with 65816. I mean if he's going to sit down and learn x86, he might as well sit down and learn 65816 and save himself some time and trouble. 6502, on the other hand would be taking a smaller step in the same direction (65816 is just a 'beefed up' 6502, so after learning 6502 he'll only need to look at a few extra things and he'll have 65816 down).
I mean it's not like 6502 tutorials or learning resources are in short supply or anything. |
DarkPhoenix
Posts: 5/31 |
As far as learning assembly, the aforementioned NES ASM tutorial seems good, but if it's a bit more than you can chew, you might want to start at one of these:
PC Assembly Language by Paul Carter, downloadable at
http://www.drpaulcarter.com/pcasm/index.php
Art of Assembly Language Programming by Randall Hyde,
http://webster.cs.ucr.edu/
Assembler, Inside and Out by Harley Hahn. Microsoft Press, c.1992.
ISBN 0-07-881842-7
They're more x86 oriented, but they're a bit more geared toward people who haven't programmed before. I particularly recommend the last one, since it's what I learned assembly from (but it might be a touch hard to find now), but the DOS version of the Art of Assembly one is pretty good, too. They both start out simple, with number systems, like Hex, and deal primarily with 16 bit registers and 24-bit addressing (if I'm remembering correctly) like the SNES. Art of Assembly's particularly nice, because you can buy the book, or look at it in HTML or download the PDF or a Zip file. The first one's more 32-bit processor oriented, and only in PDF format, but good if you need another source, if something gets confusing. Also, if anyone needs a guide in french or portuguese, the first site is the way to go.
As far as more NES relevant sources, The NESDEV tutorial listed at Zophar.net I think is the best for beginners, and the 6502 reference Parasyte mentioned is far and away the best reference for the instruction set. For the SNES, the near equivalent references (though harder to navigate) are 65816info.txt and the 65816 docs, both here. Most of the assembly stuff for the SNES requires a background in 6502, or at least some background in assembly. So again, I recommend the x86 stuff first, since it's more geared toward those with no prior experience in assembly, and since it's easier to find stuff that's more complete, as well as revised and edited a few times over. |
Parasyte
Posts: 469/514 |
I suppose the only "correction" could be made to the following:
... go somewhere else in the program if the value now in the accumulator is zero.
This isn't entirely true, since it implies that the BEQ instruction works by checking the value in the accumulator. What's actually happening, of course, is the BEQ is checking the status of the Z-flag in the Processor Status Register. As any good 6502 manual will tell you, the [preceding] LDA instruction will set the Z-flag if the value loaded is zero.
Keep in mind that conditional branches check certain flags in the Processor Status Register, and most other instructions will set certain flags in the Processor Status Register, depending usually on the "result" of the operation. As mentioned earlier, the 6502 reference explains which instructions set which flags, and how/why. ;D
Just trying to avoid confusion... |
DarkPhoenix
Posts: 4/31 |
Personally, I'd say it'd probably be easiest to get a book on something like x86 assembly first, and/or possibly take a class in assembly programming. As was mentioned before, it's pretty easy to pick up on a new assembly language once you're familiar with the concepts behind assembly programming, so my suggestion is to learn an assembly language that's well documented first, and then move onto 6502, followed by 65816, if that's your goal. x86 (which is used by the pentium processors) is particularly well documented as it's still used, at the very least for inline assembly with higher level languages. Additionally, it's pretty easy to find a good assembler for x86 (NASM, MASM, or the GNU assembler) As far as whether to pick up a book or get into a class or something, that depends on how you learn. If you know you're not gonna be able to beat yourself into reading through a programming book on your own, then take a class somewhere, to give you some structure while you get a good foundation...but you're gonna need to beat yourself into reading through a lot of technical material eventually. Once you've finally learned an assembly language, then move onto learning the instruction set for whichever console you like, and get to know the intricacies of that particular system.
Aside from that, I think R2H2's code could use some line by line explaination, if for nothing else but curiosity:
LDA $0DBF ;This means LoaD the value at $0DBF into the Accumulator
; As he mentioned, this is where the number of coins you
; currently have is stored. In short, he's going to check how many
; coins you have
BEQ x ;Branch if EQual to the line labeled x - basically, he's going to go
; somewhere else in the program if the value now in the
; accumulator is zero.
JSR $00F5B7 ;if that value wasn't zero, the program didn't jump, so if that's the
; case, he's going to Jump to the SubRoutine at $00F5B7
; the subroutine at this location, as he mentioned, kills Mario
x: RTS ;this line is labelled x, where that BEQ line jumps to. The
; on this line simply tells the SNES to ReTurn from the Subroutine
; basically, go back to what it was doing before it ran this
; whole segment of code to check the coins. Note that this line
; may or may not be executed if there were coins, depending upon
; where the subroutine at 00F5B7 sends you. If it returns you here
; it will be executed, but it might send you somewhere else, like
; a gameover screen. You'd have to look at that subroutine's code
; to find out
My sincerest apologies for taking so much space to say so little. And for the sake of education, please, correct me if I'm wrong. |
Violent J
Posts: 270/749 |
Wow. I couldent believe this today. I asked my math teacher, who worked with coleco back in the day (hes like 55 now) and worked on games like Head to Head Boxing, Football, and Soccer, and a bunch other for the Colecovision. So I asked him if he learned Assembler code, and he told me yes, but he had also learned a level of programming below it, and he said Hex. So I ended up showing HH's code he posted to him in class by him letting me use the pc, and right away he told me some long drawn out explanation of what it ment. Im starting to wonder if he could teach me some of the components of ASM and Hex.  |
Parasyte
Posts: 375/514 |
I thin the idea is to get you familiar with code that makes no bloody sense. Because when hacking assembly, you will see a lot of it. |
Violent J
Posts: 267/749 |
Bah! So i got them mixed. I will get it soon. I still got to find some way to print out my refrense material so i can look back and eventually have it down in my head. But anyways HH. What you just exampled there left me clueless. Dont explode my brain this early in the learning process! |
HyperLamer
Posts: 3824/8210 |
Decimal 0DBF?  It's hex, the $ indicates that. # marks a constant in 65816. (Eg: LDA $200 means get a value from address 0x200, LDA #$200 means set A to 0x200, and LDA #200 means set A to 200 (0xC8)). Other than that, that's pretty much the idea. |
Violent J
Posts: 264/749 |
All i can see from that is LDA which is the loading pointer or something like that for A, the acumualator(i believe thats the word). So it wants to load the accumulator of i believe decimal 0DBF becuase theres no #. But I have no idea really what it all means. Just what it wants to do. I have studied quite much today so i think im making progress.  |
HyperLamer
Posts: 3821/8210 |
What especially helps is to know the game and moreso system. Even if you know (or can guess at) 65816, this probably doesn't mean a lot to you:
LDA $0DBF
BEQ x
JSR $00F5B7
x: RTS
However, if you know that in Super Mario World, $0DBF holds your coins and $00F5B7 is the subroutine for killing Mario, it's clear enough what this would do (kill you if you have any coins). Not that you'll find this code in the actual SMW ROM, but yeah. |
Violent J
Posts: 258/749 |
Allright NOW. I gotcha. Heh. Thanks for your help! |
Parasyte
Posts: 374/514 |
No. I am saying that all you will see is a bunch of senseless instructions. You'll see some adds, bitwise logic, loads, stores, and branches. But those will not tell you what part of the game they are handling.
There is little guess and checking involved; generally an experienced hacker can deduce what each routine does by memory references and plain old reverse engineering logic. Anything can be "edited and changed" but finding it can be difficult. And this is due to what I've explained above. You don't get any simple references such as function and variable names. It's just a lot of code, and it all looks exactly the same.
The most obvious choice for a debugger is the one in FCEUXD. It contains almost everything that is needed. |
Violent J
Posts: 252/749 |
That was better than George Bushs Presidential election speech! Ok, so I take it I could jump right into 6502 without doing C or C++. And what im getting out of you is; You dont know whats in a game and what can be edited and changed, you have to guess and check and such to find out. Im hoping thats right...
EDIT: If i were to get a debugger which one should i get. And what would i use with it, cuase I got to apply it all to something! |
Parasyte
Posts: 373/514 |
The gory details are all explained within the reference I linked. The theoretical details (such as "what the hell are registers and addressing modes?") are for a tutorial. You may be able to get some of the information from a few tutorials, but few tutorials have all of the information. And that's why most tutorials are quite bad; if they aren't written by beginners, then they aren't written for beginners, either.
I'm sure if you take the time to look through the "Greek" 6502 reference, along side a debugger, you will begin to understand what's what and why. Jumping right in and learning from experience is the way to go. Even without much programming knowledge, most concepts have been learned in your early childhood; add, subtract, carry, borrow... And of course making decisions; true, false... If you can understand these concepts, and you have a nice, verbose debugger handy, you should be able to look at an instruction in said debugger, look it up in the reference, and read the description to understand what the instruction does. There's not much difficulty in that. You see, understanding an assembly language is one thing. Understanding what routines do at a higher level (for example, loading and displaying a sprite) is altogether different. No tutorial can teach these things. The best they can provide is an example of how one game may do something specific. Truth is, it is always very difficult to understand undocumented routines (especially when hacking) even for programmers and hackers with many years of experience. You just have to think a bit like the machine and put many pieces of a puzzle together.
So, what I'm saying is that tutorials can be good, but you need more than that. You need definitive resources. Whether those resources are low-level reference sheets, debuggers, or having friends with the knowledge you seek; use them all. Learning a high level language is by no means required. As long as you understand the three basics of programming; Arithmetic, Program Flow, and Data Load/Store.
And with that, I'll get back to hacking 'Lost Cheats'. (Maybe I should create an archive of these things...) |
Glyph Phoenix
Posts: 124/745 |
Well, I don't think it's so much the C++ syntax but a knowledge of variables and the kind of things that make up a language. But as for how much they'll help you learn ASM, I can't help you with that because I know C++ but it hasn't helped my nearly nonexistant understanding of ASM. Sorry. |
Violent J
Posts: 251/749 |
Wait. Those refrences said i should learn C++ first. But what your telling me is that i might as well not? |
Glyph Phoenix
Posts: 122/745 |
It may take even longer than you think if you think that C++ is such a great stepping stone for learning ASM. Heck, I know C++, but those references people linked to might as well have been written in Greek, because they're already a foreign language to me... |
| This is a long thread. Click here to view it. |
|
hukka
