I've been playing around a bit with chroma artifact colors on the NES, and it seems that for games targeting US NTSC consoles they could be useful for creating colorful backgrounds (the techniques create a diagonal stripe pattern which would probably be distracting if it appeared on moving objects, but wouldn't be so much of an issue with static backgrounds). One problem I can't see any nice way to resolve, though, is how to determine the NTSC color phase other than by asking the user to indicate whether a test pattern appears correctly.
Based on the general description of the NTSC "drop dot" behavior, I'd been hoping that it would drop a dot or not based on color phase, so that if the sequence with rendering disabled is labeled A->B B->C C->A, the sequence with rendering enabled would be either A->B B->A C->B or A->B B->A C->A (either dropping a dot except on A frames, or only on B frames, either of which would settle into an ABAB sequence). Unfortunately, the system seems to have an even/odd frame counter which is runs separate from the chroma phase and rendering enable/disable control. Finding the phase of that counter would fall in the realm of irksome but doable, and would reduce the number of states the code would need to deal with from six down to three, but it would be nicer to fully automate the phase determination.
I don't think there's any documented way for the CPU to observe chroma phase, but I don't think all aspects of the chip are fully documented. Has anyone studied the chip layout enough to know whether there is any feedback path from the chroma phase to anything the CPU could observe?
An "if nothing else is workable" automated solution might be to have a gizmo plug into the expansion board, generates a logic level if the instantaneous video output voltage is above a certain threshold, and feeds that to one of the digital inputs of the APU. This gizmo could also forward cartridge audio without requiring the resistor mod. A game could then show a test pattern which will show black in one part of the screen and non-black in two others, based upon color phase, and then either auto-select the proper color phase or ask the user to indicate which part of the screen is black. Most customers would probably rather use the manual selection than have to plug in an expansion gizmo, but if a cart included audio circuitry, requiring a gizmo to get both sound and color-phase detection might not be too bad.
Are the expansion-port gizmo and manual user input the only ways to detect chroma phase, or might there be some other way in which chroma phase would affect something the CPU could detect and act upon?
Attached is a demo (CNROM; bank table at PRG ROM offset 7FE0) which doesn't work quite the same with MESEN's NTSC filters as on my vintage NES, but illustrates chroma artifacting either way. It shows three groups of four rows of boxes showing 64 "artifact colors"; all three groups show the same colors, but arranged differently. Push down to play "color phase roulette". About half the time one will get a flickery mess, and the other half one will get one of three color phases. From the Nintendo's point of view, everything on the screen uses black, lavender, yellowish-orange, and greenish-aqua, so all of the colors shown on the screen could be placed anywhere without being limited to metatile or even tile boundaries. Using attributes would make it possible to select among multiple sets of 64 colors, so I think this technique could have a lot of potential if properly exploited. Requiring the user to select a color phase first seems awkward, though.
Based on the general description of the NTSC "drop dot" behavior, I'd been hoping that it would drop a dot or not based on color phase, so that if the sequence with rendering disabled is labeled A->B B->C C->A, the sequence with rendering enabled would be either A->B B->A C->B or A->B B->A C->A (either dropping a dot except on A frames, or only on B frames, either of which would settle into an ABAB sequence). Unfortunately, the system seems to have an even/odd frame counter which is runs separate from the chroma phase and rendering enable/disable control. Finding the phase of that counter would fall in the realm of irksome but doable, and would reduce the number of states the code would need to deal with from six down to three, but it would be nicer to fully automate the phase determination.
I don't think there's any documented way for the CPU to observe chroma phase, but I don't think all aspects of the chip are fully documented. Has anyone studied the chip layout enough to know whether there is any feedback path from the chroma phase to anything the CPU could observe?
An "if nothing else is workable" automated solution might be to have a gizmo plug into the expansion board, generates a logic level if the instantaneous video output voltage is above a certain threshold, and feeds that to one of the digital inputs of the APU. This gizmo could also forward cartridge audio without requiring the resistor mod. A game could then show a test pattern which will show black in one part of the screen and non-black in two others, based upon color phase, and then either auto-select the proper color phase or ask the user to indicate which part of the screen is black. Most customers would probably rather use the manual selection than have to plug in an expansion gizmo, but if a cart included audio circuitry, requiring a gizmo to get both sound and color-phase detection might not be too bad.
Are the expansion-port gizmo and manual user input the only ways to detect chroma phase, or might there be some other way in which chroma phase would affect something the CPU could detect and act upon?
Attached is a demo (CNROM; bank table at PRG ROM offset 7FE0) which doesn't work quite the same with MESEN's NTSC filters as on my vintage NES, but illustrates chroma artifacting either way. It shows three groups of four rows of boxes showing 64 "artifact colors"; all three groups show the same colors, but arranged differently. Push down to play "color phase roulette". About half the time one will get a flickery mess, and the other half one will get one of three color phases. From the Nintendo's point of view, everything on the screen uses black, lavender, yellowish-orange, and greenish-aqua, so all of the colors shown on the screen could be placed anywhere without being limited to metatile or even tile boundaries. Using attributes would make it possible to select among multiple sets of 64 colors, so I think this technique could have a lot of potential if properly exploited. Requiring the user to select a color phase first seems awkward, though.