TMS-RGB: An RGB Mod for 2020 and Beyond

[+grips03]

Thank you making TMS-RGB.  The install is very easy to do.  Very clean wire routing, solder points, etc.

 

I installed the TMS-RGB today and on the PVM it looks better than the Citrus3000psi RGB Colecovision I have

 

So I took the TMS-RGB Coleco up to the Sony LCD I use with OSSC and tried Pac-Man Collection.  With Ms. Pac-Man the orange ghost and the red ghost are almost the same color.  And the pattern for level 1 is orange.  If I play PMC with F18a the pattern for level 1 is red.  And red ghost and orange ghost are easily not the same color.

 

Anyway to adjust the colors on TMS-RGB to be more like F18A colors?

 

TMS-RGB board is from: Mobius Strip Technologies

RGB is cable is plain wire.

L9 has been removed.

First photo is TMS-RGB and 2nd photo is F18A.  Both use the same TV.

 

 

 

 

[Falonn]

It looks like the output from the OSSC is a little hot.  You might be able to adjust it via the OSSC's settings or simply by turning the brightness down on your TV.  Once they're toned down a bit, there should be a clearer distinction between the two Pac-Man ghosts.

 

For what it's worth, the "Light Red" and "Dark Red" colors that the TMS9928A outputs are nearly the same hue, so the chip can't really produce an orange and a red simultaneously.  Here is a shot from a vectorscope showing the full '9928A palette running on a Colecovision:

 

(Thanks and acknowledgements to Artemio Urbina for the vectorscope shot.  This is a tiny snippet and sneak peek from a larger investigation we've been helping Ikrananka with.)

 

The angle around the circle is the hue.  Since you can draw a line from the center mass out through both dots at the upper-left (near the "R"), that means (depending on your TV's settings) you're either getting two oranges or two reds, but not an orange and a red simultaneously.

 

The F18A gets to cheat and choose the colors arbitrarily.  TMS-RGB is pure analog and linear transformations, so while you can tweak things like how each channel is mixed (linearly), there isn't going to be a way to change the hue of one of the reds without changing the other.  This is one of those cases where the F18A's clear advantage in (35 year newer) capabilities easily outshines the original hardware.

[+grips03]

Does anyone else have TMS-RGB mod with OSSC?  Can you post pictures of the colors with the above games?  I'm most interested with Ms. Pac-Man. 

 

I do have a spare Citrus3000psi RGB board, so might swap back to that and see if its any better with OSSC.  My current Coleco with Citrus3000psi RGB is not so good.  I think its the memory going again on that one.

 

Did anyone ever make replacement CV system boards?

[ChildOfCv]

51 minutes ago, Falonn said:

It looks like the output from the OSSC is a little hot.  You might be able to adjust it via the OSSC's settings or simply by turning the brightness down on your TV.  Once they're toned down a bit, there should be a clearer distinction between the two Pac-Man ghosts.

 

For what it's worth, the "Light Red" and "Dark Red" colors that the TMS9928A outputs are nearly the same hue, so the chip can't really produce an orange and a red simultaneously.  Here is a shot from a vectorscope showing the full '9928A palette running on a Colecovision:

 

(Thanks and acknowledgements to Artemio Urbina for the vectorscope shot.  This is a tiny snippet and sneak peek from a larger investigation we've been helping Ikrananka with.)

 

The angle around the circle is the hue.  Since you can draw a line from the center mass out through both dots at the upper-left (near the "R"), that means (depending on your TV's settings) you're either getting two oranges or two reds, but not an orange and a red simultaneously.

 

The F18A gets to cheat and choose the colors arbitrarily.  TMS-RGB is pure analog and linear transformations, so while you can tweak things like how each channel is mixed (linearly), there isn't going to be a way to change the hue of one of the reds without changing the other.  This is one of those cases where the F18A's clear advantage in (35 year newer) capabilities easily outshines the original hardware.

Youtube recordings also seem to bear this out.

 

[+grips03]

Increasing color setting on TV helps.  I'm going to try more TV and OSSC settings. 

[cdoty]

Would this work with the TMS-9128/9?

 

The pinout seems to be the same.

[Falonn]

I'm having trouble finding my notes on it--I've never seen any of the 91xx's in the wild--but from memory I thought the only difference was an extra video mode and a slightly different palette (with better gamma correction) in the PAL version.  It was more of a revision to the 9928A/29A than a whole new chip.

 

My guess is that it should work just fine.  Out of curiosity what do you have that uses the 9128?

[ChildOfCv]

The pinout for the color components and the VCC/VSS are the same, so it should work.

[cdoty]

On 12/6/2020 at 6:08 PM, Falonn said:

 

I'm having trouble finding my notes on it--I've never seen any of the 91xx's in the wild--but from memory I thought the only difference was an extra video mode and a slightly different palette (with better gamma correction) in the PAL version.  It was more of a revision to the 9928A/29A than a whole new chip.

My guess is that it should work just fine.  Out of curiosity what do you have that uses the 9128?

I think the major difference is support for 4416 SRAM chips.

 

Several MSX machines use it, but I'm interested in using it on the BBC Bridge Companion, which I'm working on developing for.

Edited December 10, 2020 by cdoty

[retroillucid]

On 12/6/2020 at 7:08 PM, Falonn said:

I'm having trouble finding my notes on it--I've never seen any of the 91xx's in the wild--but from memory I thought the only difference was an extra video mode and a slightly different palette (with better gamma correction) in the PAL version.  It was more of a revision to the 9928A/29A than a whole new chip.

 

My guess is that it should work just fine.  Out of curiosity what do you have that uses the 9128?

Do you have any RGB Kit left?
I would like to get one if possible

[Falonn]

It looks like Mobius still has the preassembled boards in stock.

[Ianr757]

Hey all, I have a question. I just installed this mod in my Colecovision and it looks amazing overall. However, I have noticed that some colors, particularly the 5D4EFF and 8072FF blues, blink and flash as if there is some interference. This only seems to really happen on certain games, such as Tapper and Fathom, where it is extremely noticeable. Most other games do not have this issue. These games look fine on the composite setting. I have removed the shielding for the console. Could this be an issue resulting from my mod work, or a limitation of the mod? I am playing on a JVC professional monitor using the RGB SCART cables from Tim's NESRGB kit. The NES looks flawless through this set up. I don't have pictures unfortunately, as the issue is extremely hard to capture on camera.

[ChildOfCv]

The mod does not have any oscillators or anything that ought to blink.  It only does analog mixing to change YUV to RGB.

 

Are you sure this isn't the result of the Coleco's video processor and its maximum of 4 sprites per line?  You will get blinking due to that limitation.

 

Maybe you could take a video of the output for review?

[Ianr757]

52 minutes ago, ChildOfCv said:

The mod does not have any oscillators or anything that ought to blink.  It only does analog mixing to change YUV to RGB.

 

Are you sure this isn't the result of the Coleco's video processor and its maximum of 4 sprites per line?  You will get blinking due to that limitation.

 

Maybe you could take a video of the output for review?

I tried my best. Look in the top right corner to see the flashing/blinking. They look like horizontal lines.

 

Edited December 29, 2020 by Ianr757

[Ianr757]

[Ianr757]

It's worth watching a couple times and you should see it, horizontal lines towards the top.

[Ianr757]

Sorry for the awful camera quality. It's really hard to capture. 

[ChildOfCv]

Hmmm, I can't see any issues from the recorded video, unfortunately.  There's a moire pattern on the first video as you pan left, but I assume that's just what the camera is recording?  The only horizontal lines I see are the raster scan, and I assume that's not what you're referring to.

[Ianr757]

1 hour ago, ChildOfCv said:

Hmmm, I can't see any issues from the recorded video, unfortunately.  There's a moire pattern on the first video as you pan left, but I assume that's just what the camera is recording?  The only horizontal lines I see are the raster scan, and I assume that's not what you're referring to.

Yeah, it's something else that is nigh impossible to capture. Try this one. Look at the Fathom title and try to see if you notice the blue area flickering in a long rectangular motion off to its sides. 

[+-^CrossBow^-]

You may have said this earlier, but what do you have the RGB out connected into and ultimately to your TV?

 

I see stuff like this on occasion, but it is coming from my OSSC near as I can tell because I can switch to another input and then switch back and the anomalies won't be happening anymore.

 

[ChildOfCv]

 

1 hour ago, -^CrossBow^- said:

You may have said this earlier, but what do you have the RGB out connected into and ultimately to your TV?

 

I see stuff like this on occasion, but it is coming from my OSSC near as I can tell because I can switch to another input and then switch back and the anomalies won't be happening anymore.

 

22 hours ago, Ianr757 said:

JVC professional monitor using the RGB SCART cables from Tim's NESRGB kit

 

So, the far left has the moire pattern.  Near the Fathom lettering it shimmers like water waves.  Is that what you're referring to?

 

Does the JVC do digital processing?  If so, that could be filtering artifacts from attempting to enhance the image.  Most enhancement is intended for natural images.

[Ianr757]

3 hours ago, ChildOfCv said:

 

 

So, the far left has the moire pattern.  Near the Fathom lettering it shimmers like water waves.  Is that what you're referring to?

 

Does the JVC do digital processing?  If so, that could be filtering artifacts from attempting to enhance the image.  Most enhancement is intended for natural images.

Yes, the shimmering effect, that's a good way to put it. I believe we are on the same page now. I am not sure about my monitor. Here is the exact model and specs: http://pro.jvc.com/prof/attributes/features.jsp?model_id=MDL100987

It's a JVC TM-R14U. Thanks for the help thus far.

[Falonn]

I don't have a good answer, but I do have a few anecdotes that might be related to possible explanations:

 

1. "Strange behavior caused by large, solid-colored areas" is something I've seen from the VDP before.  At the time I mentioned I wasn't able to reproduce it over RF.  Eventually I was able to, though it was a little fainter because the poor quality from the RF output masked it pretty well.  I wonder if the same isn't the case here: perhaps some additional filtering along the RF path (to help clean it up) isn't hiding the effect and it can only now be seen when the veil has been lifted on the image quality?

 

2. More evidence of large, solid-colored areas causing things you might not expect: during our (still forthcoming) investigation into the 9928A's palette, Ikrananka noticed that the colors generated by the VDP varied slightly depending on the contents of the rest of the line!  A vectorscope measurement of an entire, solid-color screen showed a slightly different result than that same color when measured on a whole-palette-visible-at-once vertical bar test pattern screen.  This also doesn't involve the kind of flickering you're seeing, but it does drive home the idea that it was a very early, completely-analog design, implemented in chips that are just about to reach their 40th birthdays.  I would be willing to forgive some of their fussiness.

 

3. Continuing down the "it might be the VDP with the problem" path: it's kind of jarring how much strange stuff there is to uncover when you start reading the internal memos from the different TI development teams for the VDPs.  They go back and forth about the bugs and math they got wrong (the 9929A uses NTSC gamma correction even though it's a PAL chip; this wasn't corrected until the 9129 successor).  When you run the numbers to convert the YUV output voltages to RGB (with the assumption that the "White" entry in the palette should be at a full 100% R, G, and B), you end up with both blues clipping rather aggressively (>140%) in the blue channel and both reds clipping a little (105% and 119%) in the red channel.

 

Ikrananka uncovered an interesting piece of evidence that seems to suggest this may have been a bug.  In this old schematic of the Tatung Einstein TC01 computer (which uses the PAL chip, but with the same results), take a look at R019 (the smallest yellow circle):

 

 

That computer used a direct, (rare?) YUV output cable and left the Y and V signals completely untouched before the output voltage buffers.  But the 82 ohms on the U line forms a divider with R021's 470 ohms to ground, which would drop the voltage to about 85% of the input.  That brings the maximum clipping in the blue channel right in line with that in the red channel.  Presumably the Tatung engineers noticed that TI's VDP would output out-of-spec voltages if left uncorrected?  They appear to have opted for a slightly modified palette (with all the blues less saturated) in order to avoid any output that was over the limit.

 

I'm beginning to wonder if the ColecoVision folks didn't combat the problem using a different strategy: reduce the strength of all three (R, G, and B) channels until none of the channels clip for any color in the palette.  You'd be left with a white that was darker than it should be, but everything would be in-spec.  Looking at the video on the front page of the TMS-RGB site (say, Antarctic Adventure at 0:12), the RF recording on the left side shows something a lot more gray than white.

 

While choosing the output levels for TMS-RGB, I noticed that the SCART spec allows "synthetic pictures" to use a wider voltage range than "natural pictures" (footnote 8 on page 10), presumably for situations like these where the hardware is going to be pushing the very highest values to get fully saturated colors.  After running the numbers, it looked like the VDP's clipping on the blue channel would still be inside the expanded range, so I chose components that would deliver white-whites.  So, one explanation might be that your TV isn't as tolerant to blues that are so strong?  If the TV has some kind of "gain" or "picture" control, try reducing it to see if the flickering stops.

 

I've gone back and forth a few times now on my decision to make White fully bright at the expense of the blues being out of range.  The SCART document initially gave me confidence, but hearing about faint jailbars in some cases and now this flickering problem makes me wonder if toning the whole thing down to white showing as a light gray wouldn't have avoided some trouble for people.  Hmm.

[Ianr757]

32 minutes ago, Falonn said:

I don't have a good answer, but I do have a few anecdotes that might be related to possible explanations:

 

1. "Strange behavior caused by large, solid-colored areas" is something I've seen from the VDP before.  At the time I mentioned I wasn't able to reproduce it over RF.  Eventually I was able to, though it was a little fainter because the poor quality from the RF output masked it pretty well.  I wonder if the same isn't the case here: perhaps some additional filtering along the RF path (to help clean it up) isn't hiding the effect and it can only now be seen when the veil has been lifted on the image quality?

 

2. More evidence of large, solid-colored areas causing things you might not expect: during our (still forthcoming) investigation into the 9928A's palette, Ikrananka noticed that the colors generated by the VDP varied slightly depending on the contents of the rest of the line!  A vectorscope measurement of an entire, solid-color screen showed a slightly different result than that same color when measured on a whole-palette-visible-at-once vertical bar test pattern screen.  This also doesn't involve the kind of flickering you're seeing, but it does drive home the idea that it was a very early, completely-analog design, implemented in chips that are just about to reach their 40th birthdays.  I would be willing to forgive some of their fussiness.

 

3. Continuing down the "it might be the VDP with the problem" path: it's kind of jarring how much strange stuff there is to uncover when you start reading the internal memos from the different TI development teams for the VDPs.  They go back and forth about the bugs and math they got wrong (the 9929A uses NTSC gamma correction even though it's a PAL chip; this wasn't corrected until the 9129 successor).  When you run the numbers to convert the YUV output voltages to RGB (with the assumption that the "White" entry in the palette should be at a full 100% R, G, and B), you end up with both blues clipping rather aggressively (>140%) in the blue channel and both reds clipping a little (105% and 119%) in the red channel.

 

Ikrananka uncovered an interesting piece of evidence that seems to suggest this may have been a bug.  In this old schematic of the Tatung Einstein TC01 computer (which uses the PAL chip, but with the same results), take a look at R019 (the smallest yellow circle):

 

 

That computer used a direct, (rare?) YUV output cable and left the Y and V signals completely untouched before the output voltage buffers.  But the 82 ohms on the U line forms a divider with R021's 470 ohms to ground, which would drop the voltage to about 85% of the input.  That brings the maximum clipping in the blue channel right in line with that in the red channel.  Presumably the Tatung engineers noticed that TI's VDP would output out-of-spec voltages if left uncorrected?  They appear to have opted for a slightly modified palette (with all the blues less saturated) in order to avoid any output that was over the limit.

 

I'm beginning to wonder if the ColecoVision folks didn't combat the problem using a different strategy: reduce the strength of all three (R, G, and B) channels until none of the channels clip for any color in the palette.  You'd be left with a white that was darker than it should be, but everything would be in-spec.  Looking at the video on the front page of the TMS-RGB site (say, Antarctic Adventure at 0:12), the RF recording on the left side shows something a lot more gray than white.

 

While choosing the output levels for TMS-RGB, I noticed that the SCART spec allows "synthetic pictures" to use a wider voltage range than "natural pictures" (footnote 8 on page 10), presumably for situations like these where the hardware is going to be pushing the very highest values to get fully saturated colors.  After running the numbers, it looked like the VDP's clipping on the blue channel would still be inside the expanded range, so I chose components that would deliver white-whites.  So, one explanation might be that your TV isn't as tolerant to blues that are so strong?  If the TV has some kind of "gain" or "picture" control, try reducing it to see if the flickering stops.

 

I've gone back and forth a few times now on my decision to make White fully bright at the expense of the blues being out of range.  The SCART document initially gave me confidence, but hearing about faint jailbars in some cases and now this flickering problem makes me wonder if toning the whole thing down to white showing as a light gray wouldn't have avoided some trouble for people.  Hmm.

Thank you very much for the breakdown of potential issues and interesting read overall. Do you think there is a way to fix or reduce the severity of the flickering by removing, swapping or adding components either to the mod board or the Coleco motherboard? As far as I know, my monitor has no gain or picture equivalents. The only knobs that work with the RGB setting are V Hold, Contrast, Brightness, and Aperture. 

[Falonn]

On 12/31/2020 at 4:29 AM, Ianr757 said:

Do you think there is a way to fix or reduce the severity of the flickering by removing, swapping or adding components either to the mod board or the Coleco motherboard?

Having never seen this particular problem before, I wouldn't know where to begin, sorry.

 

If my hypothesis is true that it's more to do with a fussy, old chip than it is with the mod, you've always got the nuclear option of swapping the entire VDP out with something like the F18A.  (The last news we heard about the MK2 wasn't exactly what everyone was hoping for, but it's been a month or so since then, so hope begins to return.)