Nestopia emulator enhancer mac code#
Nestopia emulator enhancer mac Pc#
Nestopia emulator enhancer mac tv#

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.

Nestopia emulator enhancer mac tv#

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). 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. This gives a NES pixel size of 1.1429x0.9375 mm, with an width/height ratio of 1.2191, or about 11/9. The NTSC box was 70x80 NES pixels, and measured 80x75 mm on screen. For the TV I posted the images of, we can calculate the size of a pixel using this definition. If one must define a pixel, it'd make most sense to base its width on a single color carrier cycle.

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. 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). The width, on the other hand, depends on the video chip that's generating the image. Anything on screen is a multiple of a scanline height. The only discrete aspect of an NTSC/PAL image is scanlines. (the TV is less warped in the right shot because I moved farther away and zoomed in, exactly for this purpose)

Nestopia emulator enhancer mac code#

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). I also did a test shot of a square object (not shown) to verify that my digital camera's pixels are square. For the aspect ratio test, the boxes were 75 mm high, and 80 mm, 61mm, and 85 mm wide from left to right. Tepples: Below are some camera shots of a TV connected to an NTSC NES running your latest test. 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. 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. 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. There are plenty more tests like this that could be written. 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. Interestingly, most aspects of the PPU can be verified by using sprite #0 hit. You can probably think of many: proper frequency of waveforms, DAC volume levels, DMC sample playing. Several aspects of the APU, like the triangle's length counter, aren't reflected in the status register. 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? An example exists at the bottom of this page:Īnyway, that would get my vote for most creative test ROM for the NES 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. 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.Ī similar thing has been done before. 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.

Then you wouldn't be able to claim you pass all my tests unless you do NTSC too. It'd display images that you couldn't make out unless you have proper NTSC emulation. 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.