ppu reset tests

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
ppu reset tests
by on (#34686)
- What does make "2000 context" test to fail? What about "2005 context"? I'm putting zero for the loopy_v and the default value for the register as zero and... the test still prints "2000 should be zero".

- Anything more that I don't know of?

by on (#34692)
"$2000 contents" tests bits 3-5 ($38) of $2000 to be sure power/reset clears them. It sets up a background and sprite #0 and checks that the proper collision occurs. Double-height sprites or either coming from the wrong pattern bank will cause a fail.

"$2005 contents" is similar to the above. It leaves $2005 uninitialized, so that any change in scroll will move the background and upset the proper collision.

Have you run all tests? Knowing all that pass and fail would help.

by on (#34703)
- Here we go...
Code:
$2000 contents OK *
$2000.03 contents OK
$2000.03 write at 0 OK
$2000.03 write at 29657 FAIL
$2000.03 write at 29658 OK
$2000.3C write at 29657 FAIL
$2000.04 write at 0 OK
$2000.04 write at 29658 OK
$2000.38 write at 0 OK
$2000.38 write at 29658 OK
$2000.80 contents OK
$2000.80 write at 0 OK
$2000.80 write at 29657 FAIL
$2000.80 write at 29659 OK
$2001.18 write at 29656 OK
$2001.E1 contents (Orange screen with no glitches) OK?
$2001.E1 write at 0 (Solid gray) OK
$2001.E1 write at 29657 (Orange then solid gray) FAIL?
$2001.E1 write at 29659 (Solid gray) OK
$2002.80 contents OK
$2002.80 set at 27383 (source only?)
$2003 contents OK
$2003 write at 0 OK
$2004 read at 0 OK
$2004 write at 0 OK
$2005 contents OK *
$2005 write at 0 OK *
$2005 write at 29657 FAIL
$2005 write at 29658 OK *
$2006 contents OK
$2006 even-odd OK
$2006 write at 0 OK
$2006 write at 29656 FAIL
$2006 write at 29658 OK
$2007 buffer contents OK
$2007 write at 0 OK
$4014 write at 0 OK

by on (#34713)
Since $2000 and $2005 contents fail, take a look at common/test_bg_spr.inc. test_2000 and test_2005 are the entry points. After setting appropriate registers (and leaving the tested one unmodified), they set up VRAM, setup a single sprite that has one pixel within a background that has a one-pixel "hole", and test for collision at two positions. The VRAM setup is the only tricky part, where it never writes to PPUADDR ($2006), only PPUDATA ($2007). It writes $4000 bytes of data so that all areas of VRAM/palette get initialized, leaving PPUADDR at whatever it was when the routine started.

Here's a modified version of the test that makes the operation visible: 2000_contents_fx3.nes.zip

Magnified, you get two frames like this, where the sprite falls in the hole in the first frame, so there's no hit, then hits the background when it moves left one pixel:
Image

by on (#34716)
It was an error writting to the nametables:
Code:
           int tempaddr = ppu->refresh & 0x3FFF;
           //CHR-RAM
           if(tempaddr < 0x2000) {
              write_ppu(tempaddr, data);
           }
           //Nametables
           else {
              _ppubank_write((tempaddr>>10)&0xB,tempaddr&0x3FF,data);
           }


- I wasn't masking the tempaddr>>10 with 0xB. Now, it's fixed.
- Additionally, it fixes Ian Bell's tank demo! :)