NTSC emulation test?
Moderator: Moderators
I should write a "TV colors" test which displays checkerboards of particular colors that will appear identical to another solid color on an NTSC TV, but not on an emulator that only does RGB. It'd display images that you couldn't make out unless you have proper NTSC emulation. Then you wouldn't be able to claim you pass all my tests unless you do NTSC too.
The quick brown Fox jumps over the lazy dog!
Last edited by Zepper on Sun Jun 03, 2007 6:54 am, edited 1 time in total.
Zepper
RockNES author
RockNES author
Unless the emulator author adds support for the PlayChoice's second screen. Then the author has an excuse for why the emulated PPU is RGB. Are you planning on making tests for that?blargg wrote:I should write a "TV colors" test which displays checkerboards of particular colors that will appear identical to another solid color on an NTSC TV, but not on an emulator that only does RGB. It'd display images that you couldn't make out unless you have proper NTSC emulation. Then you wouldn't be able to claim you pass all my tests unless you do NTSC too.
That would be a really cool test ROM if the image it displayed read "TV Colors Test: PASSED" under an NTSC display and "TV Colors Test: FAILED" on an emulator that only does RGB. But would that be possible? For example, have both messages displayed on the screen, but each message is displayed in a different color pattern, so that under NTSC, "TV Colors Test: PASSED" was readable and "TV Colors Test: FAILED" was not readable.blargg wrote:I should write a "TV colors" test which displays checkerboards of particular colors that will appear identical to another solid color on an NTSC TV, but not on an emulator that only does RGB. It'd display images that you couldn't make out unless you have proper NTSC emulation. Then you wouldn't be able to claim you pass all my tests unless you do NTSC too.
A similar thing has been done before. There are tests for seeing if a human is color blind, where the person will see a "5" if they are not color blind and a "2" if they are color blind, even though it is the same static image. An example exists at the bottom of this page:
http://www.toledo-bend.com/colorblind/Ishihara.html
Anyway, that would get my vote for most creative test ROM for the NES
Someone please test this on an NTSC NES and tell me what you see:
http://pics.pineight.com/nes/tvpassfail.zip
http://pics.pineight.com/nes/tvpassfail.zip
I don't have a dev cart to load the ROM on, but I was testing it out under Nestopia. Its pretty cool how well it works. The interesting thing about this kind of test ROM is that, unlike other kinds of tests, the test ROM doesn't know the difference, but the observer definitely knows the difference.tepples wrote:Someone please test this on an NTSC NES and tell me what you see:
http://pics.pineight.com/nes/tvpassfail.zip
Can you make an image that is visible with RGB, invisible with NTSC?
This test relies on the 3:2 exact relationship between NES pixels and NTSC color subcarrier cycles. There are 3 non-transparent colors per tile on an NES; this ROM uses a 3-color pattern to trigger luma/chroma crosstalk. PAL, on the other hand, uses a 6:5 relationship, which makes it a bit harder to trigger crosstalk, and emulators tend not to have a PAL mode.
Maybe a similar thing could be done so that it only says "PASS" on a PAL NES? It would be cool if emulators supported emulation of specific NES, Famicom, and arcade systems... warts and all.Bregalad wrote:This is pretty amazing. I wonder how it looks on a PAL TV, but I guess it'd be pretty much the same, only slightly different.
It'd be more difficult to make a screen pattern that exploits luma/chroma crosstalk for PAL because each pixel covers more of a color subcarrier cycle (5/6 of one rather than 2/3), and because no emulator supports PAL yet.Jagasian wrote:Maybe a similar thing could be done so that it only says "PASS" on a PAL NES?
Wouldn't this require emulation of the lockout chip?It would be cool if emulators supported emulation of specific NES, Famicom, and arcade systems... warts and all.
But what about distinguishing a PAL PPU from a hypothetical SCART (RGB) PPU?Dwedit wrote:Detecting whether a game is being run on an NTSC or PAL system is very easy.
(Clarification: The existing SCART NES is a PAL NES with an internal PAL decoder.)
Like the swapping of 25% and 50% duty pulse waves found in too many famiclones, right? What about an aliasing test, which would play a high-frequency 12.5% duty pulse wave at high frequencies? What about some tests about the resetting of the various APU counters other than the linear or length counter, such as the period counter? Or maybe some test of APU DAC nonlinearity?Jagasian wrote:What other observation based NES tests are there? That is, tests where the ROM itself can't tell the difference between the real system and inaccurate emulation, but the user can easily observe the difference? Maybe some sound test?
Input latency is tricky to measure without taking the human brain's reaction time into account. But making sure that the buttons don't always change state on the same scanline might be a good idea.Maybe an input latency test?
I love tvpassfail! Here's what it displays running on my NTSC NES (as opposed to an RGB emulator, shown on right):
There are plenty more tests like this that could be written. They can still be automated in an emulator by having a human verify that they pass, saving the emulator's output (audio/video), then having your test script compare to that in the future.
Time for a thread split it seems.
Sure, if you're testing PlayChoice support, you'll get RGB, but if you're testing NES support, it had better do composite NTSC/RF in its accurate mode.tepples wrote:Unless the emulator author adds support for the PlayChoice's second screen.
Yes. Several aspects of the APU, like the triangle's length counter, aren't reflected in the status register. You can probably think of many: proper frequency of waveforms, DAC volume levels, DMC sample playing. Same for controller input as you say. Interestingly, most aspects of the PPU can be verified by using sprite #0 hit. Theoretically you could read the entire screen in terms of transparent/not transparent, though only one pixel per frame, so it'd take most of a day to do so.Jagasian wrote:What other observation based NES tests are there? That is, tests where the ROM itself can't tell the difference between the real system and inaccurate emulation, but the user can easily observe the difference? Maybe some sound test? Maybe an input latency test?
There are plenty more tests like this that could be written. They can still be automated in an emulator by having a human verify that they pass, saving the emulator's output (audio/video), then having your test script compare to that in the future.
Time for a thread split it seems.
Last edited by blargg on Sun Jun 03, 2007 10:28 am, edited 1 time in total.