It is currently Sat Nov 18, 2017 10:15 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Fri Nov 03, 2017 10:07 am 
Offline

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


    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:

    dummyPointerTableLo_lo:
             .db <chrTypeTableLo
    dummyPointerTableLo_hi:
             .db >chrTypeTableLo


And then in the routine, things like:

Code:

    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?


Top
 Profile  
 
PostPosted: Fri Nov 03, 2017 10:18 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Fri Nov 03, 2017 10:27 am 
Offline

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

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:

   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?


Top
 Profile  
 
PostPosted: Fri Nov 03, 2017 11:53 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
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:
   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:
chrTypeTableLo:
   .db <chr0Table, <chr1Table, (...)
chrTypeTableHi:
   .db >chr0Table, >chr1Table, (...)

chr0Table:
   .dw chr0Address0, chr0Address1, chr0Address2, (...)
chr1Table:
   .dw chr1Address0, chr1Address1, chr1Address2, (...)


Top
 Profile  
 
PostPosted: Fri Nov 03, 2017 11:57 am 
Offline

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group