New Coleco RGB board?

[ChildOfCv]

8 minutes ago, Falonn said:

Looking at that preprocessor page, there's already something sync-strippy-looking going on there.

I believe it has 2 purposes.  1) Disconnect the VDP completely when external video is activated.  2) Add bias that's necessary for the LM1889 to function properly.  The 1889 has the quadrature encoder that sums the two 90-degree-phase-different sine waves after multiplying them by the color difference signals.  It's a differential amp that adds Y to R-Y and B-Y and multiplies by their respective sine waves.  The internal circuitry of the quadrature encoder requires positive voltages at all times, which it gets from the regulated DC voltage returning on pin 5.

 

And the 1889 also needs the negative bump of B-Y to generate the NTSC color burst signal of 180 degrees.  In other words, the 9928's output is tailored specifically to run the LM1889.

[Falonn]

I'd gotten as far as "disconnect when external video is enabled" while staring at it, but I'd lost the thread in the tangle after that.  Again, now that you've filled in the blanks, that seems plausible.  A "clean Y" output seems to be the only thing missing from my scheme of "just attach the mod to the RF riser pins".

 

I suppose mounting on the back of the VDP and including three extra/duplicate coupling caps isn't the worst thing.  The external video case will be broken either way.  (And it's beyond the scope of the simple YUV'ish-to-RGB conversion I'm interested in to try and de-composite the external video from Expansion Module #1 to work through the same RGB output.)

[MrPix]

For point two, visuals would help a lot.

The sentence that really caught my eye was "ChildofCV's new schematics...."

Are these of the Adam, or the CV?

I'm currently capturing the Adam's top board for reproduction with modernization.

[Falonn]

The new schematics are reversed (incredibly thoroughly) from a Rev J Coleco PCB, over here.

[ChildOfCv]

5 hours ago, MrPix said:

The sentence that really caught my eye was "ChildofCV's new schematics...."

Are these of the Adam, or the CV?

I'm currently capturing the Adam's top board for reproduction with modernization.

Yeah I only got my Colecovision.  I don't own an Adam at the moment, but there is a service manual that has the schematics in it, which is of fax quality.  In other words, it may still do you some good to continue reversing it yourself, but there is something available for you to compare notes with too.

 

http://adamarchive.org/archive/Adam/Technical/Coleco_ADAM_Technical_Reference_Manual.pdf

[MrPix]

I have two copies of that. One is fax monochrome so impossible to read half the nets. He other is grayscale, and ok far out, but you can’t zoom in much before it gets blurry. Worst thing is it has a few big errors. 
 

I’m working on corrections. 

[Falonn]

"Hopefully in a week or so" was probably too optimistic!  But I have some exciting progress to report:

 

I've built the TMS doc schematic on a breadboard, during which I discovered a half-dozen mistakes in the text and schematic (some minor, some not so minor).  Most of the problems had "easy" answers (specifying a 0.01 pF cap across the supply pins of one op-amp when the other two have 0.01 uF is pretty straightforward, etc.)  After reconciling all of that, doing the smoke test, and tuning the pots as described, I connected it through my Framemeister and lo and behold: a beautiful, crisp, sharp, bright, lovely image... with a very strong blue cast!

 

The original, nearly 40 year old, built exactly-as-specified TMS doc circuit doesn't solve the "there's too much blue" problem!  So much for putting that one on a pedestal.

 

Lots more to come, but here's the first bit of evidence from the scope:

 

An H-sync pulse (of an all-white screen) showing the C-sync out line (in yellow) and Blue out:

 

 

Instead of a proper colorburst, it seems to drop below the 0V level (which is presumably tricking the TV into believing the blue output range is much wider, making 0V an already-strong blue).

 

The same, but with all four output channels labeled:

 

 

I suspect if we can find a way to hold the color lines at 0V for the 5us after the pulse ends, the blue problem will be solved.

 

Curiously, just on both sides of the V-sync pulse (2 lines before and 12 after), those extra negative-going bits on the Blue output seem to disappear:

 

 

It was late last night, so I wasn't able to investigate as thoroughly as I would have liked.  If anyone has any requests for traces they'd like to see, just point me at the appropriate net on the schematic and I'll try to capture something for you.

 

[MrPix]

Daft question, but if you swap the RGB signals around, does the blue negative follow the signal or stay on that line?

Since you haven't mentioned a fast signal diode, I'm assuming you already know that isn't an option. What's your thinking?

[Falonn]

I haven't tried much yet.  I was close to finishing the circuit, thinking "cool, I'll get to sleep by 11."  Then I remembered I still had to make a test cart, solder all the bits to the console itself to get the real inputs, move the TV connections around so they'd reach the workbench, do all the other yak shaving, all before getting wrapped up in the mystery of the blue screen.  Those final scope images were taken around 3 AM. ?

 

I was thinking about my suggestion of "hold the color lines at 0V for the 5us after the pulse" and realized it would be easier to just "hold the color lines above 0V [at all times]".  That's just a limiter (with diode-drop compensation like the second example here with the op-amp), right?  I'll try to tinker around with that tonight along with trying to swap things around like you asked.  I also haven't spent much time looking at the inputs and correlating things with what ends up on the output.  Lots of work to do and this is just the first of the three circuits I wanted to characterize! ?

[emmanuelf]

Better use the PAL version to completely remove the color burst.

I bet that your are seeing is the result of the different summing of R-Y/B-Y/Y color burst. Only the Y signal color burst must be keep to not be affected by summing and be subtracted via Vref.

The original TI circuit is only valid for 100% compliant TV witch should refer to the back-porch level ant not to the minus of colorburst/back-porch but if the discrimination of the distorted colorburst fail, back-porch level referencing may fail depending of the implementation.

[+grips03]

I remember building the Baby Pacman version of the RGB circuit years ago and got too much blue as well. 

[MrPix]

Since it's blue, and Nobody Cares About Blue(tm) would the expedient thing to do be to add a slight DC offset/bias to it, then use the VR to dial it back in?

[ChildOfCv]

1 hour ago, MrPix said:

Since it's blue, and Nobody Cares About Blue(tm) would the expedient thing to do be to add a slight DC offset/bias to it, then use the VR to dial it back in?

The Hackaday project was engineered to remove the blue offset (as well as the red one, since it was inspired by a PAL TMS).  Hopefully it works.  It performs the sample-and-hold at a better time and enforces that voltage during the color TMS's color burst inducer.  So I'm keeping my fingers crossed for that.

[MrPix]

Since you're doing the heavy lifting on this, do you want to design, build and sell these yourself? Or are you looking for someone with SMD capability to do that bit of the heavy lifting?

It just seems fair and right that since you're doing the research for us, you should get first say in what happens next

[Falonn]

10 hours ago, emmanuelf said:

I bet that your are seeing is the result of the different summing of R-Y/B-Y/Y color burst...

Here are the inputs (Y, B-Y, R-Y, and the output Sync to compare it to) for a solid white screen, during H-blank:

 

 

Using the scope to add Y and B-Y together (without any of the "correction factor" mentioned in the document), that looks like a proper black level:

 

 

Comparing that to the actual Blue output at the bottom, the scope's math channel looks more correct.  I wonder if the circuit's order of operations isn't backwards?  Maybe they're doing the 2x first and the addition second?  That would magnify the little bump and cause what we're seeing on the Blue output line.  If you reverse the order, doing the addition first (like the purple Y + B-Y trace) and then do the 2x afterward, you'd get something closer to the correct answer without the below-0V pulse.  Hmm.

 

10 hours ago, emmanuelf said:

Better use the PAL version to completely remove the color burst.

 

7 hours ago, ChildOfCv said:

So I'm keeping my fingers crossed for [the Hackaday build].

You guys are probably right.  I was focused on fixing this circuit's problems.  It might be a more effective use of time to jump right to the more promising circuit instead.

 

7 hours ago, MrPix said:

Since you're doing the heavy lifting on this, do you want to design, build and sell these yourself?

I don't know about heavy lifting, hehe.  You guys (and the 11 pages of posts before this one) have done a lot more than I have! 

 

That said, if any of this does turn into a finished "product", I don't have any plans to produce physical things.  I've always wanted to do something like that, but I've got two kids under five years old and I already run my own other thing so it would be doing a disservice to the community to make them wait around until I could find the time to manufacture the next batch or whatever.

 

I like OSH-style projects: schematics/project files/BOMs/gerbers/etc. publicly available for the enterprising DIY'er but still plenty of room left for modder-types to provide a service on top of that (whether it be assembling/distributing kits or doing full installs).  Seeing page after page of requests for a DIY kit get shot down by Yurkie made me a little sad.  If we can put something together that solves all the known problems, then, if I have any say over it, I'd like to make sure everyone in the community has ready, permanent access to it.

 

That seems the most fair to me since whatever final version is going to be 95% based off already-public schematics.  Outside of a little elbow grease, I'm not sure I'm actually contributing much, hehe.  Besides, all of this is counting our chickens before they hatch! ?

[MrPix]

Well, it’s simple then. I’m a SMD friendly, low cost open hardware builder. I don’t have a huge profit motive and I like making self install assemblies. I’m happy to supply them to installers at close to cost price - I just need to cover costs, warranties and a bit towards equipment.
 

PS: pulled the trigger on a MSO1104 with the 16 channel DSO section and all the keys came free  Very impressed with your screen caps compared to my old workhorse. Only missing feature on my wishlist was CANbus decoding, and it turns out to get that is a $1000 increase in cost and getting a 2000 series. 

[ChildOfCv]

21 hours ago, Falonn said:

Comparing that to the actual Blue output at the bottom, the scope's math channel looks more correct.  I wonder if the circuit's order of operations isn't backwards?  Maybe they're doing the 2x first and the addition second?  That would magnify the little bump and cause what we're seeing on the Blue output line.  If you reverse the order, doing the addition first (like the purple Y + B-Y trace) and then do the 2x afterward, you'd get something closer to the correct answer without the below-0V pulse.  Hmm.

It may have to do with eliminating DC offsets.  The TMS can't output negative voltages, so it biases the R-Y and B-Y outputs at some DC offset close to 2.5V, with around .25V for full deflection of the color burst.  The Y signal is also always positive, but the signal appears to be 3V for white, 2V for black, and 1.7 for sync.  So a naive Y+B-Y will be around 5.5V for white, 4.5V for black, 4.2 for sync, and 4.2 for color burst.

 

But we need to remove some DC offsets to make a compliant signal.  It's (Y-2V) and (B-Y-2.5V) as the basis for proper blue output.  Well, if you want to keep it positive, then you can leave the 2.5V in.  But any scaling you do needs to keep that in mind.  If you naively apply a gain to the DC-biased voltage, you'll scale the bias too.  In other words, a signal that's 2.5V+/-0.5V with a 2x gain would be 5V+/-1V.

[Falonn]

2 hours ago, ChildOfCv said:

But we need to remove some DC offsets to make a compliant signal.

Hmm, I wonder if the Hackaday circuit is doing this correctly?  It goes through two op amp stages for each channel, so it definitely has more breathing room as far as number of available operations is concerned.

 

I tinkered with the op amp-based limiting/clipping recipe I'd mentioned back in post #284, but it looked like it was around two orders of magnitude too slow to work at these kinds of frequencies.  Rather than go down that rabbit hole any farther, I think I'll press on and start the next build.  I did want to be exhaustive, but I wonder how valuable it is to spend time on the "NTSC" ColecoRGB 1.2, since the method is the same as this one minus half of the useful bits?  It's simple enough that it would be a quick build, but maybe jumping right to the Hackaday circuit is a better idea...

[ChildOfCv]

1 hour ago, Falonn said:

Hmm, I wonder if the Hackaday circuit is doing this correctly?  It goes through two op amp stages for each channel, so it definitely has more breathing room as far as number of available operations is concerned.

It uses B-Y as its reference DC voltage during the sync pulse, and the gain setpoint for all op-amps is based on that Vref.  So... probably.

[MrPix]

My PCB designer is straining against the leash to be on the winner!

[Falonn]

Almost certain to find the same (or worse) results as last time, I decided to get the ColecoRGB ("NTSC") 1.2 build out of the way quickly (since it was the smallest one) before moving onto the most promising Hackaday circuit.

 

So, I was surprised when I got everything built and was greeted with a perfectly clean blue signal!  Some tinkering with the pots and I think I can see why this one has caused some trouble for people.  At least for the resistor values specified, adjusting the green pot through it's full range, I was only able to get the pk-pk voltage to go from 1.0V to 1.3V.  So there's room for improvement there.  (I haven't tried swapping it around yet, but looking at the schematic, the green output isn't symmetrical with B & R in terms of going through that extra 100Ω (R19), which I recall seeing in the LM359's datasheet.  Instead it's in series with 3.9kΩ (R20), which is almost certainly a mistake... why bother; just use 4kΩ instead or omit it entirely.)

 

All of that said, the most interesting bit of behavior I've spotted in the first 30 minutes of playing with it is what happens when you sweep through the full range of the blue pot:

 

 

The bad stuff is apparently still there hiding in the cracks, but the LM359 is performing some magic to clean it up until you get past a certain threshold.  Comparing this to the TMS Doc images above, it also appears to be doing the same to the (yellow) sync line.  Those two transient spikes on either side of the H-sync pulse are where the black levels were before.

 

How interesting!  I suspect this "tune it to just before the saturation point but no farther" is rather brittle and dependent on temperature, age, and how the graphics chip is feeling that day.  I feel like the verdict is "this can mostly work, but takes a lot of care and feeding."

 

This is subtle, but while testing with Popeye, I noticed that single-pixel columns seem to be too narrow (presumably by not swinging back to 1V fast enough?):

 

 

Left is a terrible cellphone image of my LCD TV's screen.  Right is from an emulator.  The too-narrow problem is even more pronounced when it's not white.  Depending on the pot tuning, the pink "1UP" at the top left of the screen just looked like a handful of scattered pixels because all the 1px wide parts were essentially invisible.  I don't remember this happening with the TMS Doc circuit, so I'll have to make a note to go back and check.  There is a chance that this is an artifact being produced by the Framemeister's up-scaling, but something about the output from this board just feels "clipped" compared to last time.  Maybe I've just forgotten over the past two weeks or maybe the implacable blue cast was able to hide this particular artifact?  I'll collect more data when it's not 2 AM.

 

In the meantime, same as before: please let me know if anyone is curious about a certain net and would like me to poke around with the scope and post images.  I don't know if I'll bother trying to swap that 100Ω resistor around on the green output before jumping right into the third and final build: 256byteram's Hackaday circuit!

[ChildOfCv]

If you use the blue pot to chop out the color burst, doesn't that also deaden the yellow colors though?  The NTSC color burst is negative blue, and negative blue on the color wheel is yellow.  So if it's unable to drop into yellow on color burst, it should also be unable to give you yellow during the visible picture due to clipping, so I'd be surprised if everything on the lower half of the color wheel wasn't pulled toward green or red.

[Falonn]

Aren't the negative voltages only ever used for non-color communication?  The color values themselves are always positive, right?  The impression I've gotten (at least for the Framemeister; I can't speak to how the OSSC or RGB monitors do things) is that the R, G, and B lines are assumed to have no negative voltages.  Then, 0V (or black) is taken to be the smallest value ever seen across all three color channels (within some reasonable time window, maybe once per-frame?) and the peak saturation level for any/all color channels is the largest value ever seen across all three.  (This why you want them to use the same 1V'ish pk-pk scale.  Raising one to a new max changes the scaling on the other two.)

 

It's this "color burst is below 0V" that causes the blue cast in the TMS Doc circuit.  By chopping it out here (and apparently clamping the output to 0V), the auto-scaling procedure done by the Framemeister seems to be handling everything normally.  The yellows are yellow.  Something else is being sacrificed in the process though.

 

I dredged out my Elgato HD60 capture box this morning so now we don't have to rely on awful phone pictures.

 

To really see the difference between these, view them full screen and switch back and forth using an image previewer that doesn't flicker or animate between images.

 

TMS: Raw 1080p capture from the "TMS Doc" board that includes the blue cast.

 

TMS-adjusted: I used an image editing app to artificially remove the blue cast (to make comparisons a little easier).

 

CRGB: Raw 1080p capture from the "ColecoRGB 1.2" board that shows the really stark, thin single-pixel columns.

 

CoolCV-scaled: My best attempt in an image editor to get the emulator screenshot to align with the others.

 

CoolCV: The source, unscaled screenshot from the emulator.  Just for completeness.

 

Switching back and forth between "TMS-adjusted" and "CRGB" shows just how bad that missing leading-edge of pixels looks in the ColecoRGB 1.2 circuit!  Sure it's crisp, bright, and whites are actually white... but the picture quality is awful.  Again, the "1UP" at the top-left is probably the most striking difference.

Edited March 15, 2020 by Falonn
Those image attachments didn't behave how I expected them to. Let me try again...

[Falonn]

As an aside: isn't that extra 100Ω in series with the B & R outputs technically causing an impedance mismatch for video signals?  If it's really necessary for the LM359's operation in this case, wouldn't the outputs need to run through something like a unity-gain buffer and then 75Ω to be properly matched and avoid reflections, etc.?

[MrPix]

11 hours ago, Falonn said:

All of that said, the most interesting bit of behavior I've spotted in the first 30 minutes of playing with it is what happens when you sweep through the full range of the blue pot:

 

Well that's interesting.

I also notice the slew rates on this circuit are a bit slower than on the previous one - which might feed into the narrow pixel problem...

Edited March 15, 2020 by MrPix