Doing some optimizing...going cross eyed...
Page 1 of 1

Author:  JoeGtake2 [ Fri Nov 03, 2017 10:07 am ]
Post subject:  Doing some optimizing...going cross eyed...

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:

    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.
    ;;;; 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:


    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 i was trying things like creating a whole other table with high and low address values for both the high and low references there:


             .db <chrTypeTableLo
             .db >chrTypeTableLo

And then in the routine, things like:


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

    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?

Author:  tokumaru [ Fri Nov 03, 2017 10:18 am ]
Post subject:  Re: Doing some optimizing...going cross eyed...

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.

Author:  JoeGtake2 [ Fri Nov 03, 2017 10:27 am ]
Post subject:  Re: Doing some optimizing...going cross eyed...

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:


    .db <CHR0_TableLo
    .db >CHR0_TableLo

    .db <CHR0_TableHi
    .db >CHR0_TableHi

And now this SHOULD get me the right place to point?


   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?

Author:  tokumaru [ Fri Nov 03, 2017 11:53 am ]
Post subject:  Re: Doing some optimizing...going cross eyed...

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:

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

   .db <chr0Table, <chr1Table, (...)
   .db >chr0Table, >chr1Table, (...)

   .dw chr0Address0, chr0Address1, chr0Address2, (...)
   .dw chr1Address0, chr1Address1, chr1Address2, (...)

Author:  JoeGtake2 [ Fri Nov 03, 2017 11:57 am ]
Post subject:  Re: Doing some optimizing...going cross eyed...

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's negligible. But I see your point.

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


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.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group