About the scanline -1

About the scanline -1
by Zepper on 2012-05-24 (#94461)

From the wiki, "With BG enabled, each odd PPU frame is one PPU clock shorter than normal. I've timed this to occur around PPU clock 328 on the pre-render scanline, but haven't written a test ROM for it yet" (in fact, there's a test ROM now).

That means if the CPU runs for 1 clock, the PPU still runs for 3 clocks, except the scanline -1 logic ends on cycle 340, instead of 341. Is this ok?

Plus, about the cycle 328, I get a "passed" only on cycle 338. Could someone else confirm it?

Re: About the scanline -1
by Bisqwit on 2012-05-25 (#94470)

Zepper wrote:

Plus, about the cycle 328, I get a "passed" only on cycle 338. Could someone else confirm it?

I observed the same about that test.

by infiniteneslives on 2012-05-25 (#94479)

I doubt it helps but all tests pass with flying colors on the NES

by Zepper on 2012-05-25 (#94505)

infiniteneslives wrote:
I doubt it helps but all tests pass with flying colors on the NES

And sorry for disappointing you, but I don't think so... ^_^;;

by infiniteneslives on 2012-05-25 (#94507)

ppu_vbl_nmi.nes RIGHT?

If so I'm not sure what I should be disappointed about...

EDIT: haha I think I get it now. You meant I was right when I said it doesn't help you

by cpow on 2012-05-25 (#94508)

infiniteneslives wrote:
ppu_vbl_nmi.nes

no he was showing you that not ALL tests pass on a real NES...but if I recall the tests he showed are known to be flaky.

by infiniteneslives on 2012-05-25 (#94509)

Well I didn't have any issues after running in a dozen times or so. After your post I tried one more test just for fun and did get test 2 to fail.

I tried it a few more times following that and seemed like #2 failed about half the time. I guess I just got lucky during the first round I ran. #2 is all I've seen though after about 20 tests now. Seems like I'll get streaks where #2 fails or they all pass.

by byuu on 2012-05-25 (#94512)

While a test that shows some pseudo-randomness on real hardware is interesting and could be fun to simulate; I really hope they are sequestered away from other tests. If not, someone should really document exactly which tests are known to fail on hardware.

For the purpose of strict pass and fail, such tests are very dangerous. Any hardware test that has even a 0.0001% chance of failing on any functional NES hardware unit of the same revision is only useful as a curiosity, and it's a bad idea to compare to emulation. At the very least, calling it "pass" or "fail" is clearly wrong, and they should be renamed to reflect their randomness. You could easily get caught up in a situation where passing one test causes another to fail and vice versa. And now you're in a situation where -nobody- could ever achieve a 100% on those silly "emulator benchmark scores."

by Zepper on 2012-05-25 (#94518)

infiniteneslives wrote:
ppu_vbl_nmi.nes RIGHT?

Nope, I mean oam_read.nes.

by infiniteneslives on 2012-05-25 (#94522)

Zepper wrote:
Nope, I mean oam_read.nes.

That's not what you linked to...

But yes I could only pass that on the NES about 1 out 8 trys.

by Zepper on 2012-05-25 (#94523)

infiniteneslives wrote:
Zepper wrote:
Nope, I mean oam_read.nes.

That's not what you linked to...

http://blargg.parodius.com/nes-tests/oam_read_ntsc.png

Re: About the scanline -1
by Drag on 2012-05-25 (#94529)

Zepper wrote:
That means if the CPU runs for 1 clock, the PPU still runs for 3 clocks, except the scanline -1 logic ends on cycle 340, instead of 341. Is this ok?

This is consistent with all of the PPU documentation I'm aware of.

by Zepper on 2012-05-26 (#94537)

Thanks.

About the oam_read test, it fails on resets/power off/on because of the sprite ram data degradation. Such behaviour is expected on hardware.

by thefox on 2012-05-26 (#94540)

Zepper wrote:
About the oam_read test, it fails on resets/power off/on because of the sprite ram data degradation. Such behaviour is expected on hardware.

No. It (obviously) rewrites the OAM each time it runs, and rendering is kept on so the degradation doesn't occur. The reason for the "failing" of this "test" is that OAM reading is broken on NES/Famicom hardware, and that's that.

It's not a test of hardware accuracy. It just tests if OAM reading works like we have always expected it to, before we knew it was broken.

by Zepper on 2012-05-26 (#94543)

Hmm... I had remembered blargg about such sprite ram degradation (or near that), but ok.

Re: About the scanline -1
by ermular on 2012-10-25 (#101779)

I also found that 10-even_odd_timing.nes only passed if I skipped pixel #338.