PCE color space

Anyone who’s played emulation via the real system, knows there’s a difference in colors/brightness. Usually, the first thing that comes to mind is how much more vibrant the colors are in RGB. It’s a no brainer.

I’ve was recently playing the Startling Odyssey 2 translation patch (which is a lot of fun, but that’s for another post/entry). The colors on the emulator look pretty bad. I always thought this. I figured the artist just chose some crappy colors to use. I mean, they attempt to emulate that SNES RPG color look but on a low RGB step value system. It’s hard to describe, but anyway. I decided, because I’ve been doing tests on my real system lately, to play the game on the real hardware. Holy crap. What a difference. The color choice becomes much more workable and appropriate. The graphics are actually good. Now, I’m not talking filter or scanlines. This is on my HD CRT. It has neither. The image of composite, on my HD set, has pixels as perfectly square as any emulation shot without filters (raw shot). I’m talking about the COLOR.

A good example, but definitely not limited to, is the open land back drop for the fight scenes. There’s a color of blue that’s barely even noticeable. I’m REALLY unnoticeable. On RGB of emulation. That’s mednafen, doing max RGB translation steps (of 36). Yet, on the TV – this is a clear difference between that and the next color up… which is for the upper sky color. It’s more than just about a picture being lighter or darker. It’s about the luma of each color in relation to the other colors, that’s totally different between RGB and the PCE’s conversion map rom (there’s a rom in the VCE that remaps all the RGB values into YUV color space). The patent of the VCE says the three Y,R-Y,B-Y DACs are 5bit. Separate from the 3bit RGB DACs. The 9bit RGB values of CRAM are used as a direct index into this table of 15bit color (5bit*3). Unfortunately, the patent only shows a few entries of this table ( a few first and a few last). If there is indeed a luma correction or bias, you’ll need the whole table to see it. It might be that there is infact such a bias built into the table, *or* could be from the mere fact 5bits is fairly low precision to represent the RGB to YUV conversion, and this you have some rounding (it’s a table after all, who knows what they tweaked or such). So whatever it is, I think some PCE artists directly had this in mind when choosing the color palette for game graphics.

Not only that, all the colors are softer on the real console. Yeah, they might be a little less vibrant, but the graphics are complete wrong in RGB.

The choice was easy. I’ve been working on a BRAM dump tool from my Duo/SGXCD, that dumps all 2k through the sound channels (you record it on the PC, and run the wave file through a decoder, to get the file out). In light of this, I added an option to update BRAM with any file on my custom util/CD. So I took the BRAM file from mednafen, decompressed it, put it on the CD, then updated the real system with my current save point. Now I can enjoy the games graphics with the colors in the way it was meant to be viewed. RGB was never officially supported on the PCE or TG. Nor were the RGB lines even amp’d for normal usage. On top of that RGB, via the back plane pins, was removed for the flag ship Duo series systems… which are arguably the main consoles when you talk PC-Engine (because of CD becoming the dominant format of the system).

Sure, that fixes that problem. But what if I want to play games using emulation. After all, I like to preserve my consoles. I play the real systems from time to time, but I like to keep the wear and tear down to little as possible. Mednafen provides a solution. The pass few releases of mednafen support ‘colormap’. Actually, two colormaps. One for normal, and one for B&W output of the PCE (color burst off, see Chris Covell’s B&W demos and some rare instances of PCE games using it).

With that in mind, I’m off to create a RGB make of the PCE’s real colors. Or as close to it as I can do. I’ll post some colormaps when I feel I have a good match. You can also use tools like Photoshop and such, that have the ability to adjust colors in HSL, to brighten or darken this map. I’d rather see a feature in mednafen to handle this, though 😉

Also, on a side note: There’s a difference between NTSC US and NTSC JP saturation levels. Assuming the VCE’s in both US and JP systems are identical (the amp circuit), your US Duo is showing less saturation that it should – if you’re using it on a US TV. JP composite on a US TV/setup will show less saturation. Buy how much, I’m not sure yet. But it means your colors should be a little bit both brighter and vibrant than what you’re seeing, if you’re using a US NTSC set or capture device (you can usually set this to JP NTSC though). I have a US Duo and a JP SGX and PCE. When I have some time, I’ll see if there’s a difference between them.


3 Responses to “PCE color space”

  1. Here’s a quick example of the normal plains back drop in the fight scene: http://www.pcedev.net/pics/composite_rgb/pce/SO2_compare1_large.png

  2. Excellent observation. I’ve noticed the same colour difference years ago. I’ve always felt like the Turbografx16 games really looked much better on a real system and CRT TV compared to what we get today with emulators. The images are much better shaded, melded and less harsh than on emulators. Compared to the SNES, with the current inaccurate colour maps the Turbografx16 seems to be at a disadvantage in terms of colour and overall image quality – they seem generally more “cartoony” compared to the more smoothly and softly blended graphics we see on the SNES. On the real system and TV I’ve mostly felt that the graphics on some of the better games on Turbo were at least on par with and often better than the graphics on similar SNES titles. e.g. Gate of Thunder, Lords of Thunder, Ys Book I & II, Shadow of the Beast, Super Star Soldier, Aero Blasters and Legendary Axe II to name a few.

    If you could implement this more accurate colour map/colour matrix that would be greatly appreciated. It’s probably one of the last few things that are missing for a near perfect emulated Turbo experience and I am sure it will make for a huge improvement in colour quality. Are you going to try to do a version that’s compatible with Mednafen’s custom colour matrix option? I see that this has already been accomplished on the NES emulation side. Can’t wait to see it on my favourite system. Thanks for your hard work and enthusiasm. Keep it up.

  3. Speaking from only observation of your post — “there’s a rom in the VCE that remaps all the RGB values into YUV color space” and “The 9bit RGB values of CRAM are used as a direct index into this table of 15bit color (5bit*3). Unfortunately, the patent only shows a few entries of this table ( a few first and a few last)”

    Wouldn’t it be possible to dump that VCE ROM and somehow using the patent’s limited visibility to discover the rest of the LUT?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: