Doing some optimizing...going cross eyed...

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

Doing some optimizing...going cross eyed...

Post by JoeGtake2 »

Alright - so I'm attempting to do some optimization. Using ASM6, and using CHR ram. Essentially, I have different *types* of tiles that can be loaded (background, screen object, paths), and the loading of each treated slightly differently...and indexes to each are buried in their own tables. It gets pretty unruly, and I'm trying to logically simplify.

In my loadChrRam routine, I end up first checking the type (type by type), where what I'd like to have is a look up table that populates the indexing based on the type. I'm making this sound really confusing...ok...

Right now, I have something like:

Code: Select all

    LDX specifcTile ;; offset in lookup tables of specific tile to load
    LDA chrType
    BNE notZeroTileType
    ;;; if it is zero tile type
    LDA #CHR0_TableLo,x
    STA pointer
    LDA #CHR0_TableHi,x
    STA pointer+1
    JMP gotMyChrTile ;; now this pointer references the right tile in the following routine.
notZeroTileType:
    ;;;; check other tile types
This works fine. And I could keep it this way. But since there are about 8 *types*, there's a lot of redundant code here (checking for each one, instead loading #CHR1_TableLo, etc). In an attempt to free up a little ROM space, I'm trying to create a table that points to the tables that points to the values. But I'm never getting the expected results.

So like, it would be something more like:

Code: Select all



    LDY chrType
    LDA chrTypeTableLo,y ;; which, if zero, would have  #CHR0_TableLo
    STA pointer
    LDA chrTypeTableHi,y 
    STA pointer+1
    JMP gotMyChrTile

Now, of course, this doesn't directly work, because what I'm really trying to do is point to an address....so i was trying things like creating a whole other table with high and low address values for both the high and low references there:

Code: Select all


    dummyPointerTableLo_lo:
             .db <chrTypeTableLo
    dummyPointerTableLo_hi:
             .db >chrTypeTableLo
And then in the routine, things like:

Code: Select all


    LDY #$00
    LDA dummyPointerTableLo_lo
    STA pointer
    LDA dummyPointerTableLo_hi
    STA pointer+1
    LDY chrType
    LDA (pointer),y
    STA pointer


;;;;;;; JUST TESTING ABOVE TO SEE IF THAT GIVES ME THE VALUE FOR LOW BYTE, FINISHING THE HI BYTE AS BEFORE;;;;
    LDA #CHR0_TableHi,x
    STA pointer+1
    JMP gotMyChrTile ;; now this pointer SHOULD reference the right tile in the following routine.


At this point, I'm just sort of going cross eyed with it. i'm likely doing something dumb, as I have this sort of addressing all over my game, but...*shrugs*. I've got to move on to some other pressing things in the interim...anyone see glaring issues and/or suggest how to correctly mine this data?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Doing some optimizing...going cross eyed...

Post by tokumaru »

I'm kinda in a hurry now so I didn't understand the whole problem yet, but one thing that caught my eye is that you're using a weird non-existent addressing mode in a few places: LDA #CHR0_TableLo,x

The character "#" represents immediate values, that is, the argument is supplied in the instruction itself, so immediate addressing can't possibly be indexed, it doesn't make sense. It's really weird if any assembler is even assembling this code without throwing any errors.

Anyway, I will take a better look at the rest of the post later and see if I can understand what your asking.
JoeGtake2
Posts: 333
Joined: Tue Jul 01, 2014 4:02 pm

Re: Doing some optimizing...going cross eyed...

Post by JoeGtake2 »

I have a few instances of this - it is very very very old code, so it's been a while since I dug in, and there are a few quirks I'm not sure the reasoning behind. That being one. Now as I go back through and optimize with greater understanding, I'm attempting to fix all those sorts of things (in any way that doesn't break it!) haha.

So yeah, not sure, but yes the addressing works fine without (but also compiles and works just fine with, as if ignoring)

*edit* - I guess to simplify...

CHR0_TableLo,x and CHR0_TableHi,x are loaded into temp16 and temp16+1, so that a further reference to (temp16) yields the correct value...this works fine.

Now I'm trying to point to CHR0_TableLo and CHR0_TableHi. My instinct was to do something like:

Code: Select all


ChrTypeFinderLo_lo:
    .db <CHR0_TableLo
ChrTypeFinderLo_hi:
    .db >CHR0_TableLo

ChrTypeFinderHi_lo:
    .db <CHR0_TableHi
CHRTypeFinderHi_hi:
    .db >CHR0_TableHi
And now this SHOULD get me the right place to point?

Code: Select all


   LDY #$00
   LDX #$00
   LDA ChrTypeFinderLo_lo,y
   STA pointer
   LDA ChrTypeFinderLo_hi,y
   STA pointer+1
   LDA (pointer),x
   STA temp16

   LDY #$00
   LDX #$00
   LDA ChrTypeFinderHi_lo,y
   STA pointer
   LDA ChrTypeFinderHi_hi,y
   STA pointer+1
   LDA (pointer),x
   STA temp16+1


Shouldn't this be giving me the right values? Shouldn't I now have CHR0_TableLo,x in temp16 and CHR0_TableHi,x in temp16+1?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Doing some optimizing...going cross eyed...

Post by tokumaru »

This addressing mode: LDA (pointer),x also doesn't exist. Indirect addressing can only be indexed using the Y register. It probably still compiles, but the parentheses in (pointer) are interpreted as (pointless) precedence modifiers, so the instruction evaluates to LDA pointer,x, which is not what you want.

If I understand correctly, you want to index some data based not only on the tile's number, but also the tile's type, right? Your idea of using 2 tables and handling one index at a time works fine, as does combining the two indices beforehand and locating the data in a larger table sorted by the two conditions you have.

The problem with your implementation is that when you combine high/low byte splitting with indirection, things can get a bit harder to manage. Splitting tables in high/low bytes is great when you use absolute addressing, because you have immediate access to the separate tables, but when you're indirectly loading data from split tables, you need TWO pointers, one pointing to the table of low bytes, and another pointing to the table of high bytes. At this point, unless you're reusing the two pointers to fetch multiple 16-bit values, the advantage of using split tables is gone, because it takes more time and space to prepare two pointers than it takes to read two sequential bytes from the same table (i.e. just increment Y). So in this case, you could do something like this:

Code: Select all

	ldx chrType
	lda chrTypeTableLo, x
	sta typePointer+0
	lda chrTypeTableHi, x
	sta typePointer+1
	lda specificTile
	asl
	bcc +
	inc typePointer+1
+	tay
	lda (typePointer), y
	sta chrPointer+0
	iny
	lda (typePointer), y
	sta chrPointer+1

Code: Select all

chrTypeTableLo:
	.db <chr0Table, <chr1Table, (...)
chrTypeTableHi:
	.db >chr0Table, >chr1Table, (...)

chr0Table:
	.dw chr0Address0, chr0Address1, chr0Address2, (...)
chr1Table:
	.dw chr1Address0, chr1Address1, chr1Address2, (...)
JoeGtake2
Posts: 333
Joined: Tue Jul 01, 2014 4:02 pm

Re: Doing some optimizing...going cross eyed...

Post by JoeGtake2 »

It's funny, I feel this odd sense of deja vu like I've had this exactly problem before, and there is some weird lingering code right here that i found that is never referenced in my entire program. I wonder if I dropped this for the other method.

I'll give this a try. Speed is not a problem with this routine *really*, because its a fetch that happens with rendering is off...it's negligible. But I see your point.

Let's see if I can work through it with this. Thanks.


*****SOLVED*****

Easy peasy. It was indexing using the X, which worked prior without the extra level of indirection. All the convoluted work arounds I was doing were making a mess of it all. Thanks for being a second set of eyes.
Post Reply