It is currently Wed Oct 18, 2017 2:19 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 33 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: A few NES PPU test ROMs
PostPosted: Thu Sep 15, 2005 5:02 am 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 15, 2005 5:32 am 
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).


Top
  
 
 Post subject:
PostPosted: Thu Sep 15, 2005 8:45 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
vbl_clear_time.nes gives me a black screen (also with Nintendulator)

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 15, 2005 9:12 am 
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.


Top
  
 
 Post subject:
PostPosted: Thu Sep 15, 2005 10:52 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Great stuff. Anyway, what's the power-up values of palette???

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 15, 2005 12:04 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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 [url="http://www.slack.net/~ant/nes-tests/blargg_ppu_tests.zip"]archive[/url].

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:
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).


Top
 Profile  
 
PostPosted: Fri Sep 16, 2005 9:25 am 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 10:30 am 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 10:54 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
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!


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 3:43 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 3:57 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 4:36 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 5:07 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 5:36 pm 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2005 5:43 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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. :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 33 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group