It is currently Thu Dec 14, 2017 1:23 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Sprite 0 Hit Test ROMs
PostPosted: Wed Oct 05, 2005 5:09 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I've just completed a first version of a sprite 0 hit test ROM suite. In total there are almost 70 different tests performed, covering these main areas:

- Basic behavior
- Relative alignment of background and sprite
- Special cases like background off, left-edge clipping, etc.
- Corner cases and off-by-one errors
- Timing of beginning of frame, pixel, scanline, clearing at VBL
- When multiple pixels hit, which counts as the first hit

sprite_hit_tests.zip

Refer to other documentation for proper behavior or start a new thread if you are wondering about PPU operation (so this thread doesn't get swamped). Reply to this thread if you'd like a better description of what a particular failure code means.

I've improved the result reporting a bit to show the test name and PASS/FAIL. The test framework has also advanced so I can write this kind of test suite quickly (these have taken about 6 hours, where they usually take me days or weeks). This will help when writing future tests.

After writing these tests I've realized that sprite 0 hit allows all sorts of automated tests of the PPU, so I'm having several ideas for more things I can write solid tests for. With sprite 0 hit one can read the entire screen! (though only 60 pixels per frame)

Feedback welcome.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 05, 2005 7:34 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
Well, I found one bug in my emulator - basic test #4 was failing when skipping frames, apparently because I somehow removed 2 checks from my frameskip-optimized code (specifically, checking for background rendering and background clipping). After re-adding those checks (and optimizing their order), it works fine again.

_________________
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: Thu Oct 06, 2005 8:07 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Yay... my latest passed ^^

My older emu chocked on the timing tests (and the right edge) -- I think I wasn't clearing $2002 until the first rendered scanline or something... and I just didn't bother with checking x=255.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 08, 2005 4:36 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
For some reason, my emu hangs in the timing tests. Basically, it waits for the VBlank flag forever. -_-;;

Any suggestions?

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 08, 2005 8:31 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Mine gets error #9 for basic timing, the rest works fine.

Fx3: if I force a shorter vblank time, timing tests hang. Maybe your vblank time is too short ?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 08, 2005 8:42 am 
Offline

Joined: Thu Sep 15, 2005 9:23 am
Posts: 1194
Location: Behind you with a knife!
WedNESday's VBlank time is 2269 CC's. This is the most allowed for blargg's VBlanks test allows. Set it any higher or lower and it fails you.

_________________
http://www.jamesturner.de/


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 08, 2005 9:00 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
NTSC VBlank is 20 scanlines:

20 * 341 = 6820 PPU cycles

/ 3 = 2273.333333 CPU cycles


My understanding is you raise the VBlank flag at the very start of VBlank (and trigger an NMI if enabled) -- then you clear all $2002 flags immediately after those 20 scanlines are complete. This is what my emu does and it passes all these tests.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 08, 2005 9:56 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
The timing tests synchronize with the PPU by waiting for the VBL flag in the usual bit $2002 bpl loop, then going into a loop that waits 29781 clocks (about 10 less the first iteration) and checks the VBL flag. Since the PPU frame is slightly less than 29781 clocks, the loop will eventually "cross over" and see the VBL flag set, at which point it's synchronized.

This is probably where it's hanging, if the timing tests never give a result.

As for hap's error #9, this test uses a background filled with solid tiles using color 1 and a sprite with a solid tile of color 2, and expects a hit to occur. This test was to catch an emulator incorrectly ANDing the background and sprite palette indicies and reporting a hit if this was non-zero. This would fail for colors 1 and 2, since 1 AND 2 = 0. (this is the psychology aspect I was talking about in another post -- you have to think of errors human authors might make, and put tests in to catch those)

As for the actual timing, I haven't worked out the exact values. One nice thing about writing the test ROMs is that I can tweak the delays until they pass on a real NES (being sure I have them generally correct, of course). In the timing tests I report too soon/too late to allow similar adjustment of an emulator. I've done tests based on exact synchronization with the PPU clock and found it to be quite complex. There will be a set of test ROMs soon that test accuracy down to the PPU clock, which will probably fail on most emulators (yes, this is possible, even though the CPU clock is 3x the PPU's).

EDIT: oops... bit $2002 bpl loop, not bmi.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 17, 2005 2:28 pm 
Never mind, the scanline #20 was being handled incorrectly (of 340 or 341 cycles behaviour). Now, the timing tests run - but it gives error #5 for test 9 and error #3 on test 10. What am I supposed to do for proper fix? -_-;;


Top
  
 
 Post subject:
PostPosted: Mon Oct 17, 2005 5:33 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Test ROM 9, result 5 occurs if sprite hit flag is set too late with sprite 0 in the upper-right corner (well, one pixel left of that, otherwise it would fall on column 255 and never report a hit). It might mean that PPU pixels are taking too long (that was the intent behind this test). Test ROM 10 probably fails for the same reason. Once test ROM 9 passes, test ROM 10 will give a meaningful result.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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:  
cron
Powered by phpBB® Forum Software © phpBB Group