Manual lag test: Result screen background is black even if last press is Marvelous (0.09 regression; reported by Quietust)

Stopwatch: Blue in clock face is darker to improve visibility on black-and-white TVs (requested by retrorgb)

Stopwatch: Draws frame number with sprites to remain visible through composite out of Hi-Def NES (requested by retrorgb)

Stopwatch: Up to show scanline ruler (requested by retrorgb)

Grid: Fixed reversal of red and white colors

Help: Doesn't draw page numbers for 1-page help documents

I think these Hi-Def NES-related new features are the last features I can add without either adding trampolines or expanding the Jeopardy!-donor build to 128K. It was so tight that I had to reword a few other help pages for conciseness.

Wow, that's awesome! That should do the trick, as all we'd need is the frames - Seconds would be nice too, but that's still enough to use the Hi-Def NES as a true lag tester for flat-screen TV's!! Thanks so much for adding this! I'll bring it up on the podcast and add a page on my site that describes exactly what people would need to do!

Author:

mikejmoffitt [ Wed Jul 27, 2016 1:13 pm ]

Post subject:

Re: 240p test suite

retrorgb wrote:

Wow, that's awesome! That should do the trick, as all we'd need is the frames - Seconds would be nice too, but that's still enough to use the Hi-Def NES as a true lag tester for flat-screen TV's!! Thanks so much for adding this! I'll bring it up on the podcast and add a page on my site that describes exactly what people would need to do!

This is actually a really great feature-add. There aren't a lot of devices available to test a 1080p TV against a 480i CRT, both running at native resolution in the best-possible circumstances.

It can conversely act as (additional) tangible proof that the Hi-Def NES doesn't introduce more than a few lines of latency.

Author:

rainwarrior [ Wed Jul 27, 2016 3:21 pm ]

Post subject:

Re: 240p test suite

Suggestions for the lag test, pardon me if they're a repeat, I didn't reread the whole thread to check:

The lag test discards all early presses. This biases the results toward lag by half the imprecision of the human user. The lag itself should be consistent, but human precision varies from tester to tester (and condition of the tester). Since you don't know in advance how precise the user is, the amount of bias is unknown, and can't be properly corrected for. I think early results should be included to balance out this bias.

I also think displaying an indication of how "good" your timing was improperly biases the results. No matter the lag, the user can always anticipate to reach approximately "marvelous" timing, and labelling it this way gives them incentive to try to do this. It's no longer a measure of the hardware lag, but of their ability to anticipate, unless they can mentally ignore this measure of success being presented to them. The documentation mentions "if you are skilled at rhythm games"-- rhythm game skill means exactly that you can learn to anticipate and hide lag, which is the opposite of what this test should measure!

Ideally the user should be blind to their results as their coming in. I would just display "X results received" as it counts up to 10, and if you're rejecting "bad" results, bad should just be sufficiently away from the target (e.g. +/-20 frames away), not the early results.

Additionally, audio lag and picture lag should be measured separately. The user should only be using the audio cue, or only the visual cue; using them both at once is a problem if they're not the same. Thankfully there is the option to turn the audio off, and you can close your eyes to do an audio-only test, but it would seem to be more appropriate to have 3 options: picture only (to test), audio only (to test), picture+audio (to watch, same goal as "audo synch test").

The "flash" visual cue is a good cue for picture lag and should happen whether or not audio is on. Why is it disabled when you disable audio? (This is very strange to me.) Randomness on the other hand is not applicable to an audio-only test (again would reduce it to a test of the human, not a test of the lag); it should just be trying to match a steady beat. Randomness is good with the visual test though.

Suggestion for sound test:

Periodic noise (and regular noise for comparison), since some revisions of the Famicom are missing it.

Suggestions for documentation:

START seems to pause a test and enter its documentation, but it also enters a test and exits its documentation. I found this a little confusing because I didn't know what START's function was, and repeated presses end up doing a different thing each time (it enters a test, but can't exit it, but it enters documentation and exits it). Not really an issue once you're oriented, but maybe it would be more intuitive if START from the menu to you directly to the documentation (and exiting returned to either the menu or the test, depending on where it was launched from)?

Author:

tepples [ Wed Jul 27, 2016 5:26 pm ]

Post subject:

Re: 240p test suite

Trampoline get.

Quote:

The documentation mentions "if you are skilled at rhythm games"

The original (source code) also mentions "rhythm". Perhaps I misinterpreted something.

Quote:

START seems to pause a test and enter its documentation, but it also enters a test and exits its documentation.

It's at least consistent with Kirby's Adventure, which uses Start to enter or exit documentation.

I've tried to make the behavior reflect that of the versions of the suite for other consoles, particularly the version for Super NES because that's the other console that I leave hooked up. Toward that end, is it OK to pass your feedback on to the development topic for other versions? And if so, would linking or quoting be better?

Author:

rainwarrior [ Wed Jul 27, 2016 7:07 pm ]

Post subject:

Re: 240p test suite

I'm not familiar with other versions of the test, but I don't mind if you want to link to or quote my suggestions.

Author:

tepples [ Thu Aug 04, 2016 3:53 pm ]

Post subject:

Re: 240p test suite

I passed on your suggestions, and Artemio replied. I've implemented two (noise in sound test and fix inconsistent Start behavior). The manual lag test changes will wait for what Artemio ends up deciding to do.

This is largely a behind-the-scenes reorganization of how graphics data is loaded, though it includes some requested changes.

Is there any way to make $0D in PLUGE / etc. an option, so that these tests aren't useless on a TV that loses picture due to it? (Though, the pattern used does not seem to negatively affect any device I have available to test, so this is only a speculative question for me.)

Author:

tepples [ Mon Aug 29, 2016 9:00 am ]

Post subject:

Re: 240p test suite

Solid color screen uses $0D only if you move to black and press A. IRE uses $0D only if you move to the very bottom of the range. PLUGE uses $0D, and the entire point of PLUGE (Wikipedia) is to show a strip of "super-black" in contrast with a gray ramp. The approximation of SMPTE EG 1-1990 also includes a mini-PLUGE at bottom right. I guess I could mention the possibility to lose sync on some TVs in the help page, so long as the user knows to press Start to see it.

And while I'm at it, I might as well incorporate the NTSC chroma-to-luma crosstalk test from tvpassfail (with the red/green/blue diagonal stripes).

Author:

tepples [ Wed Dec 28, 2016 10:26 am ]

Post subject:

Re: 240p test suite

I have a hypothesis about 240p to 480p line doublers: It might be possible to use a 480p CRT if the scanline darkening is set high enough and the doubler has no more than a line or two of lag. So to encourage testing this hypothesis, I plan to add the 1-gun test screen from Zap Ruder into the version of the test that I've been invited to submit to the compo.

Author:

tepples [ Fri Dec 30, 2016 10:35 pm ]

Post subject:

Re: 240p test suite

Sorry for the triple post. This will probably be the last update I release this year, as I've been busy watching Windows tech support scam baiting videos.

I tested this on my Twin Fami, and a couple obvious problems are apparent:Did you know that all models of the Famicom pass the microphone input, amplified, through the TV speaker/ audio output? So, merely bringing the Fami close to a CRT TV / speaker set causes immediate squealing due to mic overload & feedback. I tried it on an LCD TV, and there is a bit of delay & echo, but the feedback is here as well.

The feedback is far louder than the Fami's PSG output, and the mic detection circuit in the Fami hardware is a little deaf, so there's no way to test the Fami audio-> mic with such feedback ruining everything. Users will have to open up their Famis to solve this, so I don't think this is a very useful test.

Author:

tepples [ Sun Jan 01, 2017 10:05 am ]

Post subject:

Re: 240p test suite

But as you mentioned earlier, a Titler was more sensitive than a Twin in a different test. I guess we need someone with a red and white Famicom to test this.

And perhaps the kind of person who would install an RGB or HDMI output mod is also the kind of person who would bridge a resistor.

As for feedback, I'll need to ask users to turn down the mic's volume just below where feedback starts to happen. That's also why I added a few frames' delay between pressing A and the tone: to distinguish feedback from a valid result.

Author:

ccovell [ Sun Jan 01, 2017 4:53 pm ]

Post subject:

Re: 240p test suite

tepples wrote:

As for feedback, I'll need to ask users to turn down the mic's volume just below where feedback starts to happen.

You've got a catch-22 here. Lowering the slider on the P2 controller decreases the input to the mic, ie: its sensitivity overall. It will never detect a PSG sound when its own amplified feedback is louder at any combination of volume & slider. I think so, anyway. Perhaps someone with a regular red & white Famicom can verify this.

Author:

zzo38 [ Sun Jan 01, 2017 4:59 pm ]

Post subject:

Re: 240p test suite

ccovell wrote:

tepples wrote:

As for feedback, I'll need to ask users to turn down the mic's volume just below where feedback starts to happen.

You've got a catch-22 here. Lowering the slider on the P2 controller decreases the input to the mic, ie: its sensitivity overall. It will never detect a PSG sound when its own amplified feedback is louder at any combination of volume & slider. I think so, anyway. Perhaps someone with a regular red & white Famicom can verify this.

I can see it from the schematic. As far as I know there is no mapper with the function to mute the audio; I have suggested such a thing before (and you said apparently is not so useful, but now we can see that actually it is useful) and if it existed then that would help if it also has expansion audio. Of course such thing would require such a cartridge to be built in order to test it, but that will be possible.