Sorry for asking such a basic question. Currently my code is in no state to test this with different syntax, looking for the correct method (which may not even exist).
This is using ASM6.
I know I can lda label, which is the same as lda $aaaa. It fetches the byte at the label address, great.
I also know I can lda (variable),y, which is the same as lda ($aa),y. It fetches the data at the word address starting at variable, plus y.
Is there a way to simply load the data at a variable address, or concatenate two variables and load the data at their address? In other words can I lda (variable), without the y?
Again, sorry for the dumb question, just looking for a quick answer.
I'm pretty sure that addressing mode (indirect, without indexing) exists on 65C816, maybe on the 65C02, but we don't have that on the old 6502. So it seems Y gets loaded with zero a lot. Oh, except for the JMP instruction (I've been doing JMP ($FFFC) quite a bit lately).
I went looking through docs I have (Western Design Center program manual) and found the same thing, that we don't have that specific instruction (the 65C02 did have it). Frustrating.
Are there no inline commands that could simulate it, either? For example I can
lda variable+1 to get the data in the byte after variable. I suppose I can't think of any operations that would result in a full word.
I could run code from RAM, though, and edit the word after the opcode. That'd do it, wouldn't it?
Yeah you're pretty left with 3 options :
1) ldy #$00
lda (Ptr),Y
the most common one
2) ldx #$00
lda (Ptr,X)
if you really must have Y preserved for some reason
3) put code in RAM and modify the argument of lda absolute. Putting code in RAM potentially "adds one level of indirection", that is immediate become "absolute", absolute become "indirect" and indirect become "indirect indirect" if you see what I mean. By using absolute,X in RAM you can also "simulate" a non-existing lda (Ptr),X adressing.
Altough you'd want to do all of tihs commonly on the Commodore 64 which always runs code from RAM (which has been initially loaded from a disk or tape), on the NES you have to first copy a part of your code from ROM to RAM which is a slow and annoying step.
Unless it's a piece of code you call a lot in your project (such as a piece of code that draws sprites or that writes to the PPU during VBlank), you'd better have to go the traditional way from ROM and save your regs in temporary variables whenever you need too.
Bregalad wrote:
on the NES you have to first copy a part of your code from ROM to RAM which is a slow and annoying step.
Well, if I was going to use this particular technique a lot, I'd probably make it a subroutine, just the load and rts. But the ability to do this is way overshadowed by the amount of cycles - 16 bit add in RAM, jsr, lda, rts - compared to sty, ldy 0, lda, ldy.
Thanks guys.
Try looking at the whole picture and see if you can do the task in some other way. What I mean is that sometimes we are sure that performing a certain operation is the way to go (and if that operation isn't available we get frustrated), but if we think a bit more we may be able to solve the problem in a different way, using a different piece of logic, and end up making something more friendly to the architecture we're using.
This has happened to me a lot. Several times I has able to replace huge chunks of slow code with some faster and smaller logic by approaching the problem differently.
Surely not all tasks can be rewritten in different ways, and the 6502 does have very few registers to work with.