New Coleco RGB board?

[New Coleco RGB board?]

I like that idea a lot.

 

Hmm, in the meantime, I just tried switching over to the burst pin entirely to test my "the uC is just gilding the lily" statement above and I can't seem to get rid of the last bits of the blue.  Adjusting the 680k---not present in the schematic---on the Rset pin of the LM1881 up to 750k and then 910k was an incremental improvement each time, but the datasheet recommends not going much farther than that or the burst pin will start to exceed the standard timings.

 

While I'm here: this is just a small detail, but the LM6172 datasheet says that 14ohm is the typical output resistance.  Does that mean 60ohm would be a better value for the output resistors than 75?

 

[New Coleco RGB board?]

The burst can be eliminated with just pin 5 from the LM1881 to the DC restore mux (U3).  But U2 is doing something more interesting: removing all sync information from the RGB lines.  To do that, you have to switch it before the sync pulse, which means a timer and some counting.

 

Again, removing all sync is a little above-and-beyond, but I'd be willing to bet there is some wacky PVM out there that won't be compatible otherwise.  It's not like it's a proper "sync on green" that we're outputting otherwise.  Each line just has whatever strange combination of Y is left afterward, so it feels a little broken to me.  (This may be my inner perfectionist speaking, though.)

[ColecoVision 17 Watt 3.4 amp USB Power Supply solution (user review)]

I remember seeing that note on the little instruction card in the box ("It is suggested to unplug the USB power supply when not in use" at the lower-left corner on the back) and remarked it as strange at the time.  Since then, I realized the same must be true of all the linear regulators in all the old AC adapters (say, NES, SNES, etc.) and have gotten into the habit of unplugging them all.

 

It is good to hear it was just some warped plastic this time and nothing worse!  That is scary.

[New Coleco RGB board?]

Too exciting not to leave a quick note before sleep: the LM6172 creates a gorgeous picture.  No fiddling with capacitors.  No overshoot.  Full-width pixels.  No offset.  Just beautiful.

 

I've got a few more hours of programming to get the timing right on this microcontroller.  (The chip takes longer than the whole blanking interval to call the ISR!)   After that I'll have a screenshot that isn't corrupt, but all signs point to this being very promising.

 

Once that's done, I'll get to test my YUV vs. YPbPr theory by changing the resistor network.  Then we can run a poll or something about which set of screenshots looks more like the "real" colors from the RF output.

[New Coleco RGB board?]

Yeah, I knew to take the input resistors off (since the signal isn't coming in from an impedance-matched transmission line), but the 0.7Vp-p detail had escaped me, thanks!  I had hastily convinced myself that the doubling there was to get the output into the right range (despite that obviously leading to an incorrect order of operations in hindsight).

 

This is the modified schematic I put together last night with those input changes, replacing the CPLD with the uC, and updating the mux parts to the nearest model I could find that was still available.  (A fun coincidence: I only had to transpose the digits of the year for the "modified on" date.  18 years later to the day.)

 

Because the stages are laid out so simply without needing to shift voltages into the supply range, the new resistor values are easy:

 

For 1.4x gain, R8 should be 188ohm (or 270 || 620).

For 1.78x gain, R10 should be 364ohm (or 390 || 5k6).

 

I'll get the schematic updated with those.  (Although, I suppose those values are starting to get a little low.  I wonder if I should run the numbers to make sure we'll still be inside the LM6172's max output current...)

 

The Digi-Key stuff didn't actually arrive until this afternoon, but I realized a few days ago that these builds always take several consecutive evenings.  So there wasn't any reason I couldn't use stand-in ICs in the meantime and just build around those.  All of that is to say I've got a breadboard full of 555 timers (instead of LM6172's) that is a good 40%'ish of the way complete.

 

Regarding the -5V requirement, you guessed it.  Again, aesthetically I really like this one (more than the elbow grease it takes to shift things into range in the Hackaday circuit), so I've got high hopes that the results will turn out really nice in this 4th attempt.  Now that I know the negative rail can be solved for $0.93 (in single quantities, no less) that's all the better.

 

The most recent switch from the "level 2 simplification" to the "level 1" schematic (despite its requirement of a "smart" component that can anticipate blanking) is kind of a "stretch goal", but a completely clean RGB out with all pulses removed seems like a nice aspirational goal for maximum compatibility.  If somebody needs them (say, for Sync-on-Green), it's a lot easier to combine things again afterward than it is to remove them.

 

On 4/9/2020 at 11:05 AM, MrPix said:

The LMH1251 is available from main sources for $5 or less. Shop around.

With TI's own 1ku pricing showing $5.38, I would be skeptical of anything I found for "$5 or less".  Are you sure they're genuine?  The $11 I paid was individual pricing, which I usually expect to be high... just not that high.

[New Coleco RGB board?]

My Digi-Key order is supposed to arrive tomorrow.  In the meantime, I've found some interesting tidbits that might be helpful:

 

• The author of this (unrelated, but awesome) Colecovision-from-scratch project was struggling with how to get a -5V rail (for the controller ports) from just his 5V supply.  He pointed out the TPS60403 as a solution.  At $0.93, a tiny footprint, and Vout = -Vin (for Vin between 1.6V and 5.5V), that little charge pump would be a neat answer to keep the install as simple as possible with one fewer wire coming in from a nearby pad (or farther if you've done the 5V VRAM mod).  In terms of designing a DIY kit that someone can buy pre-assembled, the extra dollar is almost certainly worth having one fewer installation/troubleshooting step.  Now (should the ELM circuit end up superior), I'm less worried about it requiring a -5V rail.

 

• I noticed in the datasheet for the (exorbitantly-priced) LMH1251 that the lowest resolution it mentions supporting is 240p.  I hope I didn't just spend $11 on something that has no chance of working! I suppose we'll find out soon.  At least this was one of the rare occasions where I only ordered a single chip without any backups.

 

• The ELM project page keeps paying dividends.  They've got a series of schematics there from the most-complete version (with RGB, composite, and S-video out), the first simplification (with clean RGB only), and the second simplification (leaving the sync pulses on the RGB lines).  I had initially linked the latter because the other two included a CPLD which seemed a little out of scope for our purposes.  But, going back and reviewing the first simplification, that CPLD is doing something really cool:

 

The schematic has two of those muxes.  The bottom one (U3) might as well be a 4066B with an unused channel, that is, 3x SPST switches all controlled by the same line (or, 3PST).  It's used exactly the same as in the TMS Doc for DC restoration, except on all three channels instead of just R-Y and B-Y.  Much more interesting is the top one (U2), which is behaving like a 3PDT switch.  For the entire blanking interval (from the beginning of the front porch all the way to the end of the back porch), it just feeds analog ground into the op amps.  All pulses, blanking, syncing, and bursts are completely erased!  Once the blanking interval is over, it switches back to the just-zeroed-on-black signal lines and things proceed from there.  All op-amp math is done with the black level at 0V, which makes the rest very simple.  From an aesthetic standpoint, this is my favorite circuit idea by a mile and it intuitively feels like it would be the most compatible with any equipment out there.

 

Of course, to do any of that, you'd need to anticipate the blanking period.  The LM1881 takes a few ns to respond to the sync from the Y input and doesn't have anything at all resembling a "full blanking period" signal.

 

The trick is that the CPLD has been taught to understand NTSC blanking so it predicts them instead of reacting to them.

 

My plan is still to build the most-simplified version and see how it turns out.  If too-much-blue is still a problem, I suspect a little microcontroller (say, the 6-pin, grain of rice sized ATTiny9 at $0.33) using its timer peripheral and a couple interrupts could perform the same trick just as well as the CPLD.  Although, this is one of those DIY-kit hostile things: it would leave users in a position where they might have to find a way to program their own chip.  I emailed Digi-Key to see how much their programming service is for a one-off purchase (say, if someone wanted to build the final board from parts instead of getting it pre-assembled from someone like MrPix or MobiusStripTech), but I haven't heard back yet.

 

If it comes down to a microcontroller, ideally we could cobble something together that was adaptive so the same code works for NTSC and PAL.  The code listing for the CPLD on the ELM page has a "263 for NTSC, 313 for PAL" comment in the source, which is undesirable.  Placing a premium on install procedure simplicity, making a choice based on your region is another accident-prone step that it would be nice to avoid!

[New Coleco RGB board?]

You caught me minutes before my next DigiKey order.  Nice timing!  I threw a few of each of those in there along with a grab bag of other things I've seen mentioned elsewhere and the couple of ICs for the ELM circuit.  I even included one of the (exorbitantly-priced) LMH1251 you can just make out in the picture of the RetroTINK COMP2RGB.  That's 2/3 (and the most interesting part) of the resistor network in a single IC, which might be interesting to experiment with.  If it doesn't reduce the cost, it would at least reduce the number of line items in the BOM pretty significantly. 😅

[New Coleco RGB board?]

Since none of this will work with video generated by ColecoVision Expansion Module #1 (where RF will still be the only fallback) and for ease-of-installation, I fear that keeping the rest of the circuit undisturbed is a hard requirement.

 

Would it help if the very first thing we did was run each of the 992x inputs into a voltage follower?

[New Coleco RGB board?]

Thanks again, everyone.  As I seem to have jumped into the deep end of the pool in the hopes of learning to swim, all of you have been making patient, encouraging, and helpful gestures at me from the poolside while I thrash around and try to get my bearings!

 

@ChildOfCv I wouldn't have thought to use a different reference point.  That is a useful tool.  After carefully walking through your explanation (several times, slowly, hehe), it's all making more sense.

 

@Tursi I recall seeing that EEVBlog video a few years ago near the beginning of my self-teaching.  Almost all of it sailed over my head at the time.  Thank you for the reminder!  This time around I got a lot more out of it.  In particular, the idea of "virtual ground" was still in the hazy-concept stage in my brain.  Now it's a lot more concrete.

 

A few more results/notes:

 

1. I've been meaning to say for a few posts that for whatever reason, these screen captures seem to show a nicer, more forgiving picture than the TV itself.  In the Hackaday output, there was some distinct noise (almost "jailbars", especially on an all-black screen) and the top of the screen was brighter (with a white background cast) than the rest.  But none of that was showing up via the capture device.  Just now, I think I discovered the reason: viewing angle!  From my little workbench, I'm super off-axis from the TV (say, 150-degrees), so I'm apparently viewing with "enhanced artifacts" goggles on.  This was helpful, because I could verify an even greater difference when...

 

2. I tried bigger caps and it makes a huge difference!  470uF electrolytics are comically large (and a little scary) on the breadboard, but the white at the top of the screen and the repeating pattern in the solid colors (visible as jailbars on a black screen) are both completely gone.  Even from my severe viewing angle, things are very clean now.

 

3. Using the same trick from the TMS schematic of adding ~10pF capacitors in parallel with the negative feedback path on each output amp has cleaned up maybe half of the rising pixel overshoot, which is another subtle improvement.

 

4. I still haven't found a workaround for the falling pixel "smear"/slow-discharge.  It's nearly two pixels wide, which is kind of a deal-breaker (and weird, considering the XR8054 has ~3x the slew rate of the LM318, which doesn't exhibit this problem).  Although, I'm wondering if it isn't a moot point since it's most-likely opamp-specific and this model has been discontinued.  Or maybe it's still a weak breadboard connection someplace, like ChildOfCV suggested.

 

5. Switching back to the TMS board for one last experiment: I wanted to try the scheme from the (newly discovered) ELM schematic where DC restoration is done to B-Y and R-Y during the LM1881's burst output (instead of just during sync, like the TMS doc shows).  It's very close now, but there's still a tiny dip lower than the black level.  (And now the leading edge of pixels are very slightly softer, maybe 10% of the way toward the problem exhibited by ColecoRGB 1.2.  I suspect I didn't adapt the technique to the TMS schematic 100% correctly... there are a lot of moving parts in there and my attempt was a little hasty.)

 

So here is the current state of the project:

 

TMS Doc + LM1881 (and an inverter to make the Burst output active-high for the 4066B control lines)

Good: Very clean (soft'ish) output

Bad: Too much blue; requires oscilloscope tuning; requires +12V and -5V rails

 

 

ColecoRGB 1.2

Good: ... it outputs a picture

Bad: It's an unusably bad picture; requires oscilloscope tuning; full range of trimmers isn't enough

 

 

Hackaday + 10x larger output caps + small negative feedback caps on R, G, B output amps

Good: Clean, sharp output; no tuning required

Bad: Uses a discontinued part; some overshoot and color smear still remain; those nearly-indistinguishable greens make me worry about the color accuracy

 

 

Future work

- Try building the ELM circuit?  (I'm still really excited about those resistor values for color accuracy!)

- Find a replacement amp for Hackaday and hope that it also fixes the smear/bleed?

- Build the Hackaday circuit (with improvements) on protoboard (or even a proper PCB?) to determine how big an impact the breadboard is having?

- Any other suggestions?

 

What do you guys think?  I'm running low on experiments and we haven't found a perfect (or even almost-perfect) solution yet.

[New Coleco RGB board?]

Well, that's anti-climactic.  Last night I had swapped back to the first XR8054 SMT-to-DIP adapter board I'd made for no other reason than because I'd already added the little "U1 & U2" label to the first one.  Tonight, in preparation for my anticipated long debugging search (possibly rebuilding the whole board if necessary), I did a quick power-on to make sure things were in their last known state... and this was the result:

 

 

So, I suppose, lets chalk it up to a flaky breadboard and hopefully it won't crop up again.  *sigh*

 

Alright, first off: lots and lots of ringing!  Red takes too long to discharge.  Green areas begin with too much overshoot.  Some of this is probably the breadboard's fault, but I'm going to try the same capacitor trick from the TMS board to see if it can at least mitigate the green problem.

 

As for the good: the colors are (a lot) better than ColecoRGB 1.2 and it doesn't suffer from the awful cut-off pixel problem.

 

Comparing it against the CoolCV emulator screenshot (which I haven't actually validated as having accurate colors), blue is a little dark and green is super bright, almost neon.  The difference between the two colors of grass is hard to distinguish because they're both super saturated.

 

Question 1: Does anyone know if there is a nice, reference standard emulator out there that has gone out of their way for good color accuracy?

 

That would help with verification and tuning.  I've seen this AA topic, which seems to take the subject pretty seriously, but I'm not sure if that work ever ended up in something I can download.

 

Also last night, while trying to dig into op-amp theory (for the third or fourth time) and trying to figure out the operations for each amp, I got a different answer for U2A's output than your result above, ChildOfCV.  It was tough to track down anyone talking about negative feedback going to anything besides ground, but this answer looked promising.

 

With Vi=2.5V (Vref), Ri=2k, Rf=1k, Vp=R-Y, and using their formula, I got: 1.5*R-Y - 1.25V.  Although, with an unknown impedance on the R-Y line, I wasn't quite sure how to calculate (using superposition? or the op-amp summing network formula?) what to do with that 10k to Vref.  Still, I'm curious how you found that the 1.5x also applies to the negative feedback Vref term?

 

In many topics here (and several times in this one), I've seen people describe the TMS992xA as outputting something like "almost component but with weird scaling and biasing".  While digging around some more (last night was research-heavy), after re-reading "in conformance to standard industry practice [we divide by 1.14 and 2.03]" in the TMS doc, I was curious how that was standard.  In the Hackaday schematic, he even named the B-Y input line "U".  Looking up the YUV color space, it's apparently exactly the same as component (YPbPr, which uses B-Y and R-Y lines) except with those scaling terms.

 

Question 2: Does that mean a more accurate description would be "YUV with a DC bias" and that we should be calling these the U and V lines instead of B-Y and R-Y?  (Was that just nomenclature that wasn't in use when the chip was designed?  Do they avoid it because YUV seems to also imply half-bandwidth for the U and V channels?)

 

Once we're free to search for "YUV to RGB converter" instead of something much more TMS-specific, there are hundreds of these things all over the place.  One of the first results is this delightful project with a wonderful schematic.  The op-amp analysis is already done in the margins and it looks like much(!) more care was taken in picking the resistor values than any of these three other known boards.  (The schematic continues to go to the trouble of listing the parallel resistor combinations needed to get the exact values required.  It's really very nice.)

 

That reminded me of the wording in the TMS doc: "[Our] purpose is to produce a bright, sharp image [...] rather than to produce a very accurate color difference..."  And now I'm wondering how much better things could get if our purpose was actually color accuracy! 😉

 

I haven't studied it in detail yet, but the idea in the (what I'm calling) ELM circuit above appears to be a combination of all the good parts we've seen so far: the same DC restoration idea from the TMS doc (and possibly color burst cleanup at the same time by using an LM1881?!) using a mux the same way as TMS Doc uses the 4066.  And then two amp stages like the Hackaday board, which should allow for much better color accuracy (when you actually take the time to pick good resistor values).

 

It does still need a -5V rail which is kind of a bummer, but in doing so, it saves all the complexity of the sample-and-hold for the bias voltage (and makes the analysis almost trivial).

 

I'm tempted to build the ELM circuit as-specified, like the others... but I wonder if just grafting those nice resistor values along with our other lessons learned as we near the final solution wouldn't be more expedient?  Now that it's been, what, two months that we've been dissecting these things, I'm starting to feel a tiny bit more confident about what to expect from this repeating pattern of "a little up-front cleanup followed by voltage math".

[New Coleco RGB board?]

3 hours ago, ChildOfCv said:

Check the resistance between the "-" pin and the output of "U2A".

The meter is showing 740 ohms across the IC pins while in-circuit.  The feedback resistor (R11) tested in isolation afterward is exactly 1000 ohm, down to as much precision as my meter has.  (I intentionally grabbed a set of 1% tolerance resistors for this project and then hand-picked the closest one from the 20pcs of each value as I went along.)

[New Coleco RGB board?]

5 hours ago, ChildOfCv said:

Falonn's is a few giant steps above.

No way, hehe, it's just the quintessential, entry-level Rigol DS1054Z (with the software stuff unlocked) that you see recommended everywhere as "what's the cheapest scope I should buy?"

 

9 hours ago, ChildOfCv said:

What is R-Y's typical voltage?  Is it at least close to B-Y?

With nothing at all connected to the Colecovision board (except the scope probes), the R-Y and B-Y pins of my 9928A are showing the exact same range:

 

Popeye game selection screen:

Y: 1.8V to 3.16V  (black at 2.2V)
R-Y: 2.2V to 3.16V (blank at 2.63V)
B-Y: 2.2V to 3.16V (blank at 2.63V)

 

Solid white screen (test cart):

Y: 1.8V to 3.16V (black at 2.2V)
R-Y: 2.6V, always
B-Y: 2.3V to 2.63V (blank at 2.63V, burst at 2.3V)

 

9 hours ago, ChildOfCv said:

So perhaps the next useful scope traces would be the +, -, and output of U2A.

It is worth mentioning: the XR8052 amps in the schematic were discontinued the year after the schematic was made.  I wasn't able to find any of those in the usual places, but there were still a handful (literally, less than a dozen) of the four-channel XR8054 sister chips left at Digikey.  So instead of 3x two-channel amps, I had to build this with U1 and U2 combined into a four-channel chip and U3 on its own with the C and D channels wired as plain unity-gain with a voltage divider feeding around 2.5V into the input (as recommended for unused op-amp channels).  As far as I can tell, this has had zero impact, but it's good to clarify.  (When you say U2A, it really means something like U1C when I go to find the pin, hehe.)  Should we find a way to get this board working, a suitable replacement part for these discontinued ICs will be yet another challenge...

 

As for U2A, here are the traces for about three lines (directly from the IC's pins):

- Ch1 (yellow): Burst, pin 5 from LM1881

- Ch2 (cyan😞 U2A output

- Ch3 (pink): U2A negative input

- Ch4 (dk.blue): U2A positive input

 

Test conditions (in order):

- solid "white" (actually fuscia) screen

- solid "black" (actually red) screen

- Popeye mode select

 

  

 

 

In the meantime, I've also conducted a couple of my own experiments:

 

Experiment #1: Graft the R-Y/B-Y DC Restoration scheme from TMS over to Hackaday

 

It took four or five readings before it finally clicked yesterday, but the scheme in the old TI document is really graceful for making sure the blanking level comes in at 0V.  They couple the inputs with a fairly large'ish capacitor, but then during blanking, they open a pair of 4066 switches to ground them.

 

I thought I'd give it a shot to try and get things back in range, so I tacked this onto the beginning of the Hackaday circuit (temporarily; since removed):

 

 

It actually got pretty close.  Instead of going crazy and over-saturating the red almost immediately, it mostly just looked like a red version of the usual "too much blue" we've seen elsewhere, and then around 10 seconds later, it would eventually creep back up to being a mess.  Still, an interesting experiment to be sure.

 

Experiment #2: Use the wonderful burst signal from the LM1881 to try and do something in the TMS circuit

 

I had a couple of 4066 channels free on that board already and connecting an LM1881 is trivial, so I wondered what would happen if I just used the 4066 to "shut off" the B-Y and R-Y inputs during the burst interval?  That should look like this:

 

 

Alright, yeah, they're technically floating inputs during the burst, so who knows what you'll get...

 

The answer (at least on my Colecovision) is that the too-much-blue problem is solved(!)... replaced by a tiny-bit-too-much-green problem instead. 😆

 

I was hoping for a perfectly flat B-Y signal when the 4066 was off during burst.  Instead, I got a smoothed-out, slight positive bump for the entire duration.  That's fine for blue.  Positive doesn't impact the auto-scaling done by the receiver.  But when green is calculated by subtracting the B-Y line, you get a slight negative bump.  And that does impact the auto-scaling.

 

In any event, this is very close to correct now:

 

(The green is strongest at the top of the screen and fades to black by the bottom.  It's much easier to see on the TV.  In this capture from my Elgato HD60, you almost need to raise the brightness before you can see the solid green in the background.)

 

I haven't tried it yet, but the next experiment will hopefully be a refinement that should fix this outright:

 

Instead of a 4066 channel that's either on or off, you could use a little SPDT switch (like this one) to switch from B-Y/R-Y (or even the R, G, B outputs themselves) over to, say, a voltage divider between 5V and GND that was set right at the black level.  No more floating data.  Perfectly flat line (hopefully/in-theory).

 

Thinking about it more, it might even help with the trimmer pot tuning!  Since the black level during burst would be forced to 0.3V by the divider network regardless of the pots, there would be a perfect sweet spot (when adjusting the blue pot on an NTSC system) where the (now artificially induced) too-much-blue would fade to black just before switching to too-much-green.  You could most-likely tune it by eye instead of needing a scope.

 

Speaking of auto-tuning, the more I think about a circuit without trimmer pots, the more I have my doubts.  While re-reading the TMS doc, I ran across their reasoning for DC restoration: "In the case of an RGB encoder, a black screen with dark red letters might appear as a gray screen with pink letters" followed later by "unfortunately, the R-Y and B-Y signals are not guaranteed to have a most negative or positive excursion within any particular period of time" and "the output level of the video display processor can vary from device to device as a function of process, or as a function of temperature".

 

It makes me wonder if the Hackaday circuit wasn't designed for his particular chip and mine is just a "fussier" one?

 

At any rate, those three statements taken together make me wonder if any sort of auto- or preset-scaling might be a lost cause?  What works for one board probably won't on another, right?  (That may even be what we're seeing here already.)

 

As-is, I already had to remove the 82-ohm pull-down/divider from the sync output (R25) on the Hackaday board before it would even sync on my Framemeister.  And the output is AC-coupled, which is contentious at best.  (The TL;DR; for that page is "they probably shouldn't be; TVs are pretty forgiving; and in some extreme cases you may even have to!")

 

So I'm leaning even more heavily toward "TMS Doc with half the discrete parts replaced by an LM1881 plus something to filter out the color bursts" as being the most promising path.  I ordered some of those little SPDT switches to try next.  (We'll see when/if they arrive...)

[New Coleco RGB board?]

My first sanity check (before spotting your post) was to swap out all the ICs with spares, just in case I'd destroyed one with ESD or when soldering the small ones to the adapter boards.  No effect / identical results.

 

Now, following along with your description:

 

1) Yes, this is very clear coming off pin 1 of LM1881.  About 150mV when active, 3.3V otherwise.

 

2 & 3) Yes, testing the net between U4A and U4D (pin 2 of the 4066), it's essentially the inverse of sync: 4.8V when active, 650mV otherwise.

 

4 & 5) As B-Y hasn't been DC-restored at this point, (on an all-white screen,) it's always 2.65V, except during the burst period when it's 2.3V.  The sample/hold seems to be working correctly as the positive input to U6 shows a flat 2.65V at all times.

 

U6's positive input might as well be a perfectly flat line.  The output (Vref, in pink) is similar, but not quite as clean:

 

 

 

Yellow is pin 1 of the LM1881.

 

1) Yep, the burst output (LM1881 pin 5, in pink) neatly covers the full duration of the color burst on the B-Y line (in blue).

 

 

2) The negative input of U2A is exactly Vref.  Zoomed way in, the traces overlay exactly.

 

Comparing this to the other circuits where the B-Y color burst was at or dipping just below 0V, it's a little strange that it's hanging out around 2.3V, here.  Is there a missing DC restoration step?  Would DC restoration fix this?

[New Coleco RGB board?]

Yeah, as soon as I saw the initial red cast on the TV, I shut everything off and switched back to one of the other boards to make sure I hadn't somehow damaged the Colecovision.  (I hadn't.)  Next is a meticulous confirmation that each op-amp channel is still working correctly.

 

Here's the family portrait, now that they're all complete:

 

 

Looking at the Hackaday schematic a little more, is it really the sample-and-hold (with the TL081) that's cleaning up the color burst?  From the looks of it, that's just doing the auto-scaling (so it doesn't need any trim pots).  Isn't it the pair of 4066 channels being controlled by "burst" (pin 5) of the LM1881 that actually does the cleaning up?

 

If that's all it takes, it should be easy to port just that piece of it over to the TMS circuit.  (There are even two unused 4066 channels left on that board, so it wouldn't take any additional chips.  And adding an LM1881 means dropping like half the part count from the TMS circuit. hehe.)

 

Still, I would have liked fully automatic scaling.  Hopefully I'll be able to suss out what's going wrong here...

[New Coleco RGB board?]

Good news and bad news for the Hackaday circuit.  The good: it does appear to suppress the blue color burst correctly.  The bad: something is very wrong in the red channel.  The output level is way up in the 4V range.

 

I've done an initial pass at double-checking all the components are where they need to be (and doing a few sanity checks with the scope), but didn't spot any obvious mistakes.  I confirm each resistor value with a meter before it even makes it to the breadboard, so that shouldn't be the problem.

 

Just tinkering around---knowing this circuit doesn't use split rail op-amps, so this probably wouldn't work---I added the same 10uF coupling caps used in the TMS circuit to the B-Y and R-Y inputs.  The result was interesting to look at, but not much better.  Here (at 4 seconds), I press the reset button and we get to watch the caps charging in real-time:

 

 

It's curious that the same isn't true of the blue output.  They're nearly symmetrical in the schematic.  I'll poke around tonight to check for mistakes again.  If anyone has suggestions on what to check, I'd love to hear them!  (Unless there are more electrical differences between the 28A and 29A than I know about, we've already seen this circuit work on a PAL Colecovision a few pages back, so this is most-likely my fault.)

 

I am heartened by the blue color burst being removed, at least.  We're nearly at the point of grabbing the best pieces from each circuit and creating some Frankenstein's monster that actually works.

[New Coleco RGB board?]

"d.c. component" makes it sound like just the bias with the 0.7V on top of that.  And yes, having an official source is awesome.  I'd also been looking for something like this.  Thanks!

[New Coleco RGB board?]

FWIW, I spotted this TI blog post while learning about the overshoot/ringing problem on the TMS board.  They suggested adjusting the cap in the negative feedback network.

 

As it turns out, one of the very few, small substitutions I had to make while constructing these was using 4.7pF instead of 5pF in those places.  I didn't have any 5pF caps.  The next size up in my parts bin was 15pF.  Swapping each 4.7 out for 15 on the R and B amps eliminated the overshoot in those channels.  The green channel still has a little, and 15pF was either too much or too little, but this gives me hope that the problem is just coming down to parasitic capacitance from the breadboard and the wires flying all over the place.

 

Now the (still too-blue) picture from the TMS Doc board looks even more lovely!

 

[New Coleco RGB board?]

I'm afraid it might be your fate to remind me that it can't generate negative voltages, forever. 😅  A find-and-replace for "0V" to "black level" is almost certainly what I keep intending despite continually mistaking "sync level = -0.3V" when I (probably) mean "sync level = black level - 0.3V... with black=0.3V".  Sorry for the continued source of misinformation.

 

Are the voltages that you mentioned ("+B is about 3V", "Yellow is ~2V", etc.) referring to what's coming from the graphics chip on the B-Y line (maybe after correcting with the scaling and +Y)?  Or did you mean the B in the final RGB output?  For the latter, wouldn't there need to be some voltage on the R and G lines to make yellow?

 

All of my discussion above was for the B output at the end of the RGB conversion, so we may have been talking about two different things.  Sorry again for the confusion!

[New Coleco RGB board?]

Hmm, I hadn't noticed it before, but in doing these back-and-forth comparisons between those images, it looks like the TMS Doc version actually has a little bit of overshoot on all of those first pixels.  (You can see it best on the left edge of each staircase where it's a little brighter than the rest.)

 

Initially I had chalked up these sorts of artifacts to having all of this built on a solderless breadboard with long wires running all over the place.  I wonder how much some final, tiny, actually-soldered board will clean any of this up?

[New Coleco RGB board?]

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.?

[New Coleco RGB board?]

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.

[New Coleco RGB board?]

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!

[New Coleco RGB board?]

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...

[New Coleco RGB board?]

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! 😀

[New Coleco RGB board?]

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! 😄