A few NES PPU test ROMs

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

A few NES PPU test ROMs

Post by 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

Post by 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).
User avatar
hap
Posts: 355
Joined: Thu Mar 24, 2005 3:17 pm
Contact:

Post by hap »

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

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

Post by 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.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper »

Great stuff. Anyway, what's the power-up values of palette???
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by 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
Posts: 96
Joined: Sat Nov 13, 2004 6:25 am

Re: A few NES PPU test ROMs

Post by 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.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by 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.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit »

My old NES would always flash blue, sometimes purple for one reset cycle.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Muchaserres
Posts: 96
Joined: Sat Nov 13, 2004 6:25 am

Post by Muchaserres »

blargg wrote: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.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

Muchaserres wrote: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).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
Muchaserres
Posts: 96
Joined: Sat Nov 13, 2004 6:25 am

Post by 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?
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by 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.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
Muchaserres
Posts: 96
Joined: Sat Nov 13, 2004 6:25 am

Post by Muchaserres »

Thanks again. It is always interesting to know these kind of things.
Quietust wrote: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..
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

Dwedit wrote: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. :)
Post Reply