nesdev.org

my suggestion would be to learn more about how the 6502 works and then move to the nes specific concepts

how familiar are u with 6502 assembly?

the name table to write to is specified via writes to $2006. lda $2002 lda #$20 sta $2006 lda #$00 sta $2006 change the high byte to $24, $28, or $2C for the other tables, but keep in mind mirroring is also in effect. If i opened up the .chr file and .dat would they look the same. what makes them so...

an extension is just a tool to help identify whats in a file. i myself wouldn't use the .chr extension on name table data, just to avoid confusion, but you are free to. i chose the .dat extension as an example.

just realize that the extension is not the important part, its what the data represents.

first you'll need 2 bytes labeled 'addrLO' and 'addrHI' in zp for indirect,y addressing. ; somewhere in code ; load the destination in vram lda $2002 lda #$20 sta $2006 lda #$00 sta $2006 ; load the destination of the name table lda #low(nametable) sta addrLO lda #high(nametable) sta addrHI jsr SubL...

are you asking how to draw to a specific point on the screen or how to draw a specific tile

post something with a little more detail because there could be many things.

correct me if i'm wrong but the palette consists of $20 entries. eight of those are mirrors of color 0 starting at $3F00 and its the every 4th one. half the palette is used for drawing sprites and the other half is for backgrounds. the whole $20 byte palette is mirrored many times in PPU address spa...

the problem was i over-complicated the situation. after sleeping for awhile i now have a better idea as to handleing the labels.

i've got the bank system figured out and now i have to get the labels working correctly and i'll have a functioning assembler. the biggest problem is with zero page.

now what if there is only one 16k bank at $8000, it would get loaded into $8000 and $C000...correct? therefore forcing to start at $FFFA wouldn't make much sense seing how the bank would stop at $BFFF. should i auto-detect that and switch the vector table to $BFFA, so when the rom is loaded the vect...

how do those assemblers handle interrupt vectors

what would be the better option: 1. use a banking scheme similar to nesasm but more robust, where the assembler takes care of writing the prg and chr banks in the correct order 2. writing a seperate program that reads in a seperate text file which contains the header and the order of the banks. then...

For the nes thats true, but the people who wrote the nes games we all love probably wrote software before, for other systems using a 65xx processor and possibly out of habit set it to a known value. Even though it doesn't matter. That would be my best guess.

I always thought is was to set the flag to a known state, err thats what i do it for anyways.