NTSC PPU timing by Samus Aran (livingmonolith@hotmail.com) date: Sept. 25th, Y2K This weekend, I setup an experiment with my NTSC NES MB & my PC so's I could RE the PPU's timing. What I did was (using a PC interface) analyse the changes that occur on the PPU's address and data pins on every rising & falling edge of the PPU's clock. I was not planning on removing the PPU from the motherboard (yet), so basically I just kept everything intact (minus the stuff I added onto the MB so I could monitor the PPU's signals), and popped in a game, so that it would initialize the PPU for me (I used DK classics, since it was only taking somthing like 4 frames before it was turning on the background/sprites). The only change I made was taking out the 21 MHz clock generator circuitry. To replace the clock signal, I connected a port controlled latch to the NES's main clock line instead. Now, by writing a 0 or a 1 out to an PC ISA port of my choice (I was using $104), I was able to control the 21 MHz clockline of the NES. After I would create a rise or a fall on the NES's clock line, I would then read in the data that appeared on the PPU's address and data pins, which included monitoring what PPU registers the game read/wrote to (& the data that was read/written). My findings: - The PPU makes NO external access to name or character tables, unless the background or sprites are enabled. This means that the PPU's address and data busses are dead while in this state. - Because the PPU's palette RAM is internal to it, the PPU has multiport access to it, and therefore, instant access to it at all times (this is why reading palette RAM via $2007 does not require a throw-away read). This is why when a scanline is being rendered, never does the PPU put the palette address on it's bus; it's simply unneccessary. Additionally, when the programmer accesses palette RAM via $2006/7, the palette address accessed actually does show up on the PPU's external address bus, but the PPU's /R & /W flags are not activated. This is required; to prevent writing over name table data falling under the approprite mirrored area. I don't know why Nintendo didn't just devote an exclusive area for palette RAM, like it did for sprite RAM. - Sprite DMA is 6144 clock cycles long (or in CPU clock cycles, 6144/12). 256 individual transfers are made from CPU memory to a temp register inside the CPU, then from the CPU's temp reg, to $2004. - One scanline is EXACTLY 1364 cycles long. In comparison to the CPU's speed, one scanline is 1364/12 CPU cycles long. - One frame is EXACTLY 357368 cycles long, or EXACTLY 262 scanlines long. Sequence of pixel rendering --------------------------- External PPU memory is accessed every 8 clock cycles by the PPU when it's drawing the background. Therefore, the PPU will typically access external memory 170 times per scanline. After the 170th fetch, the PPU does nothing for 4 clock cycles (except in the case of a 1360 clock cycle scanline (more on this later)), and thus making the scanline up of 1364 cycles. accesses -------- 1 thru 128: 1. Fetch 1 name table byte 2. Fetch 1 attribute table byte 3. Fetch 2 pattern table bitmap bytes This process is repeated 32 times (32 tiles in a scanline). This is when the PPU retrieves the appropriate data from PPU memory for rendering the background. The first background tile fetched here is actually the 3rd to be drawn on the screen (the background data for the first 2 tiles to be rendered on the next scanline are fetched at the end of the scanline prior to this one). In one complete cycle of fetches (4 fetches, or 32 cycles), the PPU renders or draws 8 pixels on the screen. However, this does not suggest that the PPU is always drawing on-screen results while background data is being fetched. There is a delay inside the PPU from when the first background tile is fetched, and when the first pixel to be displayed on the screen is rendered. It is important to be aware of this delay, since it specifically relates to the "sprite 0 hit" flag's timing. I currently do not know what the delay time is (as far as clock cycles go). Note that the PPU fetches a nametable byte for every 8 horizontal pixels it draws. It should be understood that with some custom cartridge hardware, the PPU's color area could be increased (more about this at the end of this document). It is also during this time that the PPU evaluates the "Y coordinate" entries of all 64 sprites (starting with sprite 0) in sprite RAM, to see if the sprites are within range (to be drawn on the screen) FOR THE NEXT SCANLINE. For sprite entries that have been found to be in range, they (that is, the sprite's nametable, and x coordinate bytes, attribute (5 bits) and fine y scroll (3 or 4 bits, depending on bit 5 of $2000 ("sprite size")) bits) accumulate into a part of PPU memory called the "sprite temporary memory", which is big enough to hold the data for up to 8 sprites. If 8 sprites have accumulated into the temporary memory and the PPU is still finding more sprites in range for drawing on the next scanline, then the sprite data is ignored (not loaded into the sprite temporary memory), and the PPU raises a flag (bit 5 of $2002) indicating that it is going to be dropping sprites for the next scanline. 129 thru 160: 1. Fetch 2 garbage name table bytes 2. Fetch 2 pattern table bitmap bytes for applicable sprites ON THE NEXT SCANLINE This process is repeated 8 times. This is the period of time when the PPU retrieves the appropriate pattern table data for the sprites to be drawn on the next scanline. Where the PPU fetches pattern table data for an individual sprite depends on the nametable byte, and fine y scroll bits of a single sprite entry in the sprite temporary memory, and bits 3 and 5 of $2000 ("sprite pattern table select" and "sprite size" bits, respectively). The fetched pattern table data (which is 2 bytes), plus the associated 5 attribute bytes, and the x coordinate byte in sprite temporary memory are then loaded into a part of the PPU called the "sprite buffer memory". This memory area again, is large enough to hold the contents for 8 sprites. The makeup of one sprite memory cell here is composed of 2 8-bit shift registers (the fetched pattern table data is loaded in here, where it will be serialized at the appropriate time), a 5-bit latch (which holds the attribute data for a sprite), and a 8-bit down counter (this is where the x coordinate is loaded). The counter is decremented every time the PPU draws a pixel on screen, and when the counter reaches 0, the pattern table data in the shift registers will start to serialize, and be drawn on the screen. Even if no sprites exist on the next scanline, a pattern table fetch takes place. Although the fetched name table data is thrown away, I still can't make much sense out of the name table address accesses the PPU makes during this time. However, the address does seem to relate to the first name table tile to be rendered on the screen. It should also be noted that because this fetch is required for sprites on the next line, it is neccessary for a garbage scanline to exist prior to the very first scanline to be actually rendered, so that sprite RAM entries can be evaluated, and the appropriate bitmap data retrieved. Finally, it would appear to me that the PPU's 8 sprite/scanline bottleneck exists clearly because the PPU could only find the time in one scanline to fetch the pattern bitmaps for 8 sprites. However, why the PPU doesn't attempt to access pattern table data in the time when it fetches 2 garbage name table bytes is a good question. 161 thru 168: 1. Fetch 1 name table byte 2. Fetch 1 attribute table byte 3. Fetch 2 pattern table bitmap bytes This process is repeated 2 times. It is during this time that the PPU fetches the appliciable background data for the first and second tiles to be rendered on the screen for the next scanline. The rest of tiles (3..128) are fetched at the beginning of the following scanline. 169 thru 170: 1. Fetch 1 name table byte This process is repeated 2 times. I'm unclear of the reason why this particular access to memory is made. The nametable address that is accessed 2 times in a row here, is also the same nametable address that points to the 3rd tile to be rendered on the screen (or basically, the first nametable address that will be accessed when the PPU is fetching background data on the next scanline). After memory access 170, the PPU simply rests for 4 cycles (or the equivelant of half a memory access cycle) before repeating the whole pixel/scanline rendering process. If the scanline being rendered is the very first one on every second frame, then this delay simply doesn't exist. Sequence of line rendering -------------------------- 1. Starting at the instant the VINT flag is pulled down (when a NMI is generated), 20 scanlines make up the period of time on the PPU which I like to call the VINT period. During this time, the PPU makes NO access to it's external memory (i.e. name / pattern tables, etc.). 2. After 20 scanlines worth of time go by (since the VINT flag was set), the PPU starts to render scanlines. Now, the first scanline it renders is a dummy one; although it will access it's external memory in the same sequence it would for drawing a valid scanline, the fetched background data is thrown away, and the places that the PPU accesses name table data is unexplainable (for now). IMPORTANT! this is the only scanline that has variable length. On every second rendered frame, this scanline is only 1360 cycles. Otherwise it's 1364. 3. after rendering 1 dummy scanline, the PPU starts to render the actual data to be displayed on the screen. This is done for 240 scanlines, of course. 4. after the very last rendered scanline finishes, the PPU does nothing for 1 scanline (i.e. makes no external memory accesses). When this scanline finishes, the VINT flag is set, and the process of drawing lines starts all over again. This makes a total of 262 scanlines. Although one scanline is slightly shorter on every second rendered frame (4 cycles), I don't know if this feature is neccessary to implement in emulators, since it only makes 1/3 a CPU cycle difference per frame (and there's NO way that a game could take into account 1/3 of a CPU cycle). Food for thought ---------------- What's important to remember about the NES's 2C02 or picture proecssing unit (hereon PPU) is that all screen data is fetched & drawn on a real-time basis. For example, let's consider how the PPU draws background tiles. We know that one name table byte is associated with an 8x8 cluster of pixels (and therefore, 16 bytes worth of pattern bitmap data, plus 2 attribute bits). Therefore, it would make sense for the PPU to only have to fetch a name table byte once for each 8x8 pixel array it draws (one tile), and 1 attribute byte fetch for every 4x4 tile matrix that it draws. However, since the PPU always draws one complete scanline before drawing the next, The PPU will actually fetch the same name table byte 8 times, once each scanline at the appropriate x coordinate. Since these name table address access reads are redundant, with some custom cartridge hardware, it would be possible to make the PPU appear as if it had background tiles as small as 8x1 pixels! Additionally, an attribute table byte is fetched from name table RAM once per 2 fetched pattern bitmap bytes (or, every 8 pixels worth of pattern bitmap data). This is useful information to keep in mind, for with some custom cartridge hardware, this would allow the NES's PPU to appear to have an effective color area as small as of 8*1 pixels (!), where only the 8 pixels are limited to having 4 exclusive colors, which, is *alot* better than the PPU's default color area of 16x16 pixels. So basically, what I'm getting at here, is that the PPU has absolutely NO memory whatsoever of what it rendered last scanline, and therefore all data must be processed/evaluated again, whether it's name table accesses, attribute table accesses, or even it's internal sprite RAM accesses. What's good, and what's bad about the way the PPU draws it's pictures: What's good about it is that it makes the PPU a hell of alot more versatile, provided you have the appropriate hardware to assist in the improvement of the PPU's background drawing techniques (MMC5 comes to mind). Also, by doing background rendering in the real time, the PPU complexity is less, and less internal temporary registers are required. What's bad about it is that it eats up memory bandwidth like it's going out of style. When the PPU is rendering scanlines, the PPU is accessing the VRAM every chance it gets, which takes away from the time that the programmer gets to access the VRAM. In contrast, if redundantly loaded data (like attribute bytes) were kept in internal PPU RAM, this would allow some time for the PPU to allow access to it's VRAM. All in all though, Nintendo engineered quite a cost effective, versatile graphic processor. Now, if only they brought the 4 expansion pins on the PPU out of the deck!