NESICIDE for Linux runs at less than full speed on my machine and therefore also lacks sound

cpow is the developer of NESICIDE, an emulator containing such a debugger.

I won't hijack this thread I'll just mention that there have been some discoveries [thanks lidnariq, torrasque] regarding the poor performance on Linux. Having said that, the minimum system requirements are still pretty high yet.

screenArray is a label that represents an address. Labels allow you to not care about actual physical addresses, assembler takes care on it. +1 etc is added to the address that is calculated by assembler for a label. So you can use it anywhere you could use an actual address, and it works exactly the same as for an address.

Like, sta $4000+1 is the same as sta $4001; if label=$4000, sta label+1 will be the same as sta $4001.

screenArray is a label that represents an address. Labels allow you to not care about actual physical addresses, assembler takes care on it. +1 etc is added to the address that is calculated by assembler for a label. So you can use it anywhere you could use an actual address, and it works exactly the same as for an address.

Like, sta $4000+1 is the same as sta $4001; if label=$4000, sta label+1 will be the same as sta $4001.

Wow, Shiru, great explanation! I really understand the +1 etc thing now; thank you so much!

These will probably assemble, but they will not work like you think. LDA (this)+1, y will most likely become LDA this+1, y, and LDA (this+1), y will use half of your pointer along with the next byte and form an invalid pointer, causing you to access garbage data.

To do what you want you'll either have to use 2 pointers (one of them pointing one byte ahead of the other), or increment Y or the low byte of the pointer between the two accesses. Indirect addressing on the 6502 is not as flexible as you'd like.

As long as This is a set value and not a RAM location, 2 will not work and 3 will. If This is a RAM value, neither will work as you just can't do that. And remember, since that's a word sized pointer, you may be needing to do +2 to move to the next pointer, keep that in mind!

If you have an array of pointers on zero page, LDA (d,x) might be your best bet. It didn't get much use on a lot of 6502-based home computers because the built-in BASIC interpreter ate up a lot of zero page.

These will probably assemble, but they will not work like you think. LDA (this)+1, y will most likely become LDA this+1, y, and LDA (this+1), y will use half of your pointer along with the next byte and form an invalid pointer, causing you to access garbage data.

Thank you though for being brave and explaning to me the truth about my second and third question. I just coded a solution yesterday thinking the other two questions weren't important. Thank you tokumaru!

tokumaru wrote:

To do what you want you'll either have to use 2 pointers (one of them pointing one byte ahead of the other), or increment Y or the low byte of the pointer between the two accesses. Indirect addressing on the 6502 is not as flexible as you'd like.

Sorry, I dont understand this right now... but, maybe that'll be ok if one of the 2 ideas below becomes possible. If not, I'll swing back to learn this.

3gengames wrote:

As long as This is a set value and not a RAM location, 2 will not work and 3 will. If This is a RAM value, neither will work as you just can't do that.

3gengames, thank you for explaining this. I don't think I could use a set value though because I'd have to recalculate it every time I added a line of code before it. Maybe I'm wrong about that? I dont know.

tepples wrote:

If you have an array of pointers on zero page, LDA (d,x) might be your best bet.

If you have an array of pointers on zero page, LDA (d,x) might be your best bet.

Really?! 4.)Is LDA (this+3, x) possible?

Yes, as long as This is a ROM location that doesn't change (when compiled, not over the projects whole creation) then that would work. But, the thing you're missing is if you have a lot of pointers in zero page, then you need to just do the begging of the array+X to point to one, because that's what it does. If you have 3 pointers in an array, you can select any of the three by putting in the code LDA (ZeroPageArray,X) because it takes the array location, adds X to the pointer of it, then gets wherever THAT points to. If I could make something up in paint I would, but I'm too slow and my graduation party is begging in 2 hours. Think of it as a normal array (LDA Array,X) then then whatever that points to, it then looks at it. Remember, each pointer is 2 bytes so moving 1 byte ahead in the array will mean you have to either do a INX INX or a ASL A if you do a TAX to get X to something you need.

It is, but again, I don't think it will do what you want. The ($XX), y addressing mode is meant for accessing an array through a pointer, while ($XX, x) is meant for using arrays of pointers. In the first case, the index register (Y) indexes the targeted data, in the second case, the index register (X) indexes a pointer in an array of pointers.

The reason why ($XX, x) is rarely used is because it can't index the target data in any way. Once the address of the pointer is calculated ($XX + x) and the pointer is used, the target is a single byte. There's no way to access any bytes after that one. If you do wish to access the next bytes, you have to manipulate the pointer itself (INC the lower byte, if it overflows INC the higher byte), which is terribly slow.

The +offset trick works with absolute addressing because the assembler calculates the absolute address for you based on the offsets you give it. With indirect addressing it's different, because it's not the assembler that will calculate the final address of the data, it's the CPU that will do it as the program runs. For this reason, if you try to use offsets they will not affect the final address, but rather the address of the pointer. I'm pretty sure that this is not what you want.

It seems you are a bit confused about the addressing modes, so I suggest you play a bit with ($XX, x) and ($XX), y using the 6502 simulator until you understand how they work.

Who is online

Users browsing this forum: No registered users and 5 guests

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