Dot-pattern averaging: Hacks to turn this on?

Hey everyone,

It is my understanding that the PCE has the ability to have its dot-pattern averaging turned on or off. Most games by Taito and NEC Avenue usually have it turned off, making the composite display much worse looking. So my question is the following: Are there any mods or hacks that can be applied to a ROM to have this enabled? Or is this kind of change a lot less trivial than it sounds?

 

What do you mean when you say "dot-pattern averaging?" I never heard of this before... Can you give a better description of what you're talking about? Maybe a source where you heard about it, how it can be turned on or off, and that taito and nec usually turn it off could be helpful

 

It's not that hard of a hack. Of course you'll need a flash card to get any benefit out of it, however.

Usually a game will write a value once to the VCE at address $0400 and then leave it at that. So most games that have averaging turned off can be "corrected" with a single byte hack to the ROM.

For example, I fixed Volfied by changing ROM offset $0003F from #$00 (low-res, no averaging) to #$04 (low-res, averaging).
(Use a clean ROM with NO header, and NON-scrambled bytes, of course.)

OutRun can be similarly corrected by changing offset $020E3 to #$04. (I haven't tested this one out on the real hardware.)

This..................... changes to (roughly) this..........


In other games, you usually look for a string of bytes like #$8D,#$00,#$04, and change the (usually) #$A9,#$00 preceding it to #$A9,#$04.

 

That's not a feature of real hardware, it's a special feature of the MAME emulator. MAME turns on horizontal blurring when you set that bit. On real hardware, that bit controls the number of lines in a field (262 or 263). I tried it on my SGX, and it makes no difference at all to the display.

 

That's where you're wrong. MAME does not enter into it. What "it" did you try on your SGX? If you ran a test on your SGX through an RGB hookup, then you won't see any change. This bit affects composite video only, just as the "greyscale bit" in the Turbo does. Which game or ROM did you test out?

 

Why would MAME emulate PC Engine to begin with? I don't recall official NEC license arcade games based on it.

 

Go! Go! Connie chan Jaka Jaka Janken uses the PCE hardware, so it's part of MAME.

ccovell: I used Out Run, changing the value stored to $400. I use svideo out to a 21" Multimedia Monitor capable of a LOT higher resolution than the PCE can output. The svideo mod is the same as done on the Duo.

Hmm - looking at the Archaic Pixels ref, you find this

It goes on about artifacting, but I think this is the main point:

So whether you see this in a game depends on the dot clock and the colors chosen.

 

Aha, there you go:

S-Video does not have the same artifacting as composite does, since many of the artifacts come from the luma/chroma information separation stage of Composite video decoding.

Anyway, to end this "I see it." "I don't see anything." game, here are some pictures that I took with a camera in front of my Sharp CRT TV. TV image enhancement (Movie, Game, Sharpening, etc) features are all turned OFF.

Of course, this artifact reduction is achieved by moving the artifacts around every 1/60th of a second, so there are many caveats: LCD TVs will blend even & odd frames anyway; cameras can't pick it up the same as the eye does; different games show it off to different degrees; and different people will notice it or not to different degrees.

 

Yeah, you're right. Svideo or RGB isn't going to see this. Also, that better description of what the bit does on Archaic Pixels helps.

 

Ah, that's neat! I'm rather surprised an automatic patcher to search and replace for those specific bytes hasn't been made yet. Artifacts seems like rather big issue IMHO, unless the feature was so obscure most people didn't know about it.

Actually, is there any case where you wouldn't want to enable this dot-pattern averaging? Might as well patch every single game then?!

 

Patching is generally easy, but not all the time. For instance Rastan Saga II didn't work after a single patch. The game reset $0400 to zero several times in the ROM, so I quickly NOPed them all out (not very safe) just for the purposes of taking the pictures.

There are actually several cases where you don't want the artifact reduction turned on:

* Games that autoscroll 1 pixel per field (1/60th of a second) either horizontally or vertically
* Games that use a lot of ordered dithering
* Games that use the 320-360 pixel mode, especially if they use ordered dithering

It really comes down to which type of game (though NEC Avenue & Taito still just did it out of sheer ignorance.)

 

Might be a good idea to make a list of games that could be improved with a patch, then start an archive of IPS files with said patches.

 

wow, I never knew about this, but then again, I only use either RGB or S-Vid

But my core question would be now, why didn't they not use that "superior" mode for any games? Since the PCE was AV only by default.

 

(quoting myself)

 

This a little old, but..
Archaic Pixels description is wrong. The bit does control the number of scanlines, but not exactly as simple as 263/262. When the bit is clear, the frame remains fixed at whatever number of scanlines 262. When the bit is enabled, it switches the frame length to 263. But there's a reason for this.

And that reason, is in direct relation to the color burst signal phase. On a normal frame, every other scanline has the CB 180 degrees out of phase (along with the color subcarrier out of phase to match it, on that scanline). I.e. each frame, the CB phase internal state gets toggled (either normal or 180). If you have DOT crawl bit enabled, the number of scanlines is 263. Since the state of CB is not reset at the start of the display, having 263 scanlines causes the next frame to invert which scanlines have the normal or 180 CB phase. It takes two frames for this to complete. On a regular TV (no advance filtering or such), the two frames average and the color artifacting does away. More complicated temporal filters on better TV sets, look at the two frame difference and are able to pulled the full resolution out of Y, of the composite signal. It looks great for static parts of the image. Of course, this on effect goes away with 60hz scrolling. Especially if the scrolling is horizontal and in 1 pixel increments (Forgotten Worlds is very good example. Just look at the first stage while it's scrolling VS the game paused).

There is no 1/2 pixel shifting or such, on the scanline. It only looks like that because of the cross talk between Y and C, on a composite signal. If it really was 1/2 pixel shift, a two frame accumulation or averaging, would blur the image - not make it sharp. Plus, I looked at the raw Y signal on an Oscope (VCE outputs raw Y without C).

There are advantages of having it on VS having it off - depending on the scrolling of the game. Vertical scrolling VS horizontal scroll, and if it's 1 pixel scrolling, etc.

Of course, RGB has none of this simply because it has no Y/C interference or a CB signal to alter color phasing. Like wise with svideo.

You can turn off the Color carrier output of the composite signal, with a bit on the VCE. But you can't (that I know of) turn off the auto CB phasing. That's too bad. The PCE's 7.159mhz dot clock mode (mid res), perfectly blends dithering without rainbow hue drift when this DOT crawl bit is turned off. You could get the advantages of the Sega Genesis/Megadrive artificial colors, if you could (and better looking too, no hue drift).

Also, from what I've tested, there's no way to tell what 'frame' the CB phase is in - on start up. That is to say, when you change between having it on and off - it doesn't reset the toggle state of the CB phase for the next frame. So you'll need user input to tell the program (visual pattern, like the old CoCo computer games) which 'phase' the frame is in for 262 scanline mode. That is, if you plan to abuse this and use it for artificial colors via dithering. Else you'll either get a random blue-ish/cool hue or red-ish/warm hue across the dithered artifacting.

I done something that works well with this (above), but only for 30hz images. I dither the image with vertical lines (line with Genesis games), and ~not~ XOR pattern dither. I turned the dot crawl bit off, and set the res to 7.159mhz. Then, I use an hsync setup for every scanline. On even frames, all odd scalines are shifted 1 pixel right; even scanlines are not shifted. Then on the next frame (odd frames), I invert the 1 pixel right shift; odd scalines have no shift, even scanlines have the 1 pixel shift. The result is that there is no bias in red/blue hue artifacting; you get a normal averaging. The places were the vertical line dithering is in the image, appears solid (it's actually solid in both eve and odd frames; it's just that two frames average the slight red/blue bias over two frame to even it out IIRC). Of course, the image is slightly soft because it's basically a 1pixel averaging effect (similar like static genesis images). The effect still works on RGB and svideo output, because of the averaging. Though it looks best on composite (because of the relation of Y being 7.159mhz, which is basically near exactly double the color subcarrier frequency). 10.74mhz res mode looks ok on composite too for this trick, but it benefits more in RGB mode since Y is not longer double of C's frequency in composite..

Since this thread is about the VCE, composite, and artifacts, etc. I'll mention a few other things. The VCE handles the RGB to YUV color space conversion with a simple internal precalculated rom. The 9bit RGB values in VCE color ram are specifically setup to be bit packed (rather than logically spaced liked with the Genesis), because the 9bit value is used as a index into a 512 YUV conversion table. The VCE outputs Y,R-Y,B-Y on three 5bit DACs. Because the DACs are only 5bit, there are errors in the version of RGB to YUV. The precalculated table has a slight bias in all three Y/U/V elements. If you disable the C output via the VCE, you'll get just Y. Because of the conversion, there are actually 32 values of Y instead of just 8. So you have true 32 grayscale output. It's actually CB is that's being disabled on the output - the color subcarrier is still there (along with alternating phasing of that subcarrier). So you'll still get Y/C cross talk, but the TV will treat the signal as if it's B/W because of the absences of CB. Thus, you'll get some more grays than just the pure 32 steps of Y - due to the cross talk. Shape Shift, IIRC, actually uses this bit in game to make B/W mode.

The other thing, is the RGB mods. Not only does Y have a bias, but U and V do as well - in the internal table. Some colors in the range of 'purple' are cooler and thus blend better with blues and greys. Some other colors/hues have some bias as well. And it's not just in a full range per se (depending on how you're categorizing the colors/hues/etc). I first noticed this in the blues; a few colors stand out more in difference than they do with an error-free conversion. Some games take advantage of this. Some don't.

And the last thing, which Ccovell has a nice demo of, is the interlacing trick you can do on the PCE. You can switch between 262/263 scanlines per frame. You can also generate an hsync interrupt on ~any~ scanline of the VDC - whether it's active display or not. With the right timing, you do an interlace display on regular SDTV CRTs - because they are analog devices and the timing works out fine. More modern TVs actually look at the EQ pulses and such, to determine of the signal is 480i or 240p. So the trick only works with normal SDTV CRTs. For what it's worth, I read that the SNES interlace mode does 262/263 scanline method. Instead of the 262.5 method. But I've never verified this on a scope. Genesis output is really weird. Even for 240p mode NTSC; there's a point where the VDP starts generating a ton of half scanlines. The weird thing is, if you made those half scanlines into full scanlines - you get 288p PAL frames (just going by scanline number per frame, not the refresh rate). This would explain why some newer or certain TVs/capture cards have problems with the Genesis (it's a VDP thing - not an RGB->Y/C thing, so it might be different on new revisions/ASICs).

 

Perhaps the table bias you're seeing is gamma correction?

A 5-bit DAC should be (barely) suitable in the sense that every input color is quantized to a unique output.

 

I dunno - maybe. At least, the stepping part itself isn't. It looks more like how they handled rounding. If you do 9bit RGB->YUV (24bit) and quantize YUV down to 15bit (5/5/5) and then back to 24bit RGB, you see very similar stepping due to the imprecision. Maybe they did apply some sort of gamma correct in the process of when they were creating the table itself. When I originally tried to duplicate this specific stepping, I had a few values of Y from the start of the table and the end of the table (from one of the patents). I did a frame capture with a capture card in B&W. It's been a while, but I believe I had a non-linear adjustment applied of Y in order to get the same Luma stepping as the frame capture and to match the partial rom entries from the patent. Yeah, I think you're right.

 

All RGB (technically R'G'B') is supposed to be gamma corrected before YIQ/YUV encoding, just as in a camera system. It would be silly for them not to with a LUT.

pow((1 / 7) * color_component_value, 0.45)

 

Yeah, but console hardware designers didn't always do things the right way. Sometimes they cheated ot just plain skipped stuff. North American NTSC and Japan NTSC aren't exacty the same; the Y range is compressed for NA compared to Japan (black starts at IRE 7 instead of IRE 0), but they didn't nothing to adjust for this on the NA version of PCE/Duo. IIRC, same for the SNES as well. As a result, certain darker colors are darker then they should normally be. I ~think~ (can't remember for sure) the brightest Y on NA ntsc standard is also a lower IRE level than ntsc japan.

 

The 7.5 IRE setup is hardly noticeable at all, plus the brightness control moves the offset up and down so (I think) it along with a slight turn of contrast (gain) can fully compensate. Since old consoles have low bit depths and high contrast game graphics the color non-linearity isn't so noticeable either until you start making side by side comparisons. Truthfully a lot of engineers were probably ignorant of gamma; arcade games don't seem to consider it at all (unless they do so strictly with their palette choices), or maybe they couldn't justify the expense of fast lookup ROMs, another register and one or two extra DAC bits per component; consoles on the other hand could do it for less than twice the linear DAC silicon since most integrated DAC seem to be binary decoded current sources/sinks so it'd only mean adding some more transistors here and there, but I'm not so sure that they did.

Once 3D consoles came around gamma correction was a necessity because without it you'd easily notice the distortion in (linear) transparency and lighting effects.

The brightest Y' has a compressed *digital* range (often so does R'G'B' and Y'CbCr), but it hits 100 IRE in analog connections everywhere as far as I know.