There is a
guy over at Famicom World with an AV-modded Famicom that experiences glitches on his TV when certain colours appears at the screen.
When testing the colours, it turns out the forbidden $0D glitches but only in conjunction with emphasis bits (more info in the linked thread).
I can only vaguely guess what the problem is. Does SMB3 or Gimmick really use colour $0D or emphasis bits?
I don't believe that either of those two games uses $0D or emphasis.
I've seen modern TVs do various stupid things because of their post processing, motion interpolation, etc. Maybe just try switching your TV to "game mode" if it has one? Usually that disables a lot of extra operations in the display chain that can mess things up.
Version 0.03 of
my NES port of the 240p test suite will have a screen that shows emphasized $0D. If your TV has a problem with sync at that signal level, that'll be one quick way to diagnose it.
So, when certain colors are on the screen, the TV loses sync. When you test each color one at a time, it only happens with $0D even though in games you mostly see it on screens with bright colors.
Perhaps some sort of automatic gain control or DC offset correction (or lack thereof?) is causing black to be misinterpreted as sync whenever there's a lot of light colors on the screen.
Maybe it's time to reignite my idea of abusing $0D mid-screen to try to implement a crude 480p mode on displays which see $0D as a sync pulse.
In the times I've seen it happen, $0D has interfered with horizontal blanking rather than vertical. I've seen a bunch of different effects though, it probably could affect vertical in some cases.
rainwarrior wrote:
In the times I've seen it happen, $0D has interfered with horizontal blanking rather than vertical. I've seen a bunch of different effects though, it probably could affect vertical in some cases.
Exactly. A 480p signal at
n FPS shares the same Vertical Sync signal with a 480i/240p signal at
n FPS, but the horizontal refresh rate is doubled. By interfering with the horizontal sync signal mid-screen, we can inject a second Hsync signal to bring the 15KHz signal to 30KHz.
Thank's everyone. So it's probably the plasma TV doing something weird after all, and no problem with the AV-mod.
Pokun wrote:
So it's probably the plasma TV doing something weird after all, and no problem with the AV-mod.
It's normal to have issues with color $0D. Issues elsewhere, like in SMB3, sound like a bad AV mod.
Sure the $0D glitching might very well be unrelated to the problem, but since everything worked fine on the CRT TV I thought it might be the TV that's misbehaving.
The TV worked with the PAL NES, and as far as I know the PAL NES uses the same signal levels as NTSC, so it sounds to me like it's the AV mod.
A NTSC system would make a better comparison, since there is a small possibility the TV just doesn't handle NTSC correctly.
NTSC, but not PAL, has something called
setup. This is a difference between the blanking level (not the sync level) and the black level. Sync is -40 IRE, blanking is 0 IRE, and black is 7.5 IRE.
Someone should convert the voltage levels on
NTSC video to IRE units so that analog video geeks can make better sense of it.
tepples wrote:
Someone should convert the voltage levels on
NTSC video to IRE units so that analog video geeks can make better sense of it.
Depends on whether anything's doing any normalization, as well as what exactly the output looks like into a 75Ω and/or infinite load.
Fortunately, for receiving over RF (which should be normalized), we can derive it from the existing data.
So there's at least 3 different values we'll need to calculate.
Joe wrote:
Perhaps some sort of automatic gain control or DC offset correction (or lack thereof?) is causing black to be misinterpreted as sync whenever there's a lot of light colors on the screen.
It's a problem with the analog encoding in the first place. Sync is encoded as luminance being "beyond black". The color $0D happens to run way too close into this range so some TVs believe its pixels are a sync signal. (the PPU is not respecting the tolerance, basically)
At least this is my understanding of the issue.
Sik wrote:
It's a problem with the analog encoding in the first place. Sync is encoded as luminance being "beyond black". The color $0D happens to run way too close into this range so some TVs believe its pixels are a sync signal. (the PPU is not respecting the tolerance, basically)
...Except, the games where this issue appears are not using $0D at all. Something is causing the black level to far low enough that the TV begins interpreting black as sync.
...And $0D only glitches when two or three emphasis bits are set, according to himself.
Emphasis bits lower the signal level, so it's not surprising that those combined with color $0D is enough to confuse one TV when color $0D by itself confuses some TVs.
Update:
240p test suite 0.03 is out. Its PLUGE screen can be set to include emphasized $0D now.