The NTSC Encoder Thread!

[Segasonicfan]

So I've been doing a lot of work with NTSC encoders these days building a high quality Supergun and weighing the encoder quality to get the finest picture around.  I thought this would be a good place to share some of my info and for some small trouble shooting help.  As we all know the only real contenders in the NTSC arena are the CXA and AD chips, so here are my notes on both:


CXA1645:

-GREAT effective luma trap (pin 17).  I find 40pf cap in series with a 100uH inductor gets the best composite picture.  This is what Sega did in the Saturn and it was spot on (best resolution with lowest cross color)

-S-Video quality is amazing.  The only problem I can find at all is a little bleeding with the reds.  But dot crawl is non-existent and pixels look damn sharp.  Truly impressive.

THE BAD...
-pin 6...sin wave input is a pain in the ass.  I tried using both HC04 and VHC04 (supposively better) but I still get a lot of vertical scaling in the cross color areas (thin lines/boarders).  I noticed this changes when I put pressure on the 4.7M resistor?!?  I've grounded the crystal thouroughly and bypassed the power lines with .01, .1, and 10uf caps.  Still, the oscillations are sparatic....


CXA2075:
-very rare but a (much?) improved CXA1645
-much fewer external components, namely pins 13, 9, etc. are N/C now
-picture supposively much better? (I've never seen one in action)

THE BAD:
said to get very very hot during use and has higher power consumption.

AD724
-NO TLL logic required!  works with a simple 3.57 parallel resonant crystal.  The cap has to be tested and adjusted correctly but this is a very nice feature.

THE BAD: No luma trap.  What was Analog thinking???  It's impossible to get good composite video out of this sucker

AD725:
same as AD724 BUT...

luma trap added and full can crystal input only (TLL logic levels).  

THE BAD:
I found the luma trap VERY ineffective (unlike the CXA1645).  Almost worthless.

the crystal I used gave a picture with pinkish reds....when adjusting the impedance on the RGB inputs I got it back, but I had to compromise with increased Green+Blue.  It just seems this crystal input is very very finicky with coloring.  





I just wanted to compile all this info into one post so it would be easier to talk about these NTSC encoders.  I'd really like to solve the HC04 oscillation problem, any suggestions?  Also, what can people say about compatibility?  I hear the CXA has the best except it doesn't work with Atomiswave?  Post your comments here!

[Segasonicfan]

well, it doesn't seem like anyone cares about this thread...lol.  I do have one piece of updatable information that I already added to the wiki:

I was rumaging through some old Saturn boards and found a MB1645 encoder in one of them.  I pulled the datasheet from offline and....it's even better than the CXA1645 (even though it's a clone).  I haven't tested the output, but it doesn't require all the annoying external crap the CXA1645 does...in fact, it has the same external part count as the 2075, from what I can tell

-Segasonicfan

[viletim!]

I haven't tested the output, but it doesn't require all the annoying external crap the CXA1645 does

The CXA1645 doesn't need much in regard to external parts does it? I don't have data on the 2075 but I do have a board with one on it and it looks like it uses no fewer bits than the 1645 on a PSX board... which is not very many anyway.

You say you're having problems with a crystal oscilator of some kind to generate the subcarrier. Care to share the circuit (can't help otherwise)?

[Segasonicfan]

well I was hoping to get some collaboration on NTSC projects...I thought more hobbiests worked with these (especially for supergun use) but I guess not.  I'm also working on Component encoders at the moment, so mabe that will attract more interest.

The CXA1645 requires a buttload of external parts.  Look at the AD275-274 and you'll see what I mean.  Here's a list of the extra components needed:

pin 6-(optional but recommended) frequency filter for sin wave input: 47pf to ground and 2.2k resistor in series
pin 9-required .1uf cap to ground
pin 10-(optional but recommended) frequency filter for sync input: 5pf to ground and 2.2k resistor in series
pin 13-required 47k and .1uf cap to ground
pin 14-required 10uf cap to ground
pin 17-(optional) luma trap filter, 68uH+27pf cap to ground
pin 18-20k (NTSC) required resistor to ground

The MB1645/2075 have a much smaller external component count because they don't need ANYTHING connect to pins 9,13,14,and 18.  It's a big difference IMO.

As for the crystal oscilator problem...I'm still working on it.   I used this circuit for the hex inverter w/crystal:
http://www.nexusuk.org/projects/rgb2svid/circuit

The crysal I used was a 3.57Mhz though for a NTSC color signal.  Problem is (and I seem to experience this wit ALL the NTSC chips even when using a TTL can) that thin lines/boarders have a vertically-moving rainbow effect.  Tweaking the luma trap helps, but sometimes this gets really bad.  Here's the REALLY weird part about it-

I noticed when pressing my finger on the 4.7M resistor the rainbow moving edge effect stops or changes drastically.  This has nothing to do with the encoder(s) and I have already added the freqency filter.  When I use a TTL can I notice it's even worse(?)  I used a 7805 HIGHLY regulated +5v line to try to help, I added 10pf,.1uf,10uf,.001uf caps to the power line as well as a 100uf and 220uf.  The oscillation is still there (slightly improved) but I can't tell if this is from the increased regulation.  I also tried making the hex inverter/crystal pins as short as possible and grounding them like HELL, even placing a copper grounding sheet over all the pins...

the oscillation rainbow effect is STILL there though.  and this is only in composite output, S-video is perfect.

any ideas (especially the weird resistor changes)??  Kinda stumped but I'll keep working on it.

-Segasonicfan

[viletim!]

I really have any ideas...except that one thing that might be worth a try is to divide the output of your oscillator with a pair of resistors. It states the 1645 datasheet that if the subcarrier is 5Vpp then 'subcarrier distortion' can occur if the duty cycle deviates from 50%. Try reducing it to about 2Vpp.

An oscillator of 4x the subcarrier frequency works best with the AD725 (and 2075 by the looks of it).

[Segasonicfan]

Thanks, I'll try that  Though, oddly enough I tried tapping the subcarrier input from both the Neo Geo CD and a Saturn board....the problem was still there X_X

I think it may have something to do with the Neo Geo MVS RGB signal...b/c when I connected a Genesis to the CXA1645 the composite output was much cleaner.  What's also odd is that it's only really noticeable with composite, the S-video is gorgeous.  I wouldn't care except I need the composite output for when I'm playing away from home :/

Thanks so much for your assistance,

-Segasonicfan

[Segasonicfan]

I talked with D-Lite about this issue (color oscillations in composite) and he says it something that cannot be fixed.  He said RGB lines in other systems go through other things (not just NTSC encoders) to solve this problem.  I wish I knew what other circuitry is required for the RGB lines to display a solid composite picture :/

I solved the AD725/4 problem with the pinkish reds  Turns out the chips are just incapable of proper impedence matching.  The red value is really fussy and you just have to manually adjust it using 500ohm pots on all the RGB lines.  Man that took wayyy too long to find out >_<

-Segasonicfan

[Segasonicfan]

did some more research on the composite problem and I think I found what is needed: a TBC, or Time Base Corrector.  These are pretty painful to build let alone find schematics for (I only found one after a lot of googling) so I can see why people don't implement them.  I assume they are used in gaming consoles although when I connected my NTSC encoders to a Genesis I got the same problem...maybe the TBC has to be connected to BFOut or something?  I'll do more work on this when I get home tonight.

-Segasonicfan

[Drewman21]

TBC's are used alot in video production houses for stablizing video images, screen freezes for image grabs, and ripping out alot of crap from video signals that you are trying to work with.  Never really thought about them being used in game systems but can't see why you couldn't.  The ones we have at my work have composite input and that funky sony digital inputs from sony decks, vcr's 3/4 decks and character generators.  No RGB or other inputs to mess with and they only output composite.  Not sure about building one from scratch because they have ALOT of fine tuneing options that you would miss out one if you were to build a thinned down one.

I hope it helps
:huh:
Drewman21

[viletim!]

You don't need to synchonise (to another video signal) or stabilise your video. Basicaly what you want to do is keep the luma info out of the chroma info. The chroma info is phase modulated on top of the video at 3.58mhz and the video itself spans from 15khz to 10mhz. Perhaps some analog filters on the RGB input lines may help. Maybe a notch filter or lowpass for everything below 3.5mhz.

or am I misunderstanding the problem?

[Segasonicfan]

viletim, that sounds correct.  It's definitely a bad mix of luma and chroma signals because the problem is 99% gone in S-video (which has split chroma and luma of course).  I think you're right about some sort of RGB filter, the sync and TTL input filters definitely didn't do anything :/

any exact circuit you could point me to for a filter?  I'm don't know what a notch filter is, but I've worked with low pass filters before (making audio crossovers).  Thanks for your help, you're definitely far more knowledgeable than anyone else I've come across on this subject.

-Segasonicfan