-I'm guessing I'm right about the lesson on Branching is "The Program Counter is where are you in Address now."
This is correct. Or at least. It's correct that the program counter is where the CPU will next execute an instruction. You are not correct that that was the goal of the lesson. The Program Counter was taught only to make it easier to follow the real lesson, which was branching.
-When the Program Counter is going up, the Opcode goes up by 2, and the Address goes up by 3. When it's number/HEX/Decimals, it's only 2 code upward, in favor for the opcode, that's used in the Address code, and the number that's also used for the Address code. I'm guessing high-byte and low-byte doesn't count here.
This is not. Each instruction always has an opcode. This is one byte. Most instructions then have an operand of either 1 or 2 bytes. So if you are using an instruction that is dealing with an address (that isn't $0000-$00FF) it is three bytes. One byte for the opcode. Two bytes for the operand which is an address.
Some instructions are exactly one byte total (just the opcode), we just haven't covered any of those yet.
Way simpler: The CPU just "knows" how many bytes each instruction is. It will add the size in bytes of the current instruction to the PC and then the PC will have the address of the next instruction.
Edit:
Because the $12 represent the "street" of the code, while $34 represent the "house of the code. $12 might be CPU, PPU, RAM. And the $34 might be the lever or role/job for what they do FOR CPU, PPU, RAM.
This is actually a reasonably solid way to look at it. It is correct that the byte in $12's place usually does defines a "profession" (like construction), while the byte in $34's place usually chooses the role within that profession. (Flag Man, cement truck driver.) RAM isn't really delegated into jobs, though.
-Labels are a type of BIG box you can use for later codings.
They're actually more like the label you put ON the box. Labels don't really "store" anything. They just name things.
How you've commented the example isn't correct, but I'm going another way for now.
Everyone following this topic will probably think I'm crazy for even trying this example here, but I think it will actually help.
I will explain why I'm doing this upfront. I want to make it clear that everything is just bytes. That the 6502 CPU doesn't care that much about things. Most context is created to help the programmer.
Order is VERY IMPORTANT. Do these things step by step. If you do anything out of order, you will need to navigate to the page again and follow the steps again starting from 1.
1. Go to an easy6502 code box.
2. Erase what's in the box.
3. Type (but don't assemble) the following code.
This address should look familiar. It is the address of the first byte of the first instruction, if you recall.
4. Type 0600 next to Start: $
5. Check the checkbox next to "Monitor"
Your easy6502 box should now look like this:
6. Click assemble
7. Check the checkbox next to "Debugger"
8. Click step.
9. Type out (in notepad or something, not easy6502) the values to the right of 0600: under the monitor checkbox. These are the bytes that the code (lda #$A2, sta $0600) became.
10. Click run.
11. Type out which values are in in A, X and Y underneath the bytes you typed out earlier.
12. In your document, type out the values to the right of 0600: under the monitor again. They've changed, but this should make sense. After all, you just stored a number there.
13. Click reset.
14. Click run.
15. Type out which values are in A, X, and Y underneath the bytes you typed out earlier.
What changed? Do you have a guess as to why this might be?
