It is currently Tue Jul 23, 2019 1:54 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Sun May 19, 2019 9:04 am 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 151
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.


Attachments:
File comment: Demo of artifacting. CNROM, with bank table at ROM offset 7FE0.
colorArtifact1.nes [64.02 KiB]
Downloaded 188 times
Top
 Profile  
 
PostPosted: Sun May 19, 2019 11:39 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8488
Location: Seattle
supercat wrote:
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?
No, there's nothing like that. The color phase is determined a free-running 6-bit twisted-ring counter – Visual2C02 nodes 193, 226, 194, 224, 195, 227 – with an extra 6 bit tail instead of generating inverted copies of the first six. Three of those signals are relayed to the color emphasis; otherwise the bottom 4 bits of the color index, a blanking signal, and all 12 signals from the twisted-ring counter go into a 13-way multiplexer (outputting on node 381). Finally, the upper two bits of the color number and node 381 select one of 11 analog multiplexers for the output stage. But there's no place where any of these signals go anywhere near the PPU's internal data bus.


Top
 Profile  
 
PostPosted: Sun May 19, 2019 5:02 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 151
lidnariq wrote:
supercat wrote:
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?
No, there's nothing like that. The color phase is determined a free-running 6-bit twisted-ring counter – Visual2C02 nodes 193, 226, 194, 224, 195, 227 – with an extra 6 bit tail instead of generating inverted copies of the first six. Three of those signals are relayed to the color emphasis; otherwise the bottom 4 bits of the color index, a blanking signal, and all 12 signals from the twisted-ring counter go into a 13-way multiplexer (outputting on node 381). Finally, the upper two bits of the color number and node 381 select one of 11 analog multiplexers for the output stage. But there's no place where any of these signals go anywhere near the PPU's internal data bus.


So the the three phase signals 193, 195, and 197 when go down the left side of the chip, that's just for color emphasis? Bummer. Is node 170 used to reset that? What else gets reset the same way?


Top
 Profile  
 
PostPosted: Sun May 19, 2019 5:30 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8488
Location: Seattle
Node 170, "_res" (and node 128, "_res2"), clears everything. Pixel counters, even/odd phase, chroma phase, &c. I'm not clear how the variable CPU-PPU subpixel phase happens, but once /RESET releases, the CPU-vs-chroma phase should be fixed forever after...

There are a few tests that can determine pixel-level (e.g. Micro Machines inspecting $2004 during rendering) and sub-pixel level phase (polling $2002 vs NMI cancellation), but I don't know if that's enough information to piece out the chroma phase.


Top
 Profile  
 
PostPosted: Sun May 19, 2019 7:26 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 151
lidnariq wrote:
Node 170, "_res" (and node 128, "_res2"), clears everything. Pixel counters, even/odd phase, chroma phase, &c. I'm not clear how the variable CPU-PPU subpixel phase happens, but once /RESET releases, the CPU-vs-chroma phase should be fixed forever after...

There are a few tests that can determine pixel-level (e.g. Micro Machines inspecting $2004 during rendering) and sub-pixel level phase (polling $2002 vs NMI cancellation), but I don't know if that's enough information to piece out the chroma phase.


When rendering is disabled, chroma and the even-odd frame counter will cycle through six states. Perhaps if I change the starting phase in my test it would land on the right phase every time, but I'm not sure if that would be reliable on all consoles. Do the processor and PPU come out of reset within a few milliseconds of each other, or are there macroscopic unpredictable delays?


Top
 Profile  
 
PostPosted: Sun May 19, 2019 7:58 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8488
Location: Seattle
supercat wrote:
Do the processor and PPU come out of reset within a few milliseconds of each other,
On the NES-001, yes; both the CPU and PPU /RESET inputs are driven by the CIC, and they should be both count as "released" within a couple microseconds of each other. Possibly better, I don't know.

On all the other licensed consoles (certainly HVC-001, HVC-101, & NES-101; probably also Twin Famicom, Famicom Titler) PPU /RESET is not the same as CPU /RESET; the external RESET button only resets the CPU, not the PPU.


Top
 Profile  
 
PostPosted: Sun May 19, 2019 10:06 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 151
lidnariq wrote:
supercat wrote:
Do the processor and PPU come out of reset within a few milliseconds of each other,
On the NES-001, yes; both the CPU and PPU /RESET inputs are driven by the CIC, and they should be both count as "released" within a couple microseconds of each other. Possibly better, I don't know.

On all the other licensed consoles (certainly HVC-001, HVC-101, & NES-101; probably also Twin Famicom, Famicom Titler) PPU /RESET is not the same as CPU /RESET; the external RESET button only resets the CPU, not the PPU.


Hmm... sounds like an NES-001 might be able to power up in the correct color phase fairly reliably then (my test cart would consistently fire up in the wrong color phase, but I'd been loath to attribute any apparent consistency to anything but happenstance). Other NTSC consoles would start the CPU in unknowable phase chosen from six, and the issue would be moot on PAL consoles. Color artifacting would seem like it could facilitate some nice effects which could be relatively harmless if they don't work (e.g. one could make text fade in and out more smoothly if one knew what pattern of colors would appear closest to black on any given frame). A light gun game could auto-set the color if the player started by shooting the screen, but don't have any ideas for light gun games where I'd want to exploit chroma artifacts. [I do have a rough prototype of a dual-Zapper mini-game where the light guns control the vertical positions of electronic table tennis paddles which actually seems like it could work well, though at the moment I only have one Zapper, but I'm not terribly interested in pursuing that beyond a cute little minigame]. Still, the idea of shooting the screen to auto-calibrate does seem sorta interesting.


Top
 Profile  
 
PostPosted: Sun May 19, 2019 10:16 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8488
Location: Seattle
supercat wrote:
I do have a rough prototype of a dual-Zapper mini-game where the light guns control the vertical positions of electronic table tennis paddles which actually seems like it could work well
Tepples has, in fact, already written this! (source on github) (precompiled binary with source)


Top
 Profile  
 
PostPosted: Sun May 19, 2019 10:34 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 151
lidnariq wrote:
supercat wrote:
I do have a rough prototype of a dual-Zapper mini-game where the light guns control the vertical positions of electronic table tennis paddles which actually seems like it could work well
Tepples has, in fact, already written this! (source on github) (precompiled binary with source)


Cool. Saves me the trouble of having to do it myself. I hauled out my old CRT so I could test chroma effects on it, and started playing with the Zapper a bit, but my real interest is getting everything in place to implement Ruby Runner. If nobody's really explored chroma on the NES, I think there's some untapped potential which could be harnessed in games that can easily switch CHROM banks. Triple up on tile sets, and switch tile sets based on the combination of color phase along with X and Y scrolling offsets. A bit of a nuisance, but it would allow games to have much more colorful backgrounds. I'm not enough of an artist to really explore that, but someone who is might really be able to do some cool new stuff.


Top
 Profile  
 
PostPosted: Tue May 21, 2019 8:34 am 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 151
lidnariq wrote:
supercat wrote:
Do the processor and PPU come out of reset within a few milliseconds of each other,
On the NES-001, yes; both the CPU and PPU /RESET inputs are driven by the CIC, and they should be both count as "released" within a couple microseconds of each other. Possibly better, I don't know.

On all the other licensed consoles (certainly HVC-001, HVC-101, & NES-101; probably also Twin Famicom, Famicom Titler) PPU /RESET is not the same as CPU /RESET; the external RESET button only resets the CPU, not the PPU.


Experimentation shows that the color phase isn't consistent, but pushing reset repeatedly in short succession usually gives the same phase. Do the color-generation counter and pixel-generation counter run on the same or opposite phase of the master clock? Perhaps if the CIC reset is released when master clock is high, the color counter runs first, and if it's released when the master clock is low the pixel counter runs first?


Top
 Profile  
 
PostPosted: Tue May 21, 2019 9:55 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8488
Location: Seattle
supercat wrote:
Do the color-generation counter and pixel-generation counter run on the same or opposite phase of the master clock?
The same. The color generation counters are clocked on both rising and falling edges, but the first node in the loop - node 193 - is always clocked on a rising edge of the master clock. So is "pclk0", the "left half pixel" synchronization signal.

I don't know what column of colors corresponds to node 193.


Top
 Profile  
 
PostPosted: Tue May 21, 2019 1:14 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
With this test, which would give 6 easily discernable colours after reset, I could reach all 6 from reset from either my front loader NES, or top loading Famicom.
(1 of the 6 phases seemed to come up less often on my NES, but that might have just been a random accident from not enough data collected.)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group