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!
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.
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.
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
tepples wrote:
Someone please test this on an NTSC NES and tell me what you see:
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.
Can you make an image that is visible with RGB, invisible with NTSC?
Quote:
Can you make an image that is visible with RGB, invisible with NTSC?
To output "failed" if that test is ran with RGB? If it's not possible, it could just output "tv test failed", and add a "not" for NTSC.
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.
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.
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.
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.
Detecting whether a game is being run on an NTSC or PAL system is very easy.
Jagasian wrote:
Maybe a similar thing could be done so that it only says "PASS" on a PAL NES?
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.
Quote:
It would be cool if emulators supported emulation of specific NES, Famicom, and arcade systems... warts and all.
Wouldn't this require emulation of the lockout chip?
Dwedit wrote:
Detecting whether a game is being run on an NTSC or PAL system is very easy.
But what about distinguishing a PAL PPU from a hypothetical SCART (RGB) PPU?
(Clarification: The existing SCART NES is a PAL NES with an internal PAL decoder.)
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?
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?
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?
Quote:
Maybe an input latency 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.
I love tvpassfail! Here's what it displays running on my NTSC NES (as opposed to an RGB emulator, shown on right):
tepples wrote:
Unless the emulator author adds support for the PlayChoice's second screen.
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.
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?
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.
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.
What emu did you use to take that screenshot?
Here what it looks like on RockNES anyways...
Bigger:
The passing image was a video capture from my NTSC NES. The failing image was from my NES emulator in RGB mode.
Can the test's bit pattern be tweaked to further obfuscate the "PASS!" message, when not displayed under NTSC?
Jagasian wrote:
Can the test's bit pattern be tweaked to further obfuscate the "PASS!" message, when not displayed under NTSC?
Not that I can think of right now.
But pixel aspect ratio is another bugaboo of mine, and I've added a second screen to the
test program.
Nifty update. People so often post about aspect ratio problems for various emulators, and then other people give wrong authoritative answers like "A TV's width is 4:3 the height, therefore pixels are rectangular with the same ratio", even though the width of a pixel depends on the particular console, etc. I'll have to adapt your code to the SNES (including your flashy anti-aliased font heh).
tepples wrote:
Jagasian wrote:
Can the test's bit pattern be tweaked to further obfuscate the "PASS!" message, when not displayed under NTSC?
Not that I can think of right now.
But pixel aspect ratio is another bugaboo of mine, and I've added a second screen to the
test program.
I just tested Nestopia using your latest TV test ROM, and the 1:1 box is definitely not square, but the NTSC box is just a little bit too tall. I actually measured with a ruler. I am using Nestopia's "TV Aspect" setting. Can anybody else confirm that Nestopia's aspect ratio is just slightly off, or is it user error on my part?
Nestopia is probably within the tolerance for consumer TV sets, as all CRTs are calibrated slightly different.
I just tested the Mac version of Nestopia. In full-screen mode, with aspect ratio correction set to 4:3. I took a full-screen screenshot (Command-Shift-3) and drew a diagonal line on the NTSC box from upper-left to lower-right. The line hit at the bottom edge, not even close to the corner. Even without drawing the line, I could tell that the box was wider than it was tall.
I'll post this at the Nestopia message board. The aspect ratio problem was brought up there before, and Richard Bannister claimed that the aspect ratio was correct. So much for that claim. When I first got Emulator Enhancer, I knew its aspect ratio correction was off, but I didn't have evidence to prove it. Now there is proof.
I can't verify the other test, though, because for some reason Nestopia is crashing every time I try to check the NTSC filter option (ugh!).
Before you bug Richard Bannister, I'd like to have the second screen tested on NES hardware on a couple different TVs first.
Maybe Nestopia calculates the aspect ratio based on NTSC_OUT_WIDTH from blargg's NTSC library, which width is about 3% too wide in favour of optimisations.
(it's what Sega Li does, with a bit too wide square as result)
*edit* Anyway, nice test tepples, and I agree with:
Quote:
Nestopia is probably within the tolerance for consumer TV sets, as all CRTs are calibrated slightly different.
tepples wrote:
Before you bug Richard Bannister, I'd like to have the second screen tested on NES hardware on a couple different TVs first.
Even without the test ROM, I could tell (by comparing with two different TVs in my household) that the aspect ratio in Nestopia for Mac OS X was stretched too far horizontally (it was enough for me to notice within seconds after I got Emulator Enhancer, which is what adds the aspect ratio correction feature).
That said, testing on real hardware will help validate the test as accurate (at least within a particular margin of error), so I am all for hardware testing.
Jagasian: did you first measure with a ruler a square box drawn with a graphics program? That'd rule out your monitor itself not being calibrated for the PC's square pixels.
hap: Using nes_ntsc, the NTSC box appears about 163x160 pixels; an emulator should display the output vertically doubled and horizontally unchanged, or some factor for both of those; the number of pixels in the image should have no part in aspect ratio handling.
tepples: Below are some camera shots of a TV connected to an NTSC NES running your latest test. For the aspect ratio test, the boxes were 75 mm high, and 80 mm, 61mm, and 85 mm wide from left to right. I also did a test shot of a square object (not shown) to verify that my digital camera's pixels are square. Oh, and you might want to add an
epilepsy warning for the NTSC test, as it flickered a bunch on the TV (probably due to the PPU alternating between two phases between frames, rather than your code slowly shifting the diagonal pattern).
(the TV is less warped in the right shot because I moved farther away and zoomed in, exactly for this purpose)
OK, I took the TV image and compared it against the Nestopia screenshot, and the image from Nestopia is obviously wider. If I draw a diagonal line on the NTSC box in the TV image, the line almost hits the corner exactly (it's only slightly to the left of the lower-right corner), but in Nestopia, the line is pretty distant from the corner.
Again, this is the Mac port. The Windows version of Nestopia may have different results.
Only Nestopia is the main point of this discussion? If another test pops, any error on Nestopia will be the main topic?
Feel free to list any other emulators which fail either test, and one or more of us can bug the author to get it fixed. How does RockNES fare on the aspect ratio test?
Why is there animosity against testing the accuracy of the emulation of how a real NES system's video looks? Was there a time when people hated the emulation of the NES's slowdown?
Jagasian wrote:
Why is there animosity against testing the accuracy of the emulation of how a real NES system's video looks?
Because it appears people
prefer the PlayChoice look.
tepples wrote:
Jagasian wrote:
Why is there animosity against testing the accuracy of the emulation of how a real NES system's video looks?
Because it appears people
prefer the PlayChoice look.
I love the way the Apple II's video output looks, but I sure as hell don't think a NES emulator should try to emulate the Apple II's video output.
blargg wrote:
Jagasian: did you first measure with a ruler a square box drawn with a graphics program? That'd rule out your monitor itself not being calibrated for the PC's square pixels.
I made a square using GIMP and measured it, and it is a perfect square. Then I ran tepples test ROM again, in Nestopia, and measured the NTSC box to be 7.9cm x 8.2cm. Note that I am using a laptop's display to do all of this. So it is a digital display at 1900 x 1200 native pixels.
tepples wrote:
But pixel aspect ratio is another bugaboo of mine, and I've added a second screen to the
test program.
That's hot. Nice work, tepples.
blargg wrote:
Nifty update. People so often post about aspect ratio problems for various emulators, and then other people give wrong authoritative answers like "A TV's width is 4:3 the height, therefore pixels are rectangular with the same ratio", even though the width of a pixel depends on the particular console, etc. I'll have to adapt your code to the SNES (including your flashy anti-aliased font heh).
That would probably include me, sadly. Though I don't claim that all TVs are
exactly 4:3, I was under the impression both NTSC and PAL were relatively close.
Is 48:35 the authoritive "average" aspect ratio for PAL height:width? Google is failing me.
byuu wrote:
That would probably include me, sadly. Though I don't claim that all TVs are exactly 4:3, I was under the impression both NTSC and PAL were relatively close.
Is 48:35 the authoritive "average" aspect ratio for PAL height:width? Google is failing me.
The actual aspect ratio (on both NTSC and PAL) is primarily dependent on the number of pixels per scanline (including overscan). Both the NES and SNES generate pixels at the same frequency (ignoring the SNES's Hi-Res mode here), so the aspect ratios should remain the same when comparing NES to SNES output. The fact that the SNES renders fewer scanlines per field (224/239 instead of 240) should not have an impact on the aspect ratio AFAIK.
byuu wrote:
Is 48:35 the authoritive "average" aspect ratio for PAL height:width?
I took the 8:7 ratio that we had previously worked out for NTSC and multiplied it by 6:5, the PAL scale factor.
Quote:
Google is failing me.
The PAL color subcarrier is 4433618.75 Hz, and there are 6 pixels per 5 color cycles, meaning the PAL PPU runs at 5320342.5 Hz. Apparently, the active picture area is
51.95 microseconds wide. 51.95 * 10^-6 s * 5320342.5 pixels/s = about 276.4 pixels per active line. Treating 276.4x288 pixels as a 4:3 picture means that 276.4 pixels across is the same as 384 pixels down, for a 1.389:1 pixel aspect ratio, which is just a smidgen wider than the 1.371:1 that the test program assumes. I'll hazard a guess that a +/- 3% tolerance is OK; just don't assume 1.0:1.
The only discrete aspect of an NTSC/PAL image is scanlines. Those are an all-or-nothing thing. Anything on screen is a multiple of a scanline height. The width, on the other hand, depends on the video chip that's generating the image. A video chip could make a pixel as wide as the entire screen, and one scanline tall, or as narrow as it likes (too narrow and it will cause artifact colors, as on the Apple II in high-res mode). Thus, there is no such thing as a pixel for NTSC/PAL, just a scanline whose color/brightness/saturation changes over its length, in response to what the video signal is doing at that moment.
If one must define a pixel, it'd make most sense to base its width on a single color carrier cycle. For the TV I posted the images of, we can calculate the size of a pixel using this definition. The NTSC box was 70x80 NES pixels, and measured 80x75 mm on screen. This gives a NES pixel size of 1.1429x0.9375 mm, with an width/height ratio of 1.2191, or about 11/9. A NES pixel's width is 2/3 of a color carrier cycle, so a pixel the width of a single color carrier cycle is 1.7143x0.9375 mm, with an width/height ratio of 1.8333, or about 11/6. Put another way, a square pixel on this particular TV could be achieved by having the video chip make each pixel last 0.5455 (~6/11) of a color carrier cycle, (which is close to what the Sega Genesis does).
I just realized that with tepples' test, an emulator author can side-step the whole issue by providing a "stretch" slider that affects how wide the image appears on the PC monitor. The user is then instructed to adjust this until the appropriate NTSC/PAL box appears nearly square. This takes everything into account, including a PC display that doesn't have square pixels, with an absolute minimum of work.
So... the NTSC thing isn't only the output of your filter, but the aspect ratio too? Here's something...
double sized, 512x480 pixelated
stretched 256x240 into 640x480
Yes, NTSC video handling conceptually includes how rectangular each pixel is in addition to the color mixing and artifacts, since the rectangularity is different for PAL. With tepples' test, you can ignore the math and simply focus on whether the NTSC box is nearly square or not; if it is, then the rectangularity of NES pixels is (very likely) handled correctly. Your 256x240->640x480 expansion shows the NTSC box very close to square, thus it's correct.
Ok, so basically ...
Code:
void update_video_settings() {
uint width = 256;
uint height = config::video.region == SNES::NTSC ? 224 : 239;
uint multiplier = minmax<1, 5>(uint(config::video.multiplier));
width *= multiplier;
height *= multiplier;
if(config::video.aspect_correction == true) {
if(config::video.region == SNES::NTSC) {
width = uint( double(width) * 8.0 / 7.0 );
} else /* config::video.region == SNES::PAL) */ {
width = uint( double(width) * 48.0 / 35.0 );
}
}
window_main.resize(width, height);
window_main.view.resize(width, height);
}
That should do, then?
PAL seems really really wide, but I'll trust your math since I've never seen a PAL TV before :/
Resizing isn't that easy as far as I know. There's loss of quality if you do this.
byuu wrote:
PAL seems really really wide, but I'll trust your math since I've never seen a PAL TV before :/
I can't provide an authoritative answer, not having the luxury of a PAL TV myself, but I have read that the total number of visible scanlines per frame on PAL is significantly larger than the number of lines output by the (S)NES, resulting in a somewhat letterboxed display. (Someone can correct me if I'm wrong.)
Is there anybody here who can take a PAL snapshot of the test ROM? We have yet to verify the accuracy of the PAL box in the test.
byuu wrote:
That should do, then?
Wait until we make a test ROM for SNES, then the answer will be completely reliable. "Show me your image" instead of "show me your code" will be sufficient.
Fx3 wrote:
Resizing isn't that easy as far as I know. There's loss of quality if you do this.
Only noticeable if you consider perfectly crisp pixels to be the quality standard. If you're aiming for even an RGB monitor, there will be natural blurring at the edges and even scaling with linear interpolation will look fine (but of course nearest neighbor will never look good, since it adds way too much error).
If someone wants to draw a 256x224x256-color (or less) bitmap, I can make an SNES ROM with a test image. But we need someone with a PAL copier + TV to verify.
I'll use 48/35 for now, until we hear otherwise. I'd be happy with NES verification, too. It actually doesn't look that bad.
Meh, maybe I should just buy a PAL TV and SNES, I think my UFO is supposed to work on both. I've been asking questions on PAL for over two years and never gotten anything concrete :/
EDIT: darn, doesn't seem they sell PAL CRTs very often anymore, and the ones they do seem to be those dual NTSC/PAL ones. Maybe that will work, maybe not ...
byuu wrote:
EDIT: darn, doesn't seem they sell PAL CRTs very often anymore, and the ones they do seem to be those dual NTSC/PAL ones.
A conforming dual NTSC/PAL TV should switch to PAL "pixel" aspect ratio (where "pixel" = 1/341 scanline period) when fed a PAL signal.
byuu wrote:
If someone wants to draw a 256x224x256-color (or less) bitmap, I can make an SNES ROM with a test image. But we need someone with a PAL copier + TV to verify.
I'll use 48/35 for now, until we hear otherwise. I'd be happy with NES verification, too. It actually doesn't look that bad.
Meh, maybe I should just buy a PAL TV and SNES, I think my UFO is supposed to work on both. I've been asking questions on PAL for over two years and never gotten anything concrete :/
EDIT: darn, doesn't seem they sell PAL CRTs very often anymore, and the ones they do seem to be those dual NTSC/PAL ones. Maybe that will work, maybe not ...
I got a crappy PAL TV and a SNES with a SWC DX2.. so I could probably try it out.
edit: but I probably would need some instructions on what I'm supposed to do when testing it
I figured some people here might be interested in this ...
http://board.zsnes.com/phpBB2/viewtopic ... 142#148142
Verdauga Greeneyes took a screenshot of
http://i73.photobucket.com/albums/i221/byuusan/som.gif , at a very high resolution (2592x1944), and with a tripod to make sure the image was minimally slanted. I then cropped the "Secret of Mana" logo out of the picture.
Below are my results:
Code:
127x 43 = 2.953488 -- 256x239 1:1 image size
1140x272 = 4.191176 -- CRT TV image size
43x4.191176 = 180.220568
180.220568 / 127 = 1.419060
So, ~1.42x is very close to tepples' ~1.39x, enough to be the difference between two different TV sets.
But, as we can see, it's definitely way off compared to NTSC's 8:7 (~1.14x). I will probably use a rounded average between our three samples. Maybe 1.40x. It's "close enough", but probably not 100% perfect.
If anyone wants, I can forward them the PAL TV screenshot for double verification. I know it's not a perfect test, but it's the best we can do.
Quote:
It's "close enough", but probably not 100% perfect.
I think it's clear that there is no "perfect", since TVs differ slightly in how they distort the image.
I think porting tepple's test to the SNES is a perfect solution, along with emulator authors providing a horizontal stretch slider so that the user can make the correct box square on whatever they're displaying the emulator with. This way the user can calibrate it as closely as desired, or throw it off to match a particular TV.
We should add NTSC/PAL detection to the ROMs to simplify things for the user.
If you capture the TV output through a video card and measure the frame, isn't this the correct thing?
EDIT: OK, now I'm curious. If you output the emulator image to the TV, the test still fails. Why?
Fx3 wrote:
OK, now I'm curious. If you output the emulator image to the TV, the test still fails. Why?
If your emulator assumes square pixels, then your video card will just shoot those square pixels straight out to the TV, likely at 7/12 color cycle per pixel, unless you can tell your video card to run in some 560x480 pixel overscan mode.
Quote:
If you output the emulator image to the TV, the test still fails. Why?
Because TVs don't have pixels, just scanlines whose hue/saturation/luminance varies from left to right. It's the video
ENCODER chip that determines the width of a pixel. The NES has a different video encoder than your PC's video output, so the pixel width probably differs. Your PC's video output probably uses a pixel width that matches scanline height, resulting in square pixels on the TV screen, because PC pixels are usually square and you'd want the image to appear nearly the same on a TV as it does on your PC display.
There's really no difference between the above situation and a normal PC video card connected to a CRT-based display. In the same way, the PC video card determines the width of a pixel, and could make them rectangular if it wanted.
I thought this aspect ratio business was a done deal already.
Quote:
If you capture the TV output through a video card and measure the frame, isn't this the correct thing?
Most TV cards don't capture the image properly, at least not with default settings.
Correct pixel aspect ratio (NTSC):
Active scanline is 52+59/90 µs (ITU-R BT.470-6). NES' pixel clock is precisely 6/4*Fsc = 7,5*63/88 MHz, giving 282.7 pixels, or 282 full pixels horizontally.
Active height is 486 scanlines for interlaced, or 243 for progressive pictures (one is always black in progressive, so 242. Since that black line is part of the 4:3 area however, we must include it).
Therefore, the NES active area including overscan is 282x243. For square pixels forming a 4:3 image, you'd need 243*4/3=324 horizontal pixels, giving you the NTSC NES'
precise pixel aspect ratio of 324/282, or
54/47, about 1.148936
Correct pixel aspect ratio (PAL):
Active scanline is 52 µs (ITU-R BT.1700). NES' pixel clock is (1135/4 + 1/625)*15625*6/5 Hz, giving 276.7 pixels, say 276 full pixels.
Active height is 576 scanlines for interlaced, or 288 for progressive.
Therefore, the NES active area including overscan is 276x288. For square pixels, we'd need 288*4/3=384 horizontal pixels, giving you the PAL NES'
precise pixel aspect ratio of 384/276, or
32/23, about 1.391304.
These values are what you should go for, not by empirically measuring screencaps from consumer-grade TV cards, which rarely get things right, or pushing a ruler against your TV. And if you're trying to get your emulator to imitate the image of every cheap-ass TV out there, you'd have to simulate curvature, overscan, phosphor chromaticities and aperture, dust on the tube, the influence of the earth's magnetic field depending on your particular geographic location (no, really!)...
NewRisingSun wrote:
Correct pixel aspect ratio (NTSC):
Active scanline is 52+59/90 µs (ITU-R BT.470-6). NES' pixel clock is precisely 6/4*Fsc = 7,5*63/88 MHz, giving 282.7 pixels, or 282 full pixels horizontally.
Active height is 486 scanlines for interlaced, or 243 for progressive pictures (one is always black in progressive, so 242. Since that black line is part of the 4:3 area however, we must include it).
Therefore, the NES active area including overscan is 282x243. For square pixels forming a 4:3 image, you'd need 243*4/3=324 horizontal pixels, giving you the NTSC NES'
precise pixel aspect ratio of 324/282, or
54/47, about 1.148936
324/282.7 is still damn close to the 324/283.5 resulting from the easy-to-compute-with assumption that scanline height = 7/12 of the width of a color cycle. (Interestingly enough, this results in the 14x12 pixel metatiles of several Apple II games being perfect squares.)
Quote:
For square pixels, we'd need 288*4/3=384 horizontal pixels, giving you the PAL NES'
precise pixel aspect ratio of 384/276, or
32/23, about 1.391304.
I get 1.38800 by not rounding the 276.66 down, but whatever. Good job on coming up with the data behind the exact values.
Quote:
And if you're trying to get your emulator to imitate the image of every cheap-ass TV out there, you'd have to simulate curvature, overscan
The whole 256x224 myth comes from emus that simulate overscan the wrong way.
Quote:
324/282.7 is still damn close to the 324/283.5
The standard allows quite some tolerance for the blanking and thus for the active duration of a scanline. But blargg already found that that the NES does indeed 282 pixels including overscan.
The only question is whether that weird
"pulse" pixel should be considered part of the active area or not; if so, we would need to go with 283 and 324/283 (1.144876) pixel aspect ratio, which would be most unfortunate, since 283 is a prime number.
(I have seen this pulse on imported Japanese NTSC VHS videos, too; never on US ones. I suspect this has something to do with NTSC-J, maybe a help for the TV to properly center the picture, as it can no longer tell the active from the blanking area by looking for a 7.5% setup.)
blargg wrote:
Oh, and you might want to add an
epilepsy warning for the NTSC test, as it flickered a bunch on the TV (probably due to the PPU alternating between two phases between frames, rather than your code slowly shifting the diagonal pattern).
Done.
blargg wrote:
We should add NTSC/PAL detection to the ROMs to simplify things for the user.
Done.
New version uploaded
Dammit, now I have to make FlashMe for this nes demo....
In reply to tvpassfailHave any of you seen this? It looks to be very thorough multi-platform test (minus NES).
http://junkerhq.net/xrgb/index.php/240p_test_suiteLinearity test is extra useful.
aspectyl wrote:
Have any of you seen this? It looks to be very thorough multi-platform test (minus NES).
http://junkerhq.net/xrgb/index.php/240p_test_suiteLinearity test is extra useful.
Recreating the suite for the NES would be a good simple project to gain familiarity with the NES PPU.
mikejmoffitt wrote:
aspectyl wrote:
http://junkerhq.net/xrgb/index.php/240p_test_suite
Recreating the suite for the NES would be a good simple project to gain familiarity with the NES PPU.
As a start, I've redrawn most of the test screens for the NES, in case anyone else wants to pick up this project.
Update: With the other big project off my back, I can devote time to this. I'm just waiting for a moderator to approve my introduction post on shmups.system11.org first.