It is currently Wed Sep 19, 2018 6:38 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Mar 31, 2006 12:48 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 31, 2006 1:09 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3153
Location: Brazil
Here's my results:

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

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 31, 2006 2:00 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 31, 2006 2:25 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Here are approximate times (in CPU clocks) that the tests look for:

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 31, 2006 2:39 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20556
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 31, 2006 6:00 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3153
Location: Brazil
"NES... Get its bugs/quirks/obscure things working for perfect emulation" ^_^;;.
Funny machine.

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 31, 2006 7:12 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
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?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 31, 2006 8:25 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 31, 2006 9:25 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 01, 2006 9:20 am 
Offline
User avatar

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

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 01, 2006 10:49 am 
Offline

Joined: Fri Nov 12, 2004 5:02 am
Posts: 40
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. :)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 01, 2006 11:15 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3153
Location: Brazil
Disch, why don't you try that 8-sprites demo by C.Covell? It's the best testing.

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 01, 2006 1:19 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 01, 2006 1:51 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 01, 2006 2:25 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3153
Location: Brazil
blargg wrote:
Quote:
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.

_________________
Zepper
RockNES developer


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

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:  
Powered by phpBB® Forum Software © phpBB Group