nesdev.org

I some how understand some parts of what you said like usage of CX in nametable addressing

I will be really happy if I knew how the fine x changes allover this timing diagram

http://wiki.nesdev.com/w/images/d/d1/Ntsc_timing.png

I think this may solve my problem .

till your comment I was thinking of it as a counter XXXX Xxxx the lower 3 bits are the fine and the upper 5 are the coarse the are used in rendering such that XXXXX -> the tile number , xxx -> a pixel inside the tile no. XXXXX while rendering , I believed that the is incrementing rendering from left...

tepples wrote:Fine x doesn't count.

How ? I didn't understand

thank you all , I have noticed it when I read it again I have another question now as stated in nesdev wiki , background buffers are shift registers , and the lower 8 bits are fed to 8x1 mux (for each register of the four registers) and fine_x used as selections for those muxs my question is how the...

then how T is edited during the entire frame ?

I only read that V is reloaded from T , but the data in T how it is calculated ?

T is the "scroll" setting. T is used to automatically reload V at the top of the screen to start drawing the new frame with the desired scroll. It also partially reloads V at the end of every line, just the horizontal bits, again to keep the desired scroll position. sorry I didn't get it ...

I may understand regsiter V but what is the importance of register T ?

sorry but I didn't get it but I think you want to refer that the vertical counters are different from scanline counters?

and pixel counters (from 0 to 340) differs from the horizontal counter ?

If we are scrolled to 0,0 on upper-left name table, we use NN = 0, YYYYY = 0, XXXXX = 0, we get this address: 010000000000000 I have a problem with this example although this is the address of the first tile in the name table , it should be fetched at clks 321 , 322 at those clks , if we tried to e...

it seems I have a problem with counters arrangement till now , I think that counters are chained as follows MSB-------------------LSB YYYYY yyy XXXXX xxx YYYYY -> 5 bits indicating tile no. (vertically) yyy -> fine ver xxx -> fine hor XXXXX-> 5 bits indicating tile no. (horizontally) that's also how...

check that the coarse X is incremented correctly.

So how it is incremented correctly ?

Hello :) I have now a question about background rendering I know that the background rendering starts 2 tiles ahead before the real output of the tile according to the this http://wiki.nesdev.com/w/images/d/d1/Ntsc_timing.png we fetch the first two tiles of scanline (S) in clks from 321 -> 336 of sc...

Thank's

I thought they are rendered as a one block not a multiple ones

Hello NES developers

I have a question related to sprite sizes in NES.

I know that the PPU deals with either 8x8 or 8x16 sprites and this what the PPU is configured to deal with

but I read that in real NES , there were 16x16 , 24x24

how then the PPU deals with them ?

thank's in advance

Most emulators just use a palette table to map the NES colours to RGB colours for the output system.

that's good, now how they map the 2 and the 4 bits to an RGB 24 bit color code ?