Sprite Overflow Flag 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:

Sprite Overflow Flag Test ROMs

Post by blargg » Fri Mar 31, 2006 12:48 pm

I've completed the sprite overflow flag (bit 5 of $2002) test ROMs (thanks for the nudge, Disch). They test general operation, timing, and the obscure pathological behavior when the PPU starts interpreting other sprite bytes as Y coordinates.

sprite_overflow_tests.zip

Reply with any questions about a failure code or about the proper behavior of the flag.

User avatar
Zepper
Formerly Fx3
Posts: 3192
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper » Fri Mar 31, 2006 1:09 pm

Here's my results:

0. OK
1. #5
2. #2 -_-;; Another headache, hahah :P

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Fri Mar 31, 2006 2:00 pm

Hah! I'm failing the basics test XD

I didn't expect that -- guess my prediction routine is messed. Glad I finally have something to test it. I mean up until now I just had to hope it worked, since I didn't really have any way to see if it did or not.

Excellent work as always blargg =) Thanks a bunch. Timing couldnt've been better either, I just finished fine-tuning this latest emu so that it passes all the other test ROMs. ;D

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

Post by blargg » Fri Mar 31, 2006 2:25 pm

Here are approximate times (in CPU clocks) that the tests look for:

Code: Select all

0       VBL begins
2272    Flag cleared
2429    Earliest it can be set on first scanline
2465    Latest it can be set for first scanline (when 64th sprite causes overflow)
2542    Earliest it can be set on second scanline
29595   Earliest it can be set on last scanline
The overflow flag time for a scanline is the earliest time for that scanline + 2 PPU clocks * the sprite # that caused the overflow (numbering sprites from zero). The earliest match can be on the sprite #8, and the latest on the sprite #63, so the timing above is 63 - 8 = 55 sprites * 2 PPU clocks per sprite = 110 PPU clocks / 3 = 36.7 CPU clocks.

I added another useful test case to 3.Obscure and updated the archive. Oh, and luckily in this case 3.Obscure doesn't depend on 2.Timing working at all; it only depends on 1.Basics passing. I think my summary of the obscure behavior in the readme should be easier to understand than that listed on the Wiki, since mine is geared towards describing this one aspect of behavior only, rather than all the internal operations.

tepples
Posts: 21875
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Fri Mar 31, 2006 2:39 pm

blargg wrote:I think my summary of the obscure behavior in the readme should be easier to understand than that listed on the Wiki, since mine is geared towards describing this one aspect of behavior only, rather than all the internal operations.
Then feel free to register on the new wiki and add your summary.

User avatar
Zepper
Formerly Fx3
Posts: 3192
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper » Fri Mar 31, 2006 6:00 pm

"NES... Get its bugs/quirks/obscure things working for perfect emulation" ^_^;;.
Funny machine.

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Fri Mar 31, 2006 7:12 pm

Okay I feel stupid.

I'm still getting error #3 on the basics test -- "3) Should be set when 9 sprites are on a scanline".

There's no way this can be my problem -- I spent about a half hour trying to figure out where my calculations were off, and after coming up empty I tried removing my checks and just having $2002.5 return high when polled at any time the PPU is on and out of VBlank -- still error 3... despite that not making any sense (if the flag is always high, how could the test be thinking it's low?)

I've got some other kind of problem elsewhere -- but it's hard to nail down. I was going to check the source for the test ROM to see what it's expecting so I could iron the problem out -- but to my dismay I found the source was not included ;_;

Any thoughts on what could cause an error 3 besides the flag not returning high when it should?

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

Post by blargg » Fri Mar 31, 2006 8:25 pm

I know the problem: you're clearing the flag at the beginning of VBL; it should be cleared at the end of VBL. I could also improve my test to not rely on this until it's run the later sub-test that gives a proper error for this. I just re-uploaded the archive again with the source code. I had figured nobody ever actually examined it. I also hope to switch things over to ca65 at some point so it'll assemble out-of-the-box.

Another thing I'm working on is another test ROM that tries to expose bugs in a non-trivial emulator implementation, like the one I use which calculates in advance the time the flag would be set and invalidates this when it might have changed. This is subject to subtle bugs that require specific tests to expose, but that would never occur on a straightforward emulator that did everything one cycle at a time without any optimization.

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Fri Mar 31, 2006 9:25 pm

blargg wrote:I know the problem: you're clearing the flag at the beginning of VBL; it should be cleared at the end of VBL.
Nope. Clearing it at the end of VBlank along with $2002.7 and .6 ( n2002Status = 0; )

I'll redownload and tinker more tomorrow -- gonna sleep.

It's very possible that my problem is completely unrelated, and that somehow this demo is just bringing it to the surface. Comparing a tracelog of the test ROM to the source and knowing what it's expecting will be a great help =) That's where I'll start tomorrow.

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

Post by blargg » Sat Apr 01, 2006 9:20 am

I've updated the archive again with a fix so improper clearing at the beginning of VBL will be reported clearly. I usually break my emulator in the appropriate way to cause each test to fail (which is kind of neat), but had skipped this before apparently.
It's very possible that my problem is completely unrelated
Seems unlikely if you were hard-wiring the flag to be always raised. Only other possibility that comes to mind is your sprite DMA. My code is clearing $2003 before writing $02 to $4014 to transfer page 2 to sprite RAM. Anyway, hope you figure it out.

Marty
Posts: 40
Joined: Fri Nov 12, 2004 5:02 am

Post by Marty » Sat Apr 01, 2006 10:49 am

Great stuff. Got them working at last. Test #5 and #7 in 3.Obscure.nes sure had me scratching my head for quite some time though. :)

User avatar
Zepper
Formerly Fx3
Posts: 3192
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper » Sat Apr 01, 2006 11:15 am

Disch, why don't you try that 8-sprites demo by C.Covell? It's the best testing.

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

Post by blargg » Sat Apr 01, 2006 1:19 pm

Disch, why don't you try that 8-sprites demo by C.Covell? It's the best testing.
Does it give a detailed report of the problem? Sure, games like Battletoads are great for finding whether your emulator has problems, but not so great for diagnosing what the problem is.

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Sat Apr 01, 2006 1:51 pm

I found the problem.

The basic idea behind my setup is that I'd keep a timestamp of a predicted time that the flag would rise. When the time has yet to be predicted, it has a time of -1 -- then when $2002 is read, if the value is -1, I actually predict the time and raise the flag if appropriate. If something happens that could change the time (PPU turned on/off, $4014 written to, etc), the time resets to -1.

The problem is... blargg's demo wasn't reading $2002 during the frame, so my time was never being predicted. $2002 wasn't being read until the next VBlank -- by which time my emu thought it was too early to predict anything (too early in the current frame).

I messed around with solutions, but I think my whole implimentation needs a serious revision. Since seeing this problem, other potential problems with this method have surfaced as well.

User avatar
Zepper
Formerly Fx3
Posts: 3192
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper » Sat Apr 01, 2006 2:25 pm

blargg wrote:
Disch, why don't you try that 8-sprites demo by C.Covell? It's the best testing.
Does it give a detailed report of the problem? Sure, games like Battletoads are great for finding whether your emulator has problems, but not so great for diagnosing what the problem is.
It only shows 8 sprites and a 9th controlled by the Dpad. When overflow (=9), the screen becomes gray from that point, up to frame end. Great to check if the overflow bit is working properly.

Post Reply