Simple table read...

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
JoeGtake2
Posts: 333
Joined: Tue Jul 01, 2014 4:02 pm

Simple table read...

Post by JoeGtake2 »

Alright, so this should work based on my understanding and other similar examples I have tried.

If I have a table that is simply this:

Code: Select all


 DataTable:
    .db $0A, $0B, $0C, $0D

...and, want to call and store the appropriate value...

Code: Select all


    LDY $02
    LDA DataTable,y
    STA someAddress

...shouldn't the value $0C now be stored in someAddress?

And if I want to store a value to a higher address...

Code: Select all


    LDY $00
    LDA DataTable,y
    STA someAddress+2

...shouldn't the value $0A now be stored in the address that is two more from someAddress?


If I'm missing something, please let me know. Thanks!
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Simple table read...

Post by rainwarrior »

The code provided isn't enough context. Edit: 43110 spotted the problem, see below.

The first question I'd ask is whether someAddress is in RAM?

The second question I'd ask is whether you've tried using a debugger? I highly suspect that this code itself does exactly what you think it does, and your problem lies elsewhere. Put a breakpoint on writes to someAddress or someAddress+2 and see if something else is messing with it.
Last edited by rainwarrior on Fri Apr 10, 2015 11:15 am, edited 1 time in total.
JoeGtake2
Posts: 333
Joined: Tue Jul 01, 2014 4:02 pm

Re: Simple table read...

Post by JoeGtake2 »

What's frustrating is it's pretty simple. Just trying to draw to the spriteRam I set up (constant...spriteRam = $0200). I've done this a dozen times or more. There's a table which contains four bytes of tile data followed by four bytes of attribute data. I find the tile data (0-3), write it to spriteRam+1, and then add four to that value to get the address of the attribute data, which I write to spriteRam+2 (where spriteRam and spriteRam+3 are set to arbitrary x and y values).

so something like...

Code: Select all


    LDY $00
    LDA spriteGroup,y  ;; gives me the tile: y offset of the table with the label *spriteGroup*
    STA spriteRam+1

    LDY $04
    LDA spriteGroup,y  ;; gives me the attribute: again, y offset of the table
    STA spriteRam+2


I'll run it through a debugger, but there's nothing present that would mess with this...it's just a tester file, and there is nothing else writing to the addresses. If I just put in values for spriteRam+1 and spriteRam+2 (like if I skip pulling from the spriteGroup table and just put the values in instead), they work fine, so it's definitely something to do with my table read?
JRoatch
Formerly 43110
Posts: 422
Joined: Wed Feb 05, 2014 7:01 am
Contact:

Re: Simple table read...

Post by JRoatch »

JoeGtake2 wrote:

Code: Select all

DataTable:
    .db $0A, $0B, $0C, $0D

Code: Select all

    LDY $02
    LDA DataTable,y
    STA someAddress
...shouldn't the value $0C now be stored in someAddress?
Without a '#' for loading a immediate value, that ldy is loading from the unlabeled variable $02

This happens to me way too many times.
JoeGtake2
Posts: 333
Joined: Tue Jul 01, 2014 4:02 pm

Re: Simple table read...

Post by JoeGtake2 »

Ugh....disregard this entire thread. I might just delete it. I'm both not crazy and also completely careless. In my testing ground here, I was loading 'test' hex values to the attributes...not at all correlating to what they should have been in binary. There was nothing wrong with my table read, apparently. Just a stupid mistake in the tables themselves leftover from 'the old way' i was doing it.

What a waste of a morning teching THAT. ha!
Post Reply