Load value at a variable address without use of X/Y?

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
UncleSporky
Posts: 388
Joined: Sat Nov 17, 2007 8:44 pm

Load value at a variable address without use of X/Y?

Post by UncleSporky »

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.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

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).
UncleSporky
Posts: 388
Joined: Sat Nov 17, 2007 8:44 pm

Post by UncleSporky »

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? :)
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

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.
Useless, lumbering half-wits don't scare us.
UncleSporky
Posts: 388
Joined: Sat Nov 17, 2007 8:44 pm

Post by UncleSporky »

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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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.
Post Reply