Addressing a two byte memory location with the registers

How can I address a two byte memory location with the help of the registers?
Let's say I want to write the value $AA into the memory from address $0200 to $04FF. I would write the following loop. But in the line with the command STA, how do I correctly concatenate the two address values or what else do I have to do here?

Your best choice for indexing into arrays bigger than 256 bytes is to put the address on zero page and use the (d),Y addressing mode.

In this particular case, these fixes will do what you want:

Note that said code will fail if the low 8 bits of the starting address aren't 0, and the low 8 bits of the ending address aren't $FF. The wiki covers the more general approach between any two addresses.

Which is why I said "in this particular case". =)

Well, I of course need a general solution that works always. Because the next thing I want to do is writing some functions for loading data. And the one thing that breaks my neck is the addressing. For example, when I want to load sprite data, then it's pretty easy:

At least as long as "Sprites" is a constant location. But as soon as I want to be able to parametrize this code and make it a sub routinge, the problems begin. Even if I don't work with the stack and whatever and simply put the data length value (#$20) into a global variable, I still don't know how to deal with the starting location in memory which is two bytes.
Besides, could anybody please explain me what's the deal with using < and > in assembly code?

Sprites is always in a constant area, it is assembled and assigned a value.

If you write one set of sprites initially, then yes it will work fine. But if you have to select the sprites you want to use per level or something, loading from sprites, which points to one 2 byte location, will ALWAYS point to that location! It will not change.

To dynamically load sprites, levels, or basically any data based on a number, you either 1. Need to build a pointer table. 2. Use math based on the number and multiply based on the base value. Let's assume we have 4 screens, screen 0 to 3. You want to load one each different level, you would have this:



if your code uses Screen0 to move it, it will ALWAYS point to the same screen. Here is some code to get around it:



what this does, is let us use objectified code like this:



If you need objectifying explained more, or any questions here, just PM or ask.

The routine is so short it can be made a macro. If it were a parameterized subroutine, it'd take 7-9 bytes to call, whereas the loop itself can be an inline macro and only need 11 bytes:

<addr gives the low 8 bits of addr, >addr gives the next higher 8 bits. If you code in C, <addr is the equivalent of addr&0xFF, and >addr is addr>>8&0xFF.

Yes, the actual sprites are in a constant area. I'm talking about my read only data that simply gives the information which sprites are to be loaded next. Imagine this:

This code tells you that level 1 will contain three Goombas (ID 1) and 5 Koopa Troopas (ID 2). And that's it. ($FF is the constant for end of data.) Another function that contains some logic would then build the actual on-screen sprites from that abstract data.
Level 4 would then maybe look like this:



Sounds good. How do I do this in 6502 Assembly, specifically for my example loop?


Doesn't sound so good. As you see above, there's no guarantee that data will have a fixed length. Besides, the same function shall be used for various unrelated data sections. So, any solution based on a fixed memory location of the data won't work in the long run.


Yeah, but if I want to call it various times (four times alone for background, sprites, palettes and attributes which would already make 44 bytes), it can get relatively very big.


If there's a way to take 8 bits from a 16 bit address, isn't there also a way to store two eight bit values next to each other and let the program treat it as a 16 bit address value?

Yeah, but math is more efficient+saves space, it's always the #1 option really, unless your data is like levels or maps, which has no set structure except a decompression stream. The code above is how you do that, the 1KB levels don't HAVE to be 1KB, because of the fact that we don't touch the level's data, we us the lookup pointer table which is changed every time it is assembled, so no matter the size, the pointer table will point to the data, that's it. It's like an array of pointers in C, in essence. See the above code, like I said, the table has to be added and the code written will take advantage of it, in 1KB chunks, but you just have to understand the idea, all the code will need rewritten for your needs.

Yes, pointers. If you store the high byte after the low byte in ZP you can use them as a 16-bit pointer. You're limited to the addressing modes that work with pointers though.

< and > are provided by the assembler, the 6502 doesn't know you're taking parts of a 16-bit value. When you do LDA #>$FFEE, what the 6502 sees is LDA #$EE. The 6502 is an 8-bit CPU that unlike some other 8-bit CPUs (Z80, for example) doesn't have 16-bit registers available to the program. Because of this, 16-bit values can only exist in memory (RAM or ROM), and must be manipulated byte by byte. The only way to address more then 256 bytes is with pointers, there's no way around that.

Pointers in 6502, concisely:


EDIT: whoops, < before $

I guess I understand that example now. In the moment I work with the standard neslib from CC65, so that's not an issue anymore, but when I remove it and write all the code myself, I guess I'll need it.