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!