Haha...only took a day. I'm stuck. Well, not in code, but in understanding. The background colors...here goes.

Oh boy, I thought I had it all down, then I went to try and change colors to the cloud (background) and came to a unfortunate conclusion that I may be missing something fundamental in how the 4 colors are assigned to the pixels in the chr file as well.

So I'm messing around with this, trying to understand the attribute table and coloring of the background pixels. so here goes.

According to bunnyboy in the first post, the first color in the 4bytes (of 16 total) is the "transparent color". SO first question, what are the next 3 colors in the 4 bytes? For example, in my example.asm, the sprite palette has $21 in each of the 4 bytes (1st color) to ensure that the minimario sprite "looks" like minimario in the sky regardless of which set of colors is used by filling in the blank pixels with sky color($21) , okay, got it. Each of the colors changes a different part of mario as I go through the chr file palette selection and select a different set of 4 colors (same as assigning the sprite attribute to $00, $01, $02, or $03), okay, got it...

But I'm not understanding how the assembler "knows for any given set of 4 bytes of the color palette that is set to be used (see below example), which pixels will receive which of the four colors". In otherwords, how does it know that marios hat is all color $16, while his eyes are $18, skin $27, and area around him is the "transparent area" in this case color $21?

I'm assuming as you make the chr file you assign "sets of pixels" to the first color, then the next "set of pixels" are assigned the second color, so on until all 4 colors are used and all pixels have been assigned to one of the 4 "sets of pixels".

Once I understand this, I'll probably understand how the attributes apply to the background, but it is much different since 8 bytes of attributes are assigned to background vice 1 byte for a sprite. Just outta curiosity, why are there 8 bytes of attributes for colors for background, but only 1 byte for the attribute of a sprite? Not sure I'm understanding the setting of background colors like I thought...

My hunch is there are 32 tiles total, so 8 tiles x 4 rows = 32 tiles. And 1 byte of background attribute dictates the colors of 4 tiles, so you need the 8 bytes for the 32 tiles total.... And even if thats right, how does 1 attribute dictate the color of 4 tiles, each with there "4 sets of pixels"?

--Sprite palette CODE

...

palette: ;first set, second, set, third set, fourth set

.db $22,$29,$1A,$0F, $22,$36,$17,$0F, $22,$30,$21,$0F, $22,$27,$17,$0F ;;background palette

.db $21,$16,$27,$18, $21,$02,$38,$3C, $21,$1C,$15,$14, $21,$02,$38,$3C ;;sprite palette data

....

sprites: ;minimario

;vert tile attr horiz

.db $80, $32, $00, $80 ;sprite 0 Attr $00 means use the first set of 4 colors in sprite palette, $01 use second set, etc.

.db $80, $33, $00, $88 ;sprite 1

.db $88, $34, $00, $80 ;sprite 2

.db $88, $35, $00, $88 ;sprite 3


...

--END sprite palette CODe



--START Background palette CODE
...

background:

.db $24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24 ;;row 1 (not visible)

.db $24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24 ;;all sky

.db $24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24 ;;row 2

.db $24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24 ;;all sky

.db $24,$24,$24,$24,$45,$45,$24,$24,$45,$45,$45,$45,$45,$45,$24,$24 ;;row 3

.db $24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$53,$54,$24,$24 ;;some brick tops

.db $24,$24,$24,$24,$47,$47,$24,$24,$47,$47,$47,$47,$47,$47,$24,$24 ;;row 4

.db $24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$24,$55,$56,$24,$24 ;;brick bottoms


; why 8 bytes here?

attribute:

.db %00000000, %00010000, %01010000, %00010000, %00000000, %00000000, %00000000, %00110000

...

--End Background palette CODE

And all this started cuz I wanted a grey cloud (which I still cant figure out)... well its raining now aint it? lol

OS

In before 3rd gen.

You need to open the chr file in tile molester. That will answer the chr ?.

Each 16x16 bg block is only 2 bits, 1 2 3 4, just like sprites. You should revisit the picture.

That. Plus each pixel is 2 bits big, remember that. 3 colors+background since 00,01,10,11 is 4 combinations for the background. On sprites, the color with bits 00 is always see-through.

HAHAHAHAHAHAHAHAHAHAHHA

I'm also having trouble with this like others before me and I think it's because I don't understand the nametable attributes. I'm trying to load a full background of one specific tile repeated 960 times. This is what I have, and I'm still getting a background of zeros:

LoadBackground:
LDA $2002 ; read PPU status to reset the high/low latch
LDA #$20
STA $2006 ; write the high byte of $2000 address
LDA #$00
STA $2006 ; write the low byte of $2000 address
LDX #$00 ; index set to 0
LDY #$00
LoadBackgroundLoop:
LDA #$24 ;
STA $2007 ; write to PPU
INY ;Background is 32x30 ($20 x $1E) sprites, so 960 bytes
CPY #$20
BNE LoadBackgroundLoop
INX
CPX #$1E  ;This swaps with line below
LDY #$00   ;This swaps with line above
BNE LoadBackgroundLoop

EDIT: Figured it out.  Had to swap the two lines as noted in the comments in the code above.  I was constantly doing a compare, then the branch is referencing Y, not the result of the compare, so the loop never completed.  The ordering of code in this language is so sensitive it can drive you nuts! haha

Attribute tables are really confusing me, I have a question.

You mention the following:

Two bits of the attribute table byte are assigned to each 2x2 area.

From your image example it seems that two bits of the byte are used per tile and not 2 per 2x2 tile area - that would be 8 bits from what I see?

I must be looking at this completely wrong, any help would be greatly appreciated.

The tiles in SMB aren't 1 tile big, that's probably what is getting you. Each little square is 4 tiles made into a 2x2 square which is 1 block, which is why you probably can't "see" it. Does that make sense?

Each of those squares is made up of 4 tiles. The question mark box is 4 tiles.

edit: Not in before 3gen.

HAHAHAHAHAHA!!

(look familiar? )

Yes that makes perfect sense, thanks guys

Whoops double post.

I think I'm having the same problem as Kenny B with overflow of nametable data going into attribute memory.  My loops that copy the nametable data into memory copy 1024 bytes, but that should be okay because I have 960 bytes of nametable data and 64 bytes of attribute data which are contiguous in memory.  I explicitly set them up in the data section so that I could copy it all in one go (yes, I know this is bad because it mixes logic with data...shame on me) so I'm not sure why there seems to be some overflow.  Do you really have to explicitly stop looping after 960 bytes, then write to $23CO through port $2007 just to prevent the overflow?  That doesn't seem right to me since that memory is contiguous anyway.

Code here:

http://pastebin.com/N0tQQ1td...

I know you've been through these (As stated on NESDev) but maybe you should look into making subroutines that upload 1KB of data to the PPU, especially before trying to implant a hack to make it work in a project right now. You don't have to stop writing to the nametable for the attributes or anything. You just have to make sure no NMI's happen and then make sure rendering is disabled to upload a whole nametable, that's it. Use the tool NESst to make nametables wth your graphics, and then save it as a .BIN file with attributes, then upload that. I'd advise doing that in another project just to get a better idea of how to do it.

When I changed your attribute data to normal looking attribute data it worked fine.

    titleattr:
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000

    attributes:
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
  .db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000

I can't begin to imagine what it is that makes it work when the attribute data is set to zero but not to anything else.

Nothing.

(You should look at the NESASM command .incbin pleaseeee!)

Moving the data into another .asm file and then doing a .incbin "data.asm" at the same address the data was at just throws compiler errors at me. I understand it cleans up my code but I'm just trying to figure out what sort of sorcery is being invoked here.

No, wrong command, read harder here:

http://www.nespowerpak.com/nesasm...

So you can start using programs like this to make screens instead, it's 50x easier than how you're doing it now.

http://nesdev.parodius.com/bbs/viewtopic.php?t=7237

That usage doc is super helpful.  Thanks!

I am using that program and basically just copying the block so that the program generates the ASM code and copies it to the clipboard.

You're not really helping with his problem.  You're constantly just trying to get his code to look better, which is great, but not really what he's asking for.

Teach them wrong and get it to do something or teach them right and get it to do something, which am I supposed to go with as the tutorial seems to go more of the way of the former. I'm trying to get him to do this so I can help him because as the code stands right now it's very, very confusing to figure out. I'm just trying to help, but Khan is more than qualified and will probably help more then.

I can certainly respect and appreciate the suggestions on restructuring my code, because if I expect any help my code should be well-organized and readable so that it's easier to spot bugs. I've split my code up into 3 files: main game logic, subroutines, and data. I've tried to comment my code as much as possible to make it evident what each block does. I guess what's really throwing me here is the issue that KHAN pointed out...if the attributes are set to zero, everything is fine. Even a switch to a non-zero value to change what palette set is being used will cause that overflow effect which I can't reconcile.

pong1.asm: http://pastebin.com/rR4hJGRp...
subroutines.asm: http://pastebin.com/jURvi5Na...
data.asm: http://pastebin.com/DAxGJWky...

EDIT: P.S. I promise I will simplify a LOT of the subroutine code tomorrow since I just learned in that Usage file for NESASM that you can create user-defined functions.  I am giddy.

Much better! Lets see here...

You enable the screen not waiting for NMI, which will cause a "jump" the first few frames instead of a clean image straight to the screen.

You never recognize the NMI except with the intro code and when you go to upload a screen.

As for the palette problem, I can't get it to do anything. Code doesn't look like it would break depending on what was written to the PPU, so good luck with that.

Yikes. Guess I'll have to keep looking then. As for the NMI acknowledgement I'm not sure what you mean. Do you mean turning off the screen and then re-enabling? If so, where else is it helpful to do so? In reference to the first comment that will be an easy fix. I know what bit does that every time a point is scored. I noticed the flashing myself and just hadn't fixed it yet.

If you turn the screen on whilst the frame is basicly halfway down the screen for example (the nes keeps generating sync signals etc...and stil sends out some video data like the backround colour) it'll cause it to start rendering the first scanline right there and then. Causing the picture to "jump". So what you do is you wait for nmi THEN turn the screen on so you don't get the jump.