It is currently Wed Nov 22, 2017 12:35 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Sat Aug 08, 2009 1:11 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 08, 2009 1:22 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3484
Location: Indianapolis
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).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 08, 2009 1:42 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 08, 2009 2:14 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7272
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 08, 2009 2:28 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 08, 2009 8:08 pm 
Offline
User avatar

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group