Jump to content
IGNORED

New Coleco RGB board?


SiLic0ne t0aD

Recommended Posts

5 hours ago, Falonn said:

Isn't 5V/(470Ω+75Ω) still about 9.2mA?  That's close to twice what the LM1881 is rated to supply out of pin 1.

 

Would running it into some tiny CMOS switch (connected to 5V) solve the problem?

Good point.  Though I'm surprised it has so little output capability.  Well, you could use an NPN transistor.  Collector to +5V, emitter to 385-ohm resistor since you'll lose a little bit of voltage from the transistor.  385-ohm resistor to SYNC output.  Throw a 3K resistor between base and LM1881 to keep it honest, though hRE should be fine without a resistor at all.  This should give you close to the required voltage without taxing the 1881.

  • Thanks 1
Link to comment
Share on other sites

That will work, thanks!

 

I was trying to think of creative ways to keep the same part count and remembered that one of the muxes was being used equivalently to a 4066B with one channel left over.  That last free channel would have done the trick, too, but while comparing the two datasheets just now to see just how similar their characteristics were, it looked like the on-state resistance was an order of magnitude higher on the 4066B and I didn't want to mess around with the (now lovely) video signals any more at this point.  A single discrete transistor and an extra resistor will do just fine.  (It sounds like that 3k has a lot of wiggle room.  I'll pick the next closest existing resistor value to save a line item in the BOM.)

 

That's problem #1 tackled.

 

I spent the rest of my evening doing math.  I've now got a new set of resistor values for all the op-amps that checks out perfectly for all 15 colors to output at 0.7V (well, 1.4V) levels in my Excel sheet, in my color simulator app, and in a Falstad simulation of the op-amps themselves.  They all agree to four significant digits, but I ran out of time to actually swap them into the breadboard.  Tomorrow!

 

In the meantime, I made the most satisfying discovery!  I've been bellyaching about YUV vs. YPbPr for pages now.  It started from the equations on this page where they list them separately with different coefficients.  But!  They're also listed with different input ranges.  And after a bunch of nonsense in Matlab while comparing the two, when the eventual matrices finally shook out after scaling the VDP's voltages to each input range... they're absolutely identical!  So now I can stop worrying about which is "correct".  They both are!  And I've got one matrix to rule them all. :D

 

Assuming the live resistors match the triple-checked theoretical numbers, that's problem #2 solved!

 

With any luck, my next post will have beautiful images.

  • Thanks 1
Link to comment
Share on other sites

Ha!  I get to claim victory... sort of.

 

final.jpg.2d029b648c666994be4cdee0ea5f0e71.jpg

[Popeye through ELM with the new YPbPr color matrix, into the OSSC 1.6's SCART input, captured via the Elgato HD60]

 

That's delightful (save for the hopefully-just-breadboard vertical line artifacts).  It looks great on the TV and from the capture card.  By playing with the ratios, I was able to find plain, E24 series resistor values for all the op-amps while losing less than 1% accuracy.  Even better, the color bar test comes out nearly identical to three different emulators:

 

PaletteComparisonFaded.thumb.png.790ceb1188abe948cbb8f7f93444f7ab.png

 

The top two lines are closer than I could have asked for.  I'm not sure why the Framemeister removes the orange from the orangey reds, but it looks like the CoolCV emulator based their palette on something similar.

 

Now for the "sort of" part:

 

Today was also coincidentally the day my long-overdue package finally arrived: the only device I could find that seemed willing to output RF in a different format.  That at least got it to VGA and the OSSC took it the rest of the way to HDMI so I could grab a frame from my capture device.

 

This is very different!  (Don't mind the artifacts; we're here for the color.  The ADC in the tuner didn't do a great job... although, who can blame them when the source is RF?!)

 

RF-OSSC-small.jpg.29049178e067041dadafa65e95373140.jpg

[Popeye straight out of the Colecovision's RF jack (through an RF-to-VGA adapter, into the OSSC 1.6, captured via the Elgato HD60)]

 

Super vivid.  Super saturated.

 

There's at least one emulator that tries for the same style, but even the "scaled up to full brightness" version doesn't make it very close:

 

PaletteComparisonVivid.thumb.png.894ce6731853d560cffa9fedc4f5534b.png

 

(On the TV it wasn't exactly the same as through the capture device, but nearly.  At least those first two greens were a little more easily distinguished.)

 

I suppose I understand that "real" RGB necessarily looks differently than the NTSC'ified image on the other end.  When I was first learning about RGB and how much nicer it could look than composite, this particular comparison image stood out:

 

photo1549938168.thumb.jpg.5f842b9e87fc98ee93d368a007c36226.jpg

 

Not because of how much sharper the pixels were, but because of how different the colors were.

 

Maybe RF is "wrong" and YPbPr is "right"?  Maybe the artists saw the "right" version while they were developing our games and we just had to suffer through the "wrong" output from our TVs?

 

I'd feel a little weird about making that decision for people.  So now I'm wondering: it should only take a few hours to try and math-out a different color matrix to try and hit the "RF palette".  When all of this finally gets published the right way, it would (hopefully) just be the difference between ~16 alternative resistor values listed in the BOM using the exact same PCB.  Maybe it would be worth it to let the user choose which colors they're happier with?  What do you guys think?

 

When I look at just how yellow that bright yellow is in the RF color bars, I kind of want to see that in my games. :D

  • Like 2
Link to comment
Share on other sites

With most of those colors at 100% output level in at least one channel (which implies clipping, which means it's not a linear function anymore), it'll be a little trickier to reverse.

 

I also wonder if that means we'd need some sort of 1.4V hard clipper/limiter tacked onto the outputs.  The alternative would be to play it fast and loose and output out-of-spec signals and hope the TV or whatever can handle it.  That's not a great alternative. ;)

Link to comment
Share on other sites

26 minutes ago, videofx said:

I am just joining the conversation. Is there something available I can buy to get RGB on my Adam?

I posted a summary in your other topic.

 

Otherwise, I'm probably overdue here for an update:  I have good news (for all of you) and bad news (for me). :D

 

Those vertical lines in the ELM screenshots were bothering me more each day, so I decided to track the source down.  At first I said that they came and went, but in reviewing my various screenshots I noticed that they really just arrived and never went away.  The first few ELM screenshots are perfectly clean.  Then, around the evening I got the MCU up and running, they seem to have appeared and persisted since.  They're always in the same place, absolutely rock solid (relative to the video clock), and unchanging in intensity.

 

With the color bar test cart running, there are literally no components on the breadboard running at a per-pixel frequency, (only per-16-pixels)... so it left me scratching my head as to what might be going on.

 

I eventually disconnected everything and just probed the VDP pins directly... and found the exact same ~100mV steady/synchronized noise pattern on all the outputs.  So the good news is that the current version of the ELM circuit most-likely outputs perfectly clean video.  The bad news is that I think my Colecovision is dying!  Hopefully it's unrelated to all this testing.  This is definitely the most use this console has seen in 35 years, so I'd like to believe it's just wear/age-related.

 

Diagnostics steps taken since then: this system was overdue for a re-capping, so I removed the RF board and replaced the six or so electrolytics.  With the RF board still removed (I worry I'm changing too many variables at once), the noise is down to maybe half the level it was before.

 

I've got a 5V RAM kit from Console5, but I wanted to hold off on that as long as I could so all of this RGB testing was done on a "stock" console.  Instead, I ordered a couple replacement 9928A's from eBay.  I'll add a socket and try swapping the VDP out.

 

On the RGB front: I was reading this RetroTINK blog post and saw "the LMH1251 even took care of removing the sync signals from the output lines. This is great, because I was about to implement a discrete one..." and then I couldn't help myself.  If there is a way to remove the MCU-programming requirement for end users, get rid of the pulses, and something like 80% of the passives in one fell swoop (with no -5V rail required, etc.), it's too good to pass up!  I had already soldered an LMH1251 to a little adapter board a couple weeks ago, so I got it on a breadboard last night and connected some things.

 

It doesn't have enough drive to output a 75-ohm video signal and I haven't gotten the THS7374 video amp on the board yet to actually see the output, but from the scope I can see it's doing something that looks vaguely correct.

 

Notes:

  • It neatly holds all three output lines at black during blanking.
  • It does NOT suppress the color burst. ?
  • It does all of its work with a 1-2V'ish DC bias.
  • The sync output is split up on this chip for separate H- and V-sync but the V-sync line never changes.

I'm guessing that last one is the 480p-minimum support mentioned in the datasheet.  That's fine--we need C-sync anyway--so tacking an LM1881 on the board "solves" what is already a non-issue.  Besides, we'll need the burst pin to do something like Hackaday's sample-and-hold to eliminate the burst, so it's double-useful.

 

Now I just need to get the video output amp running, confirm the output looks reasonable (presumably with too-much-blue), and then try for the sample-and-hold, applied to B-Y and R-Y during burst, with what I'm hoping can be accomplished with a single mux.  Then we'll have a 5th data point.

 

... I just hope I can fix my console's video output in the meantime.

Link to comment
Share on other sites

Well that was a quick turn-around!

 

The LMH1251+THS7374 (with an LM1881 + TL081 sample-and-hold + mux to remove the color burst) works beautifully.

 

At first it had seemed to amplify the noise from my failing console and give the worst picture I'd seen yet.  Then I decided to try enabling the low-pass-filter built into the THS7374.  As a rule I try to avoid that sort of post-processing, but in this case... magic.

 

1433312498_palette-LMH1251FMnofilter.thumb.png.6cb3b322eeade9544e2eb3198f2d3858.png  <-- without LPF / with LPF --> 1577290531_palette-LMH1251FMw-filter!.thumb.png.362707063ed6aa3f0e8e4b4b64ad7ebc.png

 

Just absolutely crisp, like an emulator screenshot (even with all that noise under the hood):

 

1572624463_LMH1251Framemeister(LPF).thumb.png.d6d2c201f7af4d7644975733990afb37.png

 

The colors are still over-driven (almost like the RF output :D ), but that's because the CV's voltages are out of spec for the LMH1251.  CV outputs 1.0V white and -4.7V sync.  LMH1251 expects 0.7V white and -0.3V sync.

 

There's already a 390Ω to ground on each of the Y, B-Y, and R-Y pins on the CV board.  I wonder if we couldn't just use a simple resistor divider to get the scaling factors for each line?  It'd be cool to do it with three tiny passives instead of adding a set of op-amps just for normalization.  I'll play with that (and a few other things) tomorrow.

 

So this version means: no -5V rail, no MCU programmer required, and the entire board is practically just 5 small ICs and a smattering of power bypass caps. :)

 

In the meantime, the most important task (now that board layout is nearly imminent): this project needs a name!

 

ColecoRGB would have been great, but it's already taken.  I've been thinking about "TMS-RGB".

 

Pros: It's less of a mouthful than "TMS992xA-RGB".  It avoids any sort of Colecovision trademark issues.  It implies broader compatibility (say, with the MSX or Adam) than just Colecovision.

 

Cons: "TMS" isn't particularly notable.  You have to be a hardware person before you know what it refers to.

 

Any other suggestions?

  • Like 1
Link to comment
Share on other sites

3 hours ago, Falonn said:

Well that was a quick turn-around!

 

The LMH1251+THS7374 (with an LM1881 + TL081 sample-and-hold + mux to remove the color burst) works beautifully.

 

At first it had seemed to amplify the noise from my failing console and give the worst picture I'd seen yet.  Then I decided to try enabling the low-pass-filter built into the THS7374.  As a rule I try to avoid that sort of post-processing, but in this case... magic.

 

1433312498_palette-LMH1251FMnofilter.thumb.png.6cb3b322eeade9544e2eb3198f2d3858.png  <-- without LPF / with LPF --> 1577290531_palette-LMH1251FMw-filter!.thumb.png.362707063ed6aa3f0e8e4b4b64ad7ebc.png

 

Just absolutely crisp, like an emulator screenshot (even with all that noise under the hood):

 

1572624463_LMH1251Framemeister(LPF).thumb.png.d6d2c201f7af4d7644975733990afb37.png

 

The colors are still over-driven (almost like the RF output :D ), but that's because the CV's voltages are out of spec for the LMH1251.  CV outputs 1.0V white and -4.7V sync.  LMH1251 expects 0.7V white and -0.3V sync.

 

There's already a 390Ω to ground on each of the Y, B-Y, and R-Y pins on the CV board.  I wonder if we couldn't just use a simple resistor divider to get the scaling factors for each line?  It'd be cool to do it with three tiny passives instead of adding a set of op-amps just for normalization.  I'll play with that (and a few other things) tomorrow.

 

So this version means: no -5V rail, no MCU programmer required, and the entire board is practically just 5 small ICs and a smattering of power bypass caps. :)

 

In the meantime, the most important task (now that board layout is nearly imminent): this project needs a name!

 

ColecoRGB would have been great, but it's already taken.  I've been thinking about "TMS-RGB".

 

Pros: It's less of a mouthful than "TMS992xA-RGB".  It avoids any sort of Colecovision trademark issues.  It implies broader compatibility (say, with the MSX or Adam) than just Colecovision.

 

Cons: "TMS" isn't particularly notable.  You have to be a hardware person before you know what it refers to.

 

Any other suggestions?

 

ColecoColor or Coleco SuperRGB or Coleco SuperColor or ColecoRGB Max or ColecoColor Max

Edited by videofx
add on
Link to comment
Share on other sites

4 hours ago, Falonn said:

At first it had seemed to amplify the noise from my failing console and give the worst picture I'd seen yet.  Then I decided to try enabling the low-pass-filter built into the THS7374.  As a rule I try to avoid that sort of post-processing, but in this case... magic.

Don't forget that you are dealing with signals considered very very high speed for protoboards.

On a properly routed PCB, you will get even better results with or without the (to be enabled anyway in this use case) LPF.

Edited by emmanuelf
Link to comment
Share on other sites

"Breadboard effects" was my theory, too, because each of these circuits has slowly been moving up to faster op-amps.  But then I went back and tried one of the first breadboards (that used to be perfectly clear a couple weeks ago) and the vertical lines were still there.  Something has definitely changed in the interim... I'm just not sure what.

 

I spotted in the service manual "Vertical Lines: Vertical lines on background rather than solid blue background with no lines? Replace C106."

 

C106 is just the (tantalum) power supply bypass cap on the TMS9928A, but I was going to give it a shot to see if it helps.  If it's not doing its job anymore for whatever reason, I could see the VDP getting starved for current which might cause something like that.

 

That said, you are absolutely correct that a PCB should go a long way toward solving more of the problem, especially with that LPF!

Link to comment
Share on other sites

The jail bars can always be the result of stray signals.  When you're dealing with analog at less than 1V, clock signals or other fast-changing signals radiated around will be picked up.  The most steady (such as clock lines) will show up as a pattern.  The main clock line is of course the 3.58MHz CPU/color modulation source.  There is also a 10.7MHz (3.58*3) resonator that clocks the TMS.  It outputs a division of that clock on one pin, though the Coleco doesn't connect to it.  The TMS also regularly outputs RAS refreshes on its DRAM, while also sending out reads while constructing its output frames.  So even routing of your wires that tap off of the analog outputs will make a difference in what gets picked up.  Try moving them around to see if you can at least manipulate the strength of the jail bars.

  • Like 1
Link to comment
Share on other sites

2 minutes ago, Jboner1058 said:

This should work for the TI99 also like all the other rgb boards do right?

The TI uses the 9918A which outputs a composite video, rather than the almost-component of the 9928. You COULD swap the VDP out, I've done this on a TI and it works.

 

  • Like 1
Link to comment
Share on other sites

Alright, this is nearly there.  Lots of little refinements:

 

1297659287_TMS-RGBpre1.thumb.jpg.ec59fdbeebe45970e58fea248d63d91d.jpg

 

I didn't need one of the THS7374 channels, so I swapped it for a '7314.  Using the LM1881 datasheet default of 680k for the Rset resistor makes the burst signal last into the CV's border color.  Dropping it anywhere between 560k and 600k splits the difference nicely between the end of the color burst and the start of the color border.  That will be safer.

 

With the extra 2x from the output amp, we're in a new position of needing to attenuate the signals instead of amplify them: CV outputs 1.0 black-to-white Y, but LMH1251 is spec'd for 0.7V.  So I added a set of voltage followers for each channel so we could sneak a divider network in there.  Without the buffers, the output resistance from the mux was making things challenging/unpredictable.  And putting any kind of load through the mux was causing big spikes on the transitions.  (Using higher-value resistors to reduce the load also caused smearing in the image like Hackaday!  So I get to take advantage of the voltage follower's output current and use nice, low resistor values to solve both problems.  We're talkin' 1V signals here, so it's still only like 1mA.)

 

Using a four channel amp means we can just collapse the sample-and-hold amp into the same IC, so we don't need to add anything to the board; just increase the pin count by a couple.

 

Still to-do:

 

1. With those resistor values, all the output colors are officially in-spec (0.7V white after the 75ohms) now.  This is through the Framemeister:

 

486669656_TMS-RGB1.thumb.png.c77bcb1f6959b55e3e323241c2cfb319.png

But curiously, the RGB value coming through the capture device for white is around 230 (out of 255) on each channel.  That's only 90%, which makes it feel like the Framemeister is expecting something closer to 0.8V before it will show things fully saturated.  I'll probably leave them alone (it looks just fine on the TV), but include a bonus/alternate recommendation in the BOM for brighter colors.

 

2. The 74LVC2G17 is a tiny, 6-pin dual-Schmitt trigger that can solve two problems at once: alleviate the output current of pin 1 on the LM1881 and give the pin 5 burst output a much sharper corner.  It's got plenty of output capacity for the former and is designed for the latter.  That saves a resistor (and its board space) vs. the discrete transistor solution for LM1881 pin 1.  I'm fairly confident this will work on the first try, but I don't have any of these on-hand yet.

 

3. You have to look hard, but you can see the slightest front edge on the transitions from black to other colors.  Checking it out on the scope, Y predictably leads B-Y and R-Y by about 15ns because it doesn't go through the mux.  I'm thinking of "needlessly" passing Y through the third channel (instead of the sample-and-hold) to level out the propagation delay.  All we'd need is a little replacement SPST analog switch (say, the 74LVC1G66) for the sample-and-hold and the picture should essentially be perfect.

  • Like 3
Link to comment
Share on other sites

Aside from passing Y through the 4053, the only other changes will be values?

In which case I will start on the schematic capture and PCB layout. 

Do you think this is evolved enough for me to start IC shopping?

Link to comment
Share on other sites

Quote

I didn't need one of the THS7374 channels, so I swapped it for a '7314.

Not good. You need the same buffering for CSYNC as for R/G/B. THS7374 give you a complete coherent interfacing with the display device RGB/Scart interface. CSYNC is subject to the same double 75ohm impedance matching (150ohm) see p26 of THS7374 data-sheet. Without, in real condition you will go into trouble with CSYNC at one time or another.

Otherwise, good job!

 

PS: why using followers and dividers instead of proper gain on each channel ? Ac coupling and "high"/not low impedance output on the coupling is not ideal.

Edited by emmanuelf
Question
Link to comment
Share on other sites

7 hours ago, MrPix said:

Do you think this is evolved enough for me to start IC shopping?

It feels very close, but I've been surprised during this process (like ten times now, hehe), so I will leave that gamble up to you. :D  My DigiKey order with what should be the last of the prototyping parts is supposed to be here on the 9th.  I should know more after that.

 

8 hours ago, MrPix said:

... the only other changes will be values?

And hopefully just the addition of those two small 74LVC' parts I mentioned above.  But again, every time I think I'm finally getting the hang of this, the scope shows me that I missed half a dozen important details.

 

4 hours ago, emmanuelf said:

Without, in real condition you will go into trouble with CSYNC at one time or another.

Avoiding the buffer for CSYNC was intentional.  Right now the eventual PCB will be able to target two different output connections.  As-drawn, it works with the "plain" miniDIN-8 to SCART cable (with no internal components except the pull-up on the enable-RGB pin).  But if you switch the three 75Ω and the 470Ω output resistors to 0Ω jumpers (or just solder bridge them), it will also work with all the Sega Genesis 2 miniDIN-9 to RGB SCART cables out there (which already have the 75's and 470 right in the cable).

 

So maintaining the ability to optionally output TTL-level CSYNC was on my requirements list.  If I had dropped the sync voltage before running it through the 4th channel of the '7374, we would need to route a separate pad for TTL CSYNC, which would have added a trap (using the wrong sync output) to the installation instructions.  As-is, the instructions are simple: "DIN-8: use these four resistors.  DIN-9: use jumpers instead".  I like that.  Less room for error.

 

The range of valid sync voltages in the SCART spec is super wide: "0.3V (-3 dB, +10dB)", which ends up like 0.21V to 0.95V, right?  It seems like they intentionally included a lot of wiggle room for situations like these.  Using the LM1881's output through a Schmitt trigger---just for the extra output drive because it's already on the board---seems like the best case scenario for a clean signal.  I've heard horror stories in the past about sync not working, but they seemed to usually involve an already-weak sync-on-Luma signal or something like that.

 

4 hours ago, emmanuelf said:

PS: why using followers and dividers instead of proper gain on each channel ?

The "gain" on all three channels is less than 1.0.  It could be done on the inverting side, but then you'd need another set of amps to invert it again, right?

 

5 hours ago, emmanuelf said:

Ac coupling and "high"/not low impedance output on the coupling is not ideal.

Putting it anywhere else caused more trouble.  Between the mux and the amps caused spikes on the mux's transitions.  Before the mux or without the amps caused smearing.  I agree it's not ideal but it feels like it'd be silly to add another stage of voltage followers to drop the impedance when the output is already looking/measuring perfect.

  • Like 1
Link to comment
Share on other sites

You should be able to put the divider before the aop without disturbing mux transitions if you choose a high to ground value.

 

For the rest, ok I understand your use-case.

On my side I'm only interested in pure standard connection. These sega cables are pure hack I don't like, proper driver/buffering is the base. These special purpose driver are immune to short circuit, to esd, specialy designed to drive 75ohm imputs etc...

All other things could/are working, but are not as clean/robust and able to face all the diversity of real conditions.

But this is a personal point of view that I understand some will disagree with, especially from a DIY/Hobby/Hacking perspective.

Link to comment
Share on other sites

22 hours ago, emmanuelf said:

... immune to short circuit, to esd, specially designed to drive 75ohm inputs etc...

Those do sound like nice features.  Maybe having both outputs on the board would be the lesser of two evils after all?  I'll try to get the THS7374 swapped back in with an extra tap from somewhere earlier in the circuit for those people that want/need TTL CSYNC for whatever reason.

 

 

In the meantime, while doing more extensive testing (finally it's not the same screenshot!), I spotted some strange behavior in level 3 of Popeye:

 

492431967_TMS-RGBpost-blackcapture.thumb.png.38fcea680e66fb05db85727b163f172f.png

 

Take a look at the right-hand side of the screen, just after each of the long black platforms.  There is a long sort of color "smear" just after a transition from a line that is mostly solid black to a bright color.  If you look very closely, it even continues recovering all the way on the next line (at the far left) after each one.

 

I wanted to see if this was just a VDP thing, but right now I've got the RF board removed from my test CV.  I tried it via RF on a different CV, but it either doesn't happen there or it's so slight that the normal warbling in the RF picture is enough to hide it.

 

Zooming into the right side of the screen on line 89 (Olive's platform at the top), it looks like this:

 

close-up.jpg.e42bbec035d97315e7b0fe54dba5efe8.jpg

 

It's tricky to capture just that on the scope (notably: it takes 5+ minutes to get to level three, you can't pause the game, and the game over screen only lasts about 30 seconds so you have to play simultaneously while adjusting the scope :D ), but here it is at the input (straight off the VDP pins) and the output (after the 75ohm resistors):

 

1333776066_TMS-RGBpost-blacksmear4(UVY).thumb.png.7b7899cc304045b1e084598ae2ba0171.png 570165253_TMS-RGBpost-blacksmear3(BRG).thumb.png.356bc1d0c151e2c1408cd482885cb408.png

 

You can see a 70mV or so decline (especially on R) in the output.  It's sort of there on the inputs if more subtle (and the noise certainly doesn't help).  That was what made me wonder if it showed up over RF... but testing it against a completely different chip doesn't feel like a good comparison.

 

So, is this a known issue for (old/poor/failing) 9928A chips?  Or do we have a problem in the RGB converter that can be addressed?

 

My instinct wants to say some capacitor somewhere either isn't getting charged enough or is getting too much time to charge.  It's just a question of whether that capacitor is on the CV board or this board, hehe.

 

Any ideas?  Thanks!

Link to comment
Share on other sites

Is there a way the game could instruct the TMS to output an off-violet?  That isn't one of the colors in the palette and the artifact already looks different at the left side than it does the right side (hence the slight downhill angle on the R line in that scope trace).

 

You're right that a custom program is the right answer to fully characterize the problem.  Then we could check the transition between black and each color instead of just that bright blue.

Link to comment
Share on other sites

Hey this all looks fantastic! 

 

This may sound strange considering RGB's superiority to it, but is there a chance this could help with a (true) s-video out for the CV?  With my setup, S-video is the best I can do, and even with a (very nice) composite modded cv, there is still some blurriness on some games with small text.   

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...