A few NES PPU test ROMs

[blargg]

I've written a few NTSC PPU tests that I used to verify the PPU in my NES emulator. They use the same format as my previous APU tests, reporting the result with a code on screen and a number of beeps (I like this format because it's easy to write new tests and I can keep the asm source files really short). I had a few more tests I wanted to include but couldn't get them to work reliably on my NES.

blargg_ppu_tests.zip

- Palette RAM access, mirroring, transparent entry mirroring
- VRAM read/write, read buffer operation, effect of palette read on read buffer
- Sprite RAM read and write, third byte masking, $4014 DMA copying
- Power-up values of palette (based on what my NES gives back)
- Time VBL flag is cleared

The asm source should help if it's unclear as to what a particular test is doing. Feedback welcome.

[james123]

Nice one, blargg. Please DO keep them coming. The more the better. Perhaps write one that tests the WHOLE PPU like NEStress does. Although I must admit my emulator fails most of 'em (sob).

[hap]

vbl_clear_time.nes gives me a black screen (also with Nintendulator)

*edit* What 'few more tests' did you want to include ?

[james123]

yeah vbl_clear_time.nes just appears as a grey screen on my emulator. Other tests could include testing absolutely every aspect of the PPU no matter how vague. I am going to write something myself someday.

[Zepper]

Great stuff. Anyway, what's the power-up values of palette???

[blargg]

Sorry about the VBL hanging. I found that I was testing on my NES using the serial-based console instead of the graphics-based one (I need to simplify my build setup). I added a fix, re-tested them properly (I hope), and updated the archive.

The power-up values of the palette are what my test program reads back after powering the NES. I have one of the older units that shows a green screen (I think newer front-loading ones had a gray screen). These values probably vary slightly from one console to the next.

Code: Select all

Palette at power-up

0x09,0x01,0x00,0x01,
0x00,0x02,0x02,0x0D,
0x08,0x10,0x08,0x24,
0x00,0x00,0x04,0x2C,
0x09,0x01,0x34,0x03,
0x00,0x04,0x00,0x14,
0x08,0x3A,0x00,0x02,
0x00,0x20,0x2C,0x08

One I wanted to include tests the timing of sprite 0 hit flag clearing, upper-left corner, upper-middle, and the same on the second scanline. I figured that this would catch major timing errors in sprite hit code. But on my NES it often fails one of the tests, seemingly at random.

I doubt I'll write lots of PPU tests since the detailed behavior of the PPU is exceedingly complex (or so I've read). Also I have modest aims for the PPU in my emulator (scanline accuracy only).

[Muchaserres]

I get the 6th error in "VRAM access" test, which translates into "Palette read should also read VRAM into read buffer". Could anyone tell me what is the expected behaviour here? I guess it has something to do with "read buffer operation" and "third byte masking"..

By the way, nice work blargg!
Thx in advance.

[blargg]

Confusion is likely due to my terseness (but at least anyone can correct that).

Reading from $2007 when the VRAM address is $3fxx will fill the internal read buffer with the contents at VRAM address $3fxx, in addition to reading the palette RAM.

The "third byte masking" refers to the third byte (attributes) of each sprite not having all bits implemented, where writing $ff is equivalent to writing $e3.

[Dwedit]

My old NES would always flash blue, sometimes purple for one reset cycle.

[Muchaserres]

Confusion is likely due to my terseness (but at least anyone can correct that).

Reading from $2007 when the VRAM address is $3fxx will fill the internal read buffer with the contents at VRAM address $3fxx, in addition to reading the palette RAM.

The "third byte masking" refers to the third byte (attributes) of each sprite not having all bits implemented, where writing $ff is equivalent to writing $e3.

Uhm.. I still don't get it (sorry). Aren't "the contents at VRAM address $3fxx" and "palette RAM" contents at address $xx the same thing?

Anyway, is that the expected behaviour of the PPU? And if so, what is it useful for?

Thx again.

[Quietust]

Uhm.. I still don't get it (sorry). Aren't "the contents at VRAM address $3fxx" and "palette RAM" contents at address $xx the same thing?

No, they are not the same thing. Palette RAM consists of twenty-eight 6-bit words of DRAM embedded within the PPU and accessible when the VRAM address is between $3F00 and $3FFF (inclusive). When you read PPU $3F00-$3FFF, you get immediate data from Palette RAM (without the 1-read delay usually present when reading from VRAM) and the PPU will also fetch nametable data from the corresponding address (which is mirrored from PPU $2F00-$2FFF). This phenomenon does not occur during writes (as it would result in corrupting the contents of the nametables when writing to the palette) and only happens during reading (since it has no noticeable side effects).

[Muchaserres]

Thanks Quietust, that clears it up. Just one more question, which may be offtopic, but.. is PPU $3000-$3EFF really a mirror of PPU $2000-$2EFF? And if so, what is the point of it being like that? I mean, wouldn't it be more practical to have the palettes at PPU $3000-$3F1F? A restriction of the PPU hardware scheme?

[Quietust]

The PPU does not natively access PPU $3000-$3FFF during any of the rendering process, but it IS possible to map ROM/RAM at that location and then access it $2006/$2007. The VRAM region $3F00-$3FFF is effectively read-only (and reading it is rather cumbersome).

Mapping palettes at $3000-$3F1F makes absolutely no sense - if anything, the palette could have been mapped at $3FE0-$3FFF only, but that would have required checking additional address lines (i.e. more hardware). One significant advantage of using $3F00-$3FFF is that the first write to $2006 discards the upper 2 bits, so you can write $FF,$00 (using INX/INY) to jump to the palette.

[Muchaserres]

Thanks again. It is always interesting to know these kind of things.

The PPU does not natively access PPU $3000-$3FFF during any of the rendering process, but it IS possible to map ROM/RAM at that location and then access it $2006/$2007. The VRAM region $3F00-$3FFF is effectively read-only (and reading it is rather cumbersome).

So, if I understand it right, it is the cartridge who maps PPU $2000-$2FFF at PPU $3000-$3FFF, isn't it? I don't really see any advantage in using this address range to map RAM/ROM.. is it there any program which actually takes any advantage of it?

Excuse me if all those questions sound too stupid or something..

[blargg]

My old NES would always flash blue, sometimes purple for one reset cycle.

Kind of interesting. I always thought my memories of a green screen at startup were shared by other NES owners, but now I find I might be among a minority! Almost like the philosophical issue of whether anyone else sees colors as one does. :)