nesdev.org

Hello NES developers :D I have a question related to NES palette colours https://www.google.com.eg/search?hl=ar&site=imghp&tbm=isch&source=hp&biw=1366&bih=658&q=nes+colour+palette&oq=nes+colou&gs_l=img.3.0.0i19.31.1338.0.3010.5.5.0.0.0.0.291.587.0j2j1.3.0....0...1ac.1...

Ok , you can continue to the SIPO , I understand

yes I understand but I have a question

what is really the horizontal scroll ? I think it is counter ranging from 0 --> 255 for the 256 pxl on the screen , Is this true?

I will fully understand your comment , after answering this question.

I have traced it and I understand how those values come and manipulated through the example but still I cant connect this with how they are rendered :( :( Did you understand this so far? If not, how did you think fine scrolling (by distances less than 8 pixels) would be accomplished? answering your ...

I understand this and how data in pattern tables and attributes are translated into sprites , this is not what confusing me I drew this to illustrate what I am thinking in https://s31.postimg.org/rb8yys1if/my_view.png here , we have 4 of 8 bit SIPO shift registers , loaded with the data during the f...

I am sorry again but I did not get it

Could you explain why but in much details ?

I know this but why it can't go as follows :

I fetch the pattern bit , attributes bit ( both for 8 pixels ) , put them in a shift register then output

why all of the other registers are found ? ( specially SIPO why I would need a parallel output ? )

Sorry I didn't get it again

c.A serial-in, parallel-out (SIPO) shift register fed by shift register A, to delay bit 0 of pixel data for fine scrolling d.A SIPO shift register fed by shift register B, to delay bit 1 of pixel data for fine scrolling e.A SIPO shift register fed by attribute bit 0, to delay bit 2 of pixel data fo...

Like OAM, palette memory (also called Color Generator Random Access Memory, or CGRAM) is on a separate bus. The eight fetches from CGRAM happen in parallel to the fetches from video memory, one for each pixel. So can I understand from this that after the 4 bits are fetched they are used again to ad...

can you please explain in much detail ? telling me if I am right or not and thank's

Hello NES developers :D I have some confusing questions related to the PPU 1- As far as I understood , the output which is 4 bits and equivalent to a pixel , the 4 bits are ( 2 from pattern table and 2 from attribute table ) to be concatenated forming 4 bits which is an index to a color in the palet...

So that's why it fetches th 1st two tiles of scanline 4 by the end of scanline 3 ?

Will it differ a lot if I implemented it in a shifted way ( ie : rendering on the screen in the last 256 clock , filling the sprite buffers and fetching background data from clk 0 to clk (340-265 ) ?

As I understood from you now and from search ( and tell me If I am right or not ) - sprites for scanline 4 was ready in the buffers by the end of scanline 3 and the shift registers out them from clock 0 -> 256 in scanline 4 - sprites memory has its own bus so both background and sprites can be fetch...

Sorry I didn't get it I know how render stages flow for both BG and sprites, but I am confused how if they are parallel they access the memory both in the same time also if now I am in scanline 4 , do I in the last steps in 4 fetch graphics for scanline 5 ( next scanline ) then start scanline 5 by r...

I have some questions about the way PPU render both sprites and background I knew that for every scanline , the 256 px is feed from the sprite and background buffer ( after being multiplexed on priority ) such that a px come out each PPU clock here I have two questions : 1 - Does the rendered graphi...