Are you saying that changing any of your attributes to any non-zero values are causing problems? I changed the title attribute to:

titleattr:
.db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
.db %00000000, %01010101, %01010101, %01010101, %01010101, %01010101, %01010101, %00000000
.db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
.db %00000000, %10101010, %10101010, %10101010, %10101010, %10101010, %10101010, %00000000
.db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
.db %00000000, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %00000000
.db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000
.db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000

And I didn't seem to get any errors. What is your problem, exactly?

I studied this particular tutorial and it finally makes sense. Basically I was reading the attribute byte like a sprite attribute, so only manipulating the last two bits. I now understand that there are 8 bits, and split up into 4 2-bit chunks gives one byte control over one block (16x16 pixel section). For some reason I didn't fully understand this before.

That "Oh, that's how it works" moment is always a good one.

Better late than never! I remember when the lightbulb came on for this lesson, too. Welcome to the other side! Haha.

alright so I'm having a brain dead moment. I got the background to fully load (haven't tweeks the attributes as of yet but wil get there soon) but I can't figure out why at the top it goes halfway with sky, then the bricks start. based on what I've read there should be some sky all the way across the top then the next row the bricks would start. can someone please explain to me why this is happening?

(my basic plan is to encompass the border with bricks when all is said and done. I also realize I've got my brick tops and bottoms reversed. will fix later)

i've atached a picture and the code

--- edit----

changed the attachment to the one I meant to upload

Protip: Never compare to 0, it's never needed because there's a "zero or not 0" condition code. Whe you INX and it wraps to 0, it automagically sets the flag.

Another protip you can use later: Try to count down if it's to 0. You'll need to reverse your data but it saves bytes and CPU.  

Another normal tip: Stuf inbetween normal labels like:

Label:
  LDA #$20
  LDA #$00
LabelLoop:
  STA Somewhere
  DEX
  BPL LabelLoop
AfterLabel:

can use local labels. Local labels are names so that you can use generic label names like "Loop" everwhere. All you do it put a dot before the label and in between each global label with no period, it'll use the local one. You also need to put the . in the label name in your code too, but it's not hard. I'll give you some code of mine to check out if you need a detailed example.

As for why the bricks aren't loading tight, I'm not sure. You're starting it at the top left and writing it. They should just all be in the first 2 rows since you're doing 64 (2 rows) of tiles. I'm not looking far into the code though. If you want to try to debug your code, ise FCEUX and open the debugger. On the top right do "set breakpoint" and make it for the PPU, make it memory location $2000 write, and then make it a write. It may catch a bug because of how it looks like it's writing the tiles, so you may be rewriting them later for some reason. Sorry I couldn't help too much, good luck.

thanks for the tips. I was tweaking with the code and ended up deleting it so i decided to DL the one I uploaded. turns out the code I attached was my code from last year that NA kept on file. lol I did realize that in my background 2,3,and 4 sections I had 1 too many .db in there. I had 9 instead of 8 So I think I might have been over loading the RAM or something.

--------------EDIT--------------

figured it out. I forgot to reset the high/low latch before engading the background loops.  but the extra .db probably didn't help either. Now to get it to look the way I want.

Alright so I have another question. for some reason all the sky background tiles are pulling from the sprite color palette instead of from the background palette. I can't seem to figure out why. could someone please go over the code i have and help me understand what's happening please?

Sprite color 0 is never used in any sprite palette and all the color entries that go into $3F00,$3F04,$3F08,$3F0C,$3F10,$3F14,$3F18,$3F1C have to be the same as the background color*, sprites only get 3 colors, it looks like you're trying to use 4.

* They don't have to be unless you know more how the hardware works, but in these tutorials, keep them the same.

I understand that a sprite gets 3 colors + transparent, and that the colors in the background within a certain area all need to use the same palette. I have the attributes for the background all set to be the same. but for some reason instead of the background having a pale pink color it turns green. I only have green for sprites not the background. and when I change the sprite colors it changes the background. The bricks around the sky are the right color but the sky tile is not. and that's where I'm getting confused.

The sprite palette 0 color isn't used ever, and you assgning it is screwing with your program because the PPU doesn't write to $3F10, it writes over $3F00. It has to match the background color as the sprite transparent color writes miror down to the 3F00-3F0F range.


This shold work. Rename the file when including it too, the names not right. I didn't compile it but I'm fairly confident that this will get the results your after.

http://wiki.nesdev.com/w/index.php/Palette

It looks to me that you're telling $2000 to use the wrong palettes for the sprite/background (unless your comments are just wrong). You should be doing LDA #%10001000 STA $2000, but currently you're doing LDA #%10010000 STA $2000.

alright 3Gen, so what you are saying is that the first color in each palette entry needs to match respectively?

palette:
.db $33,$34,$35,$0F, $33,$34,$35,$0F, $33,$34,$35,$0F, $33,$34,$35,$0F ;;background palette
............^ ............................^................................ ^.............................. ^
............| ..............................|................................ |............................... |
............v ............................v................................ v............................... v
.db $1A,$02,$21,$0F, $22,$02,$38,$3C, $22,$1C,$15,$14, $22,$02,$38,$3C ;;sprite palette

and KHAN, I Switched those around but it pulled the tile data from the wrong area when that happened. What I have is what was in the example from BB.

Yeah, basically, that's the best way to do it. At least the ones at 3F00 and then 3F10 need to, as the 3F10 gets written to 3F00 because 3F10 doesn't exist basically.

And if you upload a full zip file of your code that's not working I'll fix it up and compile it to make sure it's right, and tell you what the problems are.

alright thanks. this was just bugging me. actually my original problem was in the starting pong section but I figured it was because I missed something important in this section. I expanded on it and discovered this problem. So I wanted to make sure i got this understood first. I had to read what you said like 20 times to understand it. but after some sleep it made sense this morning. Thanks for the help. I'll probably be asking for more help in the next section later today if I can't figure it out.

Hello!

After carefuly reading all this topic's posts, there is still one thing that confuses me.
I understood that one attribute byte rules a 32*32 pixels square (i.e. 4*4 tiles).
The screen is 32 tiles width, so 256 pixels, which is a multiple of 32 and is fine.
The screen is 30 tiles height, so 240 pixels, which is not a 32 multiple.
So the last 8 bytes of the attribute table would have a part of them that are useless?

For instance, if my last 8 attributes bytes are :
.db %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000

Can you confirm those represented by "X" could take either 0 or 1 without consequence ?
.db %XXXX0000, %XXXX0000, %XXXX0000, %XXXX0000, %XXXX0000, %XXXX0000, %XXXX0000, %XXXX0000

That's correct.

I never stopped to think about that. Fantastic point.

Thank you very much, it was just something I was wondering before going further in tutorials

This one was nice and easy. The only thing that gave me problems were the BIN attributes, because I am used to fix them on FCEUX's hex editor because of my ROM-Hacking knowledge, just like I did there. Load up incorrect tables in the ASM file, fire the .nes file up in FCEUX, fix it with the Hex Editor and voilà, you have a road for my little dude. Now to learn quick so I can make pedestrians *makes evil grin, thinks about Death Race*

Hi, it's been a couple of week since I'm following those tutorial, there so great and make me feel close to my dream of making my own NES game week after week.

I have a couple of questions, I know that this tutorial is showing how do to generate background/ nametables manually but, you mention that there ''is Some graphics tools [that] will generate this data''. I would like to know:
1) do you really do that method manually everytime you make a game or are you actually using a graphics tools like you mention that help you generate your nametable? the point is that I consider myself more an artist than a hard programmer. if you just could show me a program that could help me saving effort of hard coding something that I litteraly don't see.
2) If you use that kind of program, does it run on Window 8? or is there any that run on Window 8?

Unfortunately, you have to program everything yourself. However, you can program tools that help you with that, like compression routines (Metatile-based, AKA 16x16 tiles for example).
I even programmed a program for the NES that makes it easier to make screens, but it involves a lot of programming knowledge to use it unfortunately

EDIT: Oh lookie! It's an old thing by me when I did the NN for the first time. Time flies by so fast

then, I need know now before going any further, with the knowledge that I can get on the nerdy nights and the rest of programming ressource on Nintendo Age (http://nintendoage.com/forum/mess...) his there any chance that I could done a reel good side scroller on my own?

As a first game?  Definitely not.  But the tools are there to get you to the point where you can, if you put forth the effort.

Seriously! thank you both for your answer, I'll try to go as far as I can! And I won't let myself being stop if I don't understand something. I've just started posting questions And already got answers, I think I'll have nice support in here.

Thank again KHAN Games and Vectrex280996