nesdev.com

I just tried it on my NESRGB-modded Famicom and it didn't seem to work - No audio played on the TV, no matter what I did. Maybe I'm just making a stupid mistake? Load the audio test and press A, right?

Does it say "noise"? If so, the microphone bit is getting triggered before the tone begins. Does it still say "noise" when you turn the mic volume all the way down? I'll need to add a real time display to troubleshoot this. If it instead says "no signal", does the other sound test make noise?

It says "noise" regardless of the mic position, including if I start with the mic all the way down.

Is the mic continuously triggered if you open player 2 in my controller test?

Yes, "mic" stays red no matter what. Does that mean my controller is bad?

Also...cool controller test program!

That or the mic circuit in your Famicom is bad. It might cause problems in other games using the mic, such as the FDS version of Zelda where the player is supposed to blow Pols Voice away. If you want to troubleshoot it, feel free to open a new topic.


UPDATE: I had krom in #nesdev test an interim build with a couple changes, such as less frequent polling (155 CPU cycles per sample instead of 11), and it still had the problem of not being loud enough to trigger without going straight to feedback. I'll just remove this test from the next version and wait until I get a Famicom of my own to try other things like $4011 manipulation.

With that said, is there any other output testing functionality I could put in 0.15?

Test suggestion:

It would be useful to be able to identify skipped frames (thinking about this recent thread).

In some of my work, the test I've used for this is to display a row of numbers, each number appearing for exactly one frame as we cycle through them. (All numbers have to be in a different visual position.)

Actually, after looking at the stopwatch test, that seems to be almost this, but I find it a lot less effective to try and read it because the numbers are always displayed, and the contrast between red and blue is not nearly as strong as if it would be if the numbers were appearing only on their frame. (Black would be better than that blue, and that dark blue is better than the red for contrast against white.) The little dots in the centre are only on for one frame, but they're small and red and in a circle instead of a row.

Additionally, a longer period than 10 may help; I've usually found 16 to be effective, in a row or a grid. 64 is probably too many, but 10 looks like too few to me, but I'm just "eyeballing" this, YMMV. A configurable period might be even better as it could help diagnose particular framerate mismatch problems too (e.g. 60 vs 50 fps).


Other versions of the 240p suite seem to have a "lag test" that is like your stopwatch but with bigger numbers arranged in a 4x2 grid; it seems that older versions had on/off numbers instead of red/blue, which I think was better, but given that the intent of that test was to be used with a camera, I don't think it made a difference for that purpose. My suggestion is for something that you should be able to see easily with the human eye, which wasn't really the original intent I think. A human test should try to emphasize and take advantage of persistence of vision (via greater contrast, or larger numbers, or only showing one at a time, etc.).

You make a good point about the contrast. I've passed your feedback upstream and changed my version to use a blue ($01) active circle and pink ($26) inactive circles. This should improve visual contrast.

Honestly, I think the most critical thing here is that inactive ones should be invisible (i.e. the background colour). Simply changing the colour is not very effective for persistence of vision.

When I was talking about contrast I just meant that dark blue against the white background was a better contrast than red against white, but black against white would be best, and the inactive numbers should be invisible.

If all goes well, here's the version I'll submit to the compo.

0.15 (2017-01-23)

• Removed Famicom audio lag test after negative results by ccovell and krom
• Stopwatch: Clock face uses a blue active circle and pink inactive circles for contrast (requested by rainwarrior)
• Stopwatch: Down to show or hide inactive circles (requested by rainwarrior)

And the blurb:

I have received a private message asking for a port of 240p Test Suite to Famicom Disk System. I had to reply that I lack a Famicom, RAM adapter, and FDSStick with which to test it. Is there demand for an FDS port among anyone else?

Do you really need those three things? Emulator / PowerPak / Everdrive should be good enough to get it together, and if you need verification testing I'm sure there's many who could oblige (myself included).

The main caveat with PowerPak or Everdrive is that they swap sides automatically, and also the PowerPak FDS seems to have an accelerated load timing, but that only matters if you're doing something that requires loading to be specifically slower. (You can still make the license skip work on it without this.) Actually a test that can tell you the disk bandwidth might be interesting, though I'm not sure how you'd time it, since you'd want to go through the BIOS for compatibility.

This is not a request for a 240p port, though. I'm just suggesting that your lacking hardware isn't really a big problem. A good emulator with the original BIOS does a pretty good job of replicating it.

What Rainwarrior said re: emulators, but if you really need, I can provide testing or lend hardware.

The port would be neat, but I don't know that it's so important. Unlike a Sega CD port, it doesn't really make it a lot easier for others to use it by offering it on this disc based platform.

I was wondering if anyone tried the 0D color address? It's supposed to be blacker than black. For the pulge bars in the SMTPE pattern this would be extremely helpful. As long as the NES's other blacks other are outputting a 7.5 NTSC in middle bar, left bar is 0 or blacker; that's about all you need for 7.5 NTSC brightness calibration. (Sounds likely 0D is a 0 level NTSC instead of 7.5 like used in actual pluge bars which would be even better)

Further, I think it would be better if the lightest of the 3 bars on the right was one of the light greys, 10 or 3d (how are they different?) While it might technically be further from a pulge lightest grey (15?) than black, that's not really point of the test pattern; functionally, anything but black there would be better. Then if the 0D, blacker black, actually works out, you'd have functioning, maybe fully functioning, pluge bars!

BTW I've used this rom extensively for nearly all my CRT testing and calibration (which I do A LOT of), does everything great besides pluge, and of course chroma/phase calibration, but the later is a given with 55 colors; I have to use a TSG for both.

reference:
http://wiki.nesdev.com/w/index.php/File ... atches.png
https://upload.wikimedia.org/wikipedia/ ... rs.svg.png