Hello,
I am writing a NES emulator, and Brad Taylor's "NTSC 2C02 technical reference" says that at the end of a playfield tile fetch phase for a given tile, its just fetched pattern table bytes #0 and #1 are put into the most significant bytes of two 16-bit shift registers that shift right every PPU clock cycle.
The 2 bits of pallete select data for this particular tile are loaded in two 8-bit shift registers, also shifted every clock, to implement fine horizontal scrolling with the correct pallete select data.
Depending on fine horizontal scroll value(0...7), bit 0 - 7 is selected in all 4 shift registers. These four bits are used as the pallete index for the current playfield pixel.
The document also states that:
As we know, at scanline cycles 0..255, 32 tile fetches occur, the first one being for the 3-rd tile drawn on the current scanline, and the last two - for the first two tiles of the next scanline.
Each tile fetch consists of 4 fetches(2 clock cycles each):
1. Fetch Name table byte
2. Fetch Attribute table byte
3. Fetch Pattern table bitmap #0
4. Fetch Pattern table bitmap #1
So each complete tile fetch takes 8 PPU clock cycles.
Now, I will try to illustrate what I believe to be the shift register behaviour:
If that is correct, it would mean that:
1. Before the PT byte is latched into the MSB of a reg, the reg is first shifted right.
2. After PT is latched into the MSbyte , no further shifts are made during this cycle.
3. The pallete select data is loaded into the first bit of the 8bit AT shift registers EXACTLY 9 CC's after the corresponding tile fetch starts(if it starts at the beginning of CC0, the first palette value will be shifted into the AT shift register during CC9).
4. the pixel data is fet to the video out pin AFTER all shifts for the current cycle are made
I have one more question. As far as I know, A pattern table byte is drawn like this:
leftmost pixel ->01011001<- rightmost pixel
The screen ray moves from left to right on the screen ->
Now, if we load the PT byte into the leftmost byte of the 16-bit shift register, and shift it right every clock, the first bit to reach the video out pin will be the bit of the rightmost tile pixel, which the TV ray will draw as the leftmost, and will flip the tile horizontally.
So, isn't it really the least significant byte of the shift reg that is loaded with the PT byte, and isn't it shifted left every clock?
Cheers,
Evtim
I am writing a NES emulator, and Brad Taylor's "NTSC 2C02 technical reference" says that at the end of a playfield tile fetch phase for a given tile, its just fetched pattern table bytes #0 and #1 are put into the most significant bytes of two 16-bit shift registers that shift right every PPU clock cycle.
The 2 bits of pallete select data for this particular tile are loaded in two 8-bit shift registers, also shifted every clock, to implement fine horizontal scrolling with the correct pallete select data.
Depending on fine horizontal scroll value(0...7), bit 0 - 7 is selected in all 4 shift registers. These four bits are used as the pallete index for the current playfield pixel.
The document also states that:
Quote:
the precise delay between when a tile's bitmap fetch phase starts (the whole 4 memory fetches), and when the first pixel of that tile's bitmap data hits the video out pin, the formula is (16-n) clock cycles, where n is the fine horizontal scroll offset (0..7 pixels).
As we know, at scanline cycles 0..255, 32 tile fetches occur, the first one being for the 3-rd tile drawn on the current scanline, and the last two - for the first two tiles of the next scanline.
Each tile fetch consists of 4 fetches(2 clock cycles each):
1. Fetch Name table byte
2. Fetch Attribute table byte
3. Fetch Pattern table bitmap #0
4. Fetch Pattern table bitmap #1
So each complete tile fetch takes 8 PPU clock cycles.
Now, I will try to illustrate what I believe to be the shift register behaviour:
Code:
0 - meaningless data
1 - data for tile #1
2 - data for tile #2
3 - data for tile #3
4 - data for tile #4
the 16-bit value indicates one of the 16-bit PT shift registers
the 8-bit value(prefixed tith *)
indicates one of the 8 bit AT palette select shift registers.
CC MSByte LSByte
CC 00 22222222|11111111 <- Fetch phase for tile #3 begins at the beginning of CC 0
CC 01 02222222|21111111 (takes cycles 0..7)
CC 02 00222222|22111111
CC 03 00022222|22211111
CC 04 00002222|22221111
CC 05 00000222|22222111
CC 06 00000022|22222211
CC 07 00000002|22222221
CC 08 33333333|22222222 <- Tile #3 fetch phase ends at the end of CC7
CC 09 03333333|32222222 (the 16-bit register is FIRST shifted, and then
*32222222 MSB updated with #3 byte)
CC 10 00333333|33222222
*33222222
CC 11 00033333|33322222
*33322222
CC 12 00003333|33332222
*33332222
CC 13 00000333|33333222
*33333222
CC 14 00000033|33333322
*33333322
CC 15 00000003|33333332
*33333332
CC 16 44444444|33333333 <- If fine horizontal scroll is 0, the first
*33333333 tile #3 pixel will be drawn at CC 16
CC 17 04444444|43333333
CC 18 00444444|44333333
1 - data for tile #1
2 - data for tile #2
3 - data for tile #3
4 - data for tile #4
the 16-bit value indicates one of the 16-bit PT shift registers
the 8-bit value(prefixed tith *)
indicates one of the 8 bit AT palette select shift registers.
CC MSByte LSByte
CC 00 22222222|11111111 <- Fetch phase for tile #3 begins at the beginning of CC 0
CC 01 02222222|21111111 (takes cycles 0..7)
CC 02 00222222|22111111
CC 03 00022222|22211111
CC 04 00002222|22221111
CC 05 00000222|22222111
CC 06 00000022|22222211
CC 07 00000002|22222221
CC 08 33333333|22222222 <- Tile #3 fetch phase ends at the end of CC7
CC 09 03333333|32222222 (the 16-bit register is FIRST shifted, and then
*32222222 MSB updated with #3 byte)
CC 10 00333333|33222222
*33222222
CC 11 00033333|33322222
*33322222
CC 12 00003333|33332222
*33332222
CC 13 00000333|33333222
*33333222
CC 14 00000033|33333322
*33333322
CC 15 00000003|33333332
*33333332
CC 16 44444444|33333333 <- If fine horizontal scroll is 0, the first
*33333333 tile #3 pixel will be drawn at CC 16
CC 17 04444444|43333333
CC 18 00444444|44333333
If that is correct, it would mean that:
1. Before the PT byte is latched into the MSB of a reg, the reg is first shifted right.
2. After PT is latched into the MSbyte , no further shifts are made during this cycle.
3. The pallete select data is loaded into the first bit of the 8bit AT shift registers EXACTLY 9 CC's after the corresponding tile fetch starts(if it starts at the beginning of CC0, the first palette value will be shifted into the AT shift register during CC9).
4. the pixel data is fet to the video out pin AFTER all shifts for the current cycle are made
I have one more question. As far as I know, A pattern table byte is drawn like this:
leftmost pixel ->01011001<- rightmost pixel
The screen ray moves from left to right on the screen ->
Now, if we load the PT byte into the leftmost byte of the 16-bit shift register, and shift it right every clock, the first bit to reach the video out pin will be the bit of the rightmost tile pixel, which the TV ray will draw as the leftmost, and will flip the tile horizontally.
So, isn't it really the least significant byte of the shift reg that is loaded with the PT byte, and isn't it shifted left every clock?
Cheers,
Evtim