Reply with any questions about a failure code or about the proper behavior of the flag.
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
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
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.
Then feel free to register on the new wiki and add your summary.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.
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?
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.
Nope. Clearing it at the end of VBlank along with $2002.7 and .6 ( n2002Status = 0; )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.
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.
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.It's very possible that my problem is completely unrelated
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.
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.blargg wrote: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.Disch, why don't you try that 8-sprites demo by C.Covell? It's the best testing.