A few months back, I talked about h-blur technique. This involves shifting every other scanline over 1 pixel, then revert back and by to the interleaved set of scanlines. Rinse/repeat. But during some tests, I found some strange artifacts with PCE’s mid res mode.
I was looking over some CoCo 3 stuff the other week (from some light web surfing). Came across this article/post by Potatohead (you might know him from the Atari 8bit scene). Long story short, he created a 256 color mode for the CoCo 3. It only works on NTSC video (composite or RF). But the idea behind it was pretty interesting. When you have exact multiples of the color sub carrier frequencies, you get specific bleed over into the chroma field. When it’s not an exact multiple, you get rainbow artifacts instead (see Genesis, NES, etc). It works because the pixels are higher resolution than what the frequency can sustain. When the frequency of Y is not an exact multiple of C, then you can use filters to comb through and get back some of the resolution of Y. But this isn’t the case when you have exact multiples of C.
Coco 3 has a 4x multiple mode of C. Potatohead uses 4 shades of grey at a 14.318mhz dot clock. The patterns accumulator and bleed over into the Chroma channel. By using shades other than grey, you can ‘tint’ those 256 colors. Other systems has used this artifact as well, CGA/Apple/CoCo1&2. Pretty cool. But how does this apply to the PCE? Easy. The PCE has a resolution that’s an exact multiple of C as well. The mid resolution (dot clock 7.159mhz). If you turn off h-filter bit in the VCE, and use two pixel groups – you get near-perfect solid colors of those two pixels. Matter of fact, on my NTSC set (a new one at that) it IS perfect. Same on my HD set. And same on my NTSC capture card.
Now, what might come to mind.. is the Genesis. It’s known for it’s crappy video output (at least for NTSC). But the Genesis isn’t an exact multiple of Chroma frequency. It’s something like 1.87x the frequency. So you see a rainbow effect because it’s out of phase. The PCE mid res mode pretty much has the Genesis high res mode beat – hahaha. Of course, you need to have the h-filter turned off.
The other thing that I noticed, is that the phase of the accumulation is not the same every time. Just like the coco 1/2, where you had to reset the system until you saw the correct red/blue pattern – to continue along playing the game. The PCE phase offset is also random. But you can control it. By turning the h-filter on, and then off, you can have the user/person cycle through until they see the correct pattern. There might be an even better why to automate this, but only if you can force it to a specific phase first (reset it).
Ok, so what are the benefits? A larger master palette for one (4096 colors if my math is right). No flicker at all (this isn’t a color cycle thing). You aren’t restricted to only using pairs of colors. If you were, you’d be limited to a 172×224 resolution. You can restrict dither in areas of an image where you need color over resolution, horizontally.
10.74mhz and 5.37mhz dot clock will *not* have this property that the 7.159mhz dot clock has. You’d figure 10.74mhz could be similar, since the resolution is so high, but it’s not. And with really good filters, you can pull the higher resolution in Y back out of the signal. My capture card does an amazing job of this.
The down side? It won’t work in RGB. It also has no effect on PAL systems. But lets be frank, RF and composite are the only official outputs supported by the systems. Yes, RGB was technically available on the back plane of the original core systems – but it need amps and was never officially made available. Not to mention how are you doing to tap RGB when you have a CD addon? Not without opening up the system. The later systems, the Duo units, which are more or less considered the main systems (replacing the core systems) and probably selling more units, completely lack the external means the tap the RGB lines. It requires opening up the system. PAL systems were only realized as an experimental test market, and not PAL soft was ever officially made (the finland demo group that did the NES images ran on PAL modified PCEs). Therefore, I think it’s safe to assume this isn’t a ‘special case’ scenario when using this mode. There’s enough of a reason why someone could use this, without paying attention to the naysayers (of course, that’s if you’re targeting the real machine, not emulation or such). And not like with the Genesis, where RGB *was* supported *and* used. And any NTSC artifacting used in games – was completely nullified by RGB setups. Good luck trying to get any emulators to support this type of artifacting though. I don’t know of any PCE emulators that even have NTSC filters (yet Kega has it for Genesis emulation. I guess enough games needed it to warrant it’s support).
Also, on another note; I think I got my h-blur demos wrong. That’s to say, the dithering pattern was wrong. It was checker board for a static image, but that turns each frame into vertical bars (because of how the dither pattern on every other line, aligns up). I guess the proper method would be to *not* phase shift the checker board dither by 1 pixel every other line. That way, it would appear as checker board on ALL frames (less flicker).
Edit: Oh, I also forget to mention. If you turn off the color burst when using this artifacting res, you also get a much larger greyscale range.