Okay. Here's a quick crash course.
So this is what an assembler does: It creates a sequence of bytes based on the instructions you give it.
Code:
reset:
sei
ldx #$00
becomes $78, $A2, $00. This is rom. If you opened your assembled rom in a hex editor and searched for this byte sequence you would find it. A guide like this:
http://www.obelisk.demon.co.uk/6502/reference.htmlTells you what byte each instruction is assembled as, but that is not that important.
The next thing to know, is a label doesn't actually take any rom. What takes up space are references to it. In the code above, reset takes no rom. References to it are actually stored with the instruction.
So this:
Code:
reset:
sei
ldx #$00
lda reset
would be assembled as
$78, $A2, $00, $AD, (low byte of reset), (high byte of reset).
All these bytes are actually part of your games binary (the .nes rom), so they are rom. To further bring this home, you can actually load an instruction's opcode. Remember how I said sei becomes $78?
So what do you think is stored in the accumulator when I lda reset in the code above? $78. lda reset+1? $A2.
When you directly load a number (lda #$00), the actual number (here it's 0) is stored in rom. $A9, $00 would be what is assembled. When you're referring to an address, you don't include the # part.
RAM is $0000-$07FF. Whenever you load a number from any of those locations, you're loading from RAM. These numbers can be changed. To put actual code in RAM is easy. You just look up the opcodes. Remember the byte stream of the code above?
$78, $A2, $00 was sei, ldx #$00
Code:
lda #$78
sta $00
lda #$A2
sta $01
lda #$00
sta $02
jmp $0000
This stores code into RAM, then jmps there and runs it. The NES CPU makes no distinction between RAM and ROM when it's running through instructions.
RAM can't be changed before the program is run. If you want a location in RAM to be a certain number, you need to set it to that number at startup. It's as easy as loading the number you want, and storing it there. If you want to load the number from rom, you can incbin a byte stream, and load each value then store it in RAM, but I just use immediate addressing. What I think is being suggested to you is something like this:
You want ram locations $00, $01, $02, $03 to contain $F3, $FD, $08, $23 respectively. So you create a binary file that contains the bytes $F3, $FD, $08, and $23.
Then you incbin that file after an address.
Code:
zeropageinitialvalues: incbin "zeropagebinary.bin"
Then you run code like what 3gengames wrote.
For reference, I'd just do this:
Code:
lda #$F3
sta $00
lda #$FD
sta $01
lda #$08
sta $02
lda #$23
sta $03
since it's easier to change a number, and you won't necessarily be storing numbers so sequentially.
If I were you, I would try to read and understand thing like the difference between lda #$00 and lda $00 before doing anything else. I might also try to completely rewrite whatever you've got, since if you didn't know this stuff, it has gotta be messy.