Metatile troubles

I've tried several attempts at getting a working metatile loader thrown together with very little success. Anyway, I have this routine here that should be taking the contents of a map data string and copying what should go into the nametable into RAM. I've tried many methods for this and the current is what I like best because it's sleek and nice looking. Anyway, I've tried debugging it and I'm still unsure where it's happening, but it seems like something is getting overwritten because when I ran the program it's showing the signs of going into an infinite loop.

Here is the routine:



Here are my tables:

I can tell you one thing: there is no INC A on the 6502 ("A" here is obviously a reference to the accumulator, not a variable or memory location that you've labelled "A") The assembler you're using is letting you use 65c02 or newer opcodes; the 6502 does not have a way to increment the accumulator aside from clc ; adc #1 (or in this case, you'd want to use clc ; adc #2 since you're wanting to add 2 to something).

Your INC A is probably being assembled into opcode $1a, which is an undefined opcode on the 6502, and is probably causing you chaos.

Get yourself an assembler that adheres strictly to 6502. :-)

Okay, that makes sense. However, it is producing different results but still seems to go into an infinite loop. Anyone know why?

Yes, executing undefined instructions is really bad... probably the cause of your infinite loop.

You appear to be doing unnecessary complex pointer operations, and making lots of mistakes along the way. For example, I don't see you ever setting the high bytes of ColumnNumX_Ptr or ColumnNumY_Ptr, so when you use those pointers you'll hardly get the addresses you expect. Also, you have the index of the metatile you want to draw in A when you call WriteTileToBuffer, but then you trash it with the LDA #HIGH(MT_Table) command.

Still, errors aside, the solution you're trying to come up with is way more complicated than it should be. Is there any reason why you can't copy your tiles like this:

You don't need pointers unless you have more than 256 types of metatiles throughout the game, but even if you do you can use this exact same code, except you'd use indirect addressing instead of absolute addressing for accessing the 4 corners of the metatile (you have to setup the 4 pointers whenever the tileset changes, which is usually between levels):

Yes. I'm not sure if I understand your code there. It's using the labels I've made just for readability. wouldn't that be hardcoding them? What I'm trying to say here is how would I use your code but instead of the "block 01" "block 02" ect loading make it load from the beginning of a long set of metatile data?

edit: also, using your method is only viable for one single metatile right? because there's nothing to stop the next jsr to that routine to keep overwriting itself

I doubt this is doing what you want, this is not the same as [pointer],y. There is nowhere in this code that needs pointers. Maybe if your metatile definitions were various sizes, you would need a pointer table to find the beginning of the metatile data.

You can leave your data as is and multiply the metatile(0 to 3) to by 4 to find the start index of the relevant data or arrange it so all top left, top right etc are together: (all $23 cause I'm lazy)



Then look at tokumaru's code again.

Edited because Kasumi is very silly...
By changing the value in A.
This writes tile $00.


This writes tile $0F.

I'm not sure what you mean that that will only write a single metatile. It will, but you put it in a loop to load the whole map. Something like:


I'm not sure what you mean by "there's nothing to stop the next jsr to that routine to keep overwriting itself".

edit2: Also, I probably misunderstood your first question:



Currently, Tokumaru suggests this:

For the table you have:


If you needed more sets, he's suggesting you do this:


Say these are your tables:


To use indirect code, MetaTileTopLeft etc now refer to RAM rather than ROM.

From there

Would load the Grasslands data as you'd expect. If you write the address for the waterlevel block to MetatileTopleft etc, that same code will load the waterlevel data.

How does WriteTileToBuffer write tile $0f? The first instruction is tay... that would copy the accumulator into y overwriting y. Right?

That's true. My bad, so you'd load A with the tile you want instead of Y.

Man this is confusing lol..... I guess I should have worded that better. I don't have separate banks of metatiles. Just one. No separate tileset..just the one. What i don't understand is in your code your lda'ing with all of the block labels. why? I was under the assumption that all one needed to do was supply the starting address of the metatiles data.

edit: say those labels weren't there. Could I just make a big table of the metatile data and make just one label?

Fair enough, you shouldn't use code you don't understand (don't ever copy/paste chunks of code together hoping they'll work if you don't understand the purpose of each chunk), but that's also not a reason to go for a solution way too more complex for your problem, specially if it's getting out of hand like in this case.


Not at all. The subroutine I wrote is indeed not a direct replacement of yours, but it's close enough. The only thing missing is the initialization of the X register, which has to be set to 0 before the decoding loop begins (since there is no pointer being updated anymore). Something like this (adding to what kasumi wrote):



With a loop similar to the above, like Kasumi said.


The value in X is kept between calls to the function, so nothing is overwritten.


Then forget about pointers altogether, you really don't need them for this.


Because you need to load the four corners of the metatile, so we have one LDA instruction for each corner.


Not necessary unless you have more than 256 metatiles. The index register (n this case, Y) can address up to 256 values, so if it contains #$05 and you do LDA MetaTileBlock00, y, that means "get the top left tile of metatile number $05". That will work up until metatile number 255, after that you'll need pointers.

You will maybe need pointers to read from your level map though, unless they're all < 256 metatiles (which could be the case if there's no scrolling, since you need 240 metatiles to fill the whole screen).

Please forgive my abundance of question asking, and my un-ability to grasp this concept, but I still don't get it. :E



I understand this, but the way the labels are being used is confusing me. Say I've got 16 metatiles instead of the 4 we have now. MetaTileBlock00-MetaTileBlock10 in order. Now what? Would the routine still be effective? If so, why are only the first 4 corner offsets loaded? (edit: I know 4 tiles make up a 16x16 tile, but why load the first 4 labels instead of say the last 4 or middle 4?)

Oh, now I get why you're confused! Each label in your table represents a metatile, I assumed that each label represented a corner of the metatiles... The code I posted assumed the data was arranged like this:


Which means that metatile #0 is made of the following tiles: $00, $20, $60, $80. I often arrange data like this because the 6502 is better at reading structures of arrays rather than arrays of structures. In this case, even if you have 200 tiles or more you'll still have only 4 labels in the code, because they represent the corners, and all metatiles have 4 corners.

You can do it your way and store the metatiles linearly, but then you can only have 64 of them before you need to use pointers. To read linear metatiles, my routine would look like this:

Like I said, this can only access 64 metatiles, which is why I prefer the other method (which is a better option than using pointers, because it's simpler and faster).

Ah! Now I see. As I'm not planning on using very many metatiles at all. This seems to be perfect for my style. Thank you very much tokumaru.

Update: Argh! I need to go back to NES school.. lol.

New problem: The code you all have been so gracious to help me with is for one column. Now, I assumed that right before I turned the screen on, I could JSR to that routine that sets the map up then return to turn the screen on. Basically, I imagined I could just set the writing area to $2000 and proceed on to a routine that would fetch 16 bytes from a level data table indexed by a which row to draw. However, my new problem is that I have no idea how to set the PPU writing area to what it needs to be. Like +$00 for row 1, +$16(?) for row 2, +$32 for 3(?) etc. My first assumption would be something like just using x to index what row. However, the PPU register is write-twice so that pretty much defeats the idea of that. How is this accomplished? Pointers? Sorry, my go-to is always pointers for some reason. lol

I mean, I know the nametable deal ($2007) increments with every write, however the buffer is only 64 bytes. Get what I'm trying to say?

No, not pointers. Since the PPU is on a separate addressing space, there are not that many ways to access it. If you want direct access to any given byte, there's no other way than setting up the address through $2006 for every access. As you can imagine, this is slow should be avoided, specially during VBlank. Most programs take advantage of the auto-increment feature the PPU has: after each write/read, the address increments automatically (by 32, which is useful for drawing columns of tiles, or by 1, which is for nearly everything else).

Since you have divided your buffer into a top row and a bottom row, the easiest thing to do would be to set PPU address increments to 1 and just blast all 64 bytes in sequence. If you're drawing a whole screen (meaning rendering is turned off), you can even leave the PPU address untouched from one row of metatiles to the next. Something like this: