nesdev.com

I barely made it fit.

0.12 (2016-07-26)

• 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.

_________________
Pin Eight | Twitter | GitHub | Patreon

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.

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)?

Trampoline get.


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


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?

_________________
Pin Eight | Twitter | GitHub | Patreon

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.

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.

0.13 (2016-08-04)

• Reorganized most compressed graphics into "files"
• Moved compressed graphics files into banks 0 and 1
• Made separate BNROM build, with graphics decompression code behind interbank call gates
• Expanded usable portion of ROM from 48K to 64K
• make clean is more thorough
• Sound test includes noise channel in hiss and buzz mode (requested by rainwarrior)
• Start on main menu always opens About (SNES parity; reported by Artemio)

_________________
Pin Eight | Twitter | GitHub | Patreon

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.)

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).

_________________
Pin Eight | Twitter | GitHub | Patreon

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.

_________________
Pin Eight | Twitter | GitHub | Patreon

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.

0.14 (2016-12-31)

• Added chroma crosstalk test for NTSC
• Added basic Zapper test based on Zap Ruder
• Added audio lag test using Famicom microphone (caution: untested on hardware)
• PLUGE, SMPTE, Solid color screen, IRE: Help page warns about super-black signal causing distortion (requested by rainwarrior)
• Some help copyedits
• Documented interbank call gate mechanism

Once this version gets tested, the next thing I plan on is refactoring display of 2- and 3-digit decimal numbers throughout the program.

_________________
Pin Eight | Twitter | GitHub | Patreon

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.

_________________
http://www.chrismcovell.com

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.

_________________
Pin Eight | Twitter | GitHub | Patreon

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.

_________________
http://www.chrismcovell.com

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.

_________________
.