Abusing the BA6592F as a general purpose encoder

Hi all. Not sure if this is an appropriate place for this discussion, and I'm okay if this is moved to a better spot.

I've been trying since New Year's to make a general-purpose RGB>YPbPr encoder (and hopefully refining the result to also output S-Video and Composite) with basically no usable results. The end goal here is to have a small and simple circuit board that I could build into various consoles or into plug-and-play dongles to get my YPbPr CRT working with the Dreamcast, PS1, a PC that I built to be a console-ized arcade emulator and what have you.

My most recent attempt focuses on the Snes' encoder, the S-ENC or BA6592F. I've found this schematic and I've been working from it, but I'm getting absolutely no picture from it. I've seen a few people talk about it here and I was hoping that someone could tell me what I need to do to this chip to get it to work.

Right now my setup is
Composite sync from Dreamcast > 22uF capacitor (remove DC coupling) > 75Ohm pulldown resistor > pin 8
+5V from the Dreamcast > 0.047uF capacitor to ground > 10uF capacitor to ground > pin 5
Ground from Dreamcast > pin 2

And if I understand at all how this thing works, I should get an empty sync signal out of pin 23. But instead, I get a very flat 1.4ish volts out of pin 23. Now, there is a lot of pins on this chip that I don't at all understand. Here's what I've got out of it:


And the schematic that I draw these guesses from.

I've tried a few other configurations by tying VCC to a few different pins but none of it seems to have effect on my Luma line. Does anyone here have any experience with this thing?

The japanese-language datasheet for the BA6592F can be found without too much difficulty...
italics for translated bits

3: PCP | PCP input | Pedestal Clamp Pulse (negative logic)
4: SW | switch | fixed to H
9: YI | Luminance signal input | Luminance signal input
10: (B-Y)I | | color difference signal input | EB-EY signal input
11: (R-Y)I | color difference signal input | ER-EY signal input
12: BLA | Burst Level Adjustment | Semi-fixed resistor connection for color burst signal amplitude adjustment
13: VC | VCXO input | VCXO delay phase input
14: VB | VCXO input | VCXO input
15: VA | VCXO output | VCXO output
16: BFP | BFP input | Burst Flag Pulse input (negative logic)
17: PHA | APC adjustment | Semi-fixed resistor connection for color burst signal phase adjustment
18: PDO | Phase detector output | Connect to the PLL filter

Do you have an oscilloscope? I'd really think you'd have a better time looking at the intermediate signals of the various ones you've already built and figuring out where it's going wrong, rather than trying blindly again and getting random results.

You should be able to get a cheap functioning used 20MHz scope (all you need for standard definition questions) for very cheap from one of the random junk warehouses in the bay area.

Indeed, it can be found with little difficulty! Unfortunately I wasn't able to read much of it. My Japanese is limited to kana and only the simplest of phrases. I have a scope as well, an Xprotolab-plain that was a gift, and it's been really useful so far.

That being said, even after reading your translations I have basically no idea what any of those pins do, but at least now they're in terms I can research more.

I've been trying to learn, er, anything about how Burst Flag Pulse works. I can't find anything very informative about it, it seems to be related to the color information that composite carries on the little space between sync pulses and luma information. I have no idea how to apply any of that though. I've got some 4fsc NTSC crystals that I might be able to build oscillators from but I have no idea if that's even what should be fed to that pin.

Easy question, pin four is SW which is fixed to H. To me that means 'fixed to High' which means 5V. Is that wrong?


...if it's not totally obvious yet, I've got 100% of my electrical knowledge through console mods. I have nearly no idea what I'm doing.

Pedestal: US NTSC difference between blanking and black
Burst Flag: Colorburst should be generated

I don't see an obvious reason why either of these would have anything to do with the component intermediary product, as opposed to just the composite/S-video outputs.

For whatever it's worth, you should be able to
* Use S-video luma interchangeably with Component Y
* Fail to connect S-video chroma, or Component Pr, Pb, and still get identifiable video (without color)

Ah, so the Pedestal is the 40 ire from the sync pit up to black (0 ire)?
And Burst Flag just tells the chip 'currently, we should send out the color bust signal'. Okay.

Yeah, I was hoping that I could just link up R G B and Sync to the chip and at least get Luma out, but no luck with that. I just tried doing it again just now but with switch tied to 5V, and this time I'm certainly getting a Luma signal, but the sync is ALL OVER THE PLACE to say the least. Looking at my scope, it looks like the current output is really high over the center line (I assume that the sync valley needs to dip below that line). I am not sure how to identify the voltages at each horizontal line of my scope. It looks like the sync is most reliable (not very reliable) when we're dealing with very bright, white screens like the Dreamcast startup screen. But on mostly black screens the sync valley quickly fades out of my signal in a way that makes me think it's getting eaten by a capacitor or something. It's very strange. I wonder if my capacitors are of the incorrect voltage or something? I'm using three 35v 220uf caps on the R, G and B outputs from the Dreamcast. I always thought the voltage was irrelevant as long as it's above the voltage you're working at but I can't find any evidence that says yea or nay on that.

7 IRE from blank to black.

NTSC-U only:

• -40 IRE - negative sync tip
• -20 IRE - approximate lower bound of colorburst
• 0 IRE - blanking
• 7 IRE - black
• 20 IRE - approximate upper bound of colorburst
• 100 IRE - white
• 120 IRE - highest permissible instantaneous voltage for an in-gamut color

that sounds like your scope is failing to sync...
"real" oscilloscopes control the vertical scale and tell you the "Volts/div", where a "div[ision]" is the spacing between between horizontal lines.
Well, try adding pullups and/or pulldowns on the analog inputs?

Oh, no I meant that the image onscreen was falling out of sync (or rather, never IN sync). My scope most certainly fails to sync up, because it would appear that my sync pulses aren't actually getting through at all. There certainly seems to be a difference between blanking and black, and I would call it close to 7 IRE, but the sync never actually shows for some reason.

The only thing I have between my sync line and the chip is that 22uF capacitor. Removing or flipping the cap has no effect, nor does pullup/down resistors of any value I tried on my 1kOhm pot.
...The Japanese schematic doesn't specify anything about the composite sync it expects, does it? I ASSUME that it needs to be AC coupled. The sync I'm feeding it is .5 volts peak to peak (which I can identify now, thanks to you!)

Perhaps I should try amplifying the sync signal and see if that has any effect. I can afford to burn a few of these chips, I bought a 'I really wanna figure this out' sized bag of them.

EDIT: Here's something pretty interesting. If I put a pulldown resistor on sync, no effect. If I put a pullup resistor on sync, no effect. BUT; when I remove the pullup resistor from sync, then for just a quarter of a second, the sync valleys appear on the scope before they flatten out again. With my CRT connected it behaves as expected, going from unstable picture to perfectly stable to unstable again. I suspect some kind of cross-bleeding into a capacitor that eats the signal or something?

EDIT2: BAM! So on closer analysis of the luma line I saw the sync dips appear just momentarily when I remove the pullup resistor from the sync line, right? So I thought to analyze the sync line as I add or remove the pull up resistor, and I saw that as I remove the pullup from sync it floats gradually down from 5V to 0V. So what if I keep it at the midway point? So I build a voltage divider and pull up sync to that voltage. Bam, sync valleys on Luma. Okay, we're cooking with gas now. I need to do some more work with the luma line in order to get the picture less washed out, but we're onto something here.

I'd have assumed that bare composite sync should be logic level (i.e. 3 or 5 Vpp), not RS170 level (0.3Vpp)

The Japanese-language datasheet disagrees, though. It explicitly states it expects 0.55Vpp (p2), and the input stage (p8) shows that it's "just" a voltage divider feeding an NPN BJT ...

It looks to me like feeding it logic level should be safe.

The input stage diagram shows that the input impedance of the SYNC pin should be around 15kΩ, so I doubt any normal logic level would damage it.

Well, the CSync input doesn't really have an input biasing stage. With your highpass capacitor there, I wouldn't be surprised if it's just being centered around 0V, below the "on" voltage of the internal BJT.


(P.S. unrelated to all of this ... given how almost-right the discrete transistor RGB-to-YPrPb converter you have is, I'd personally work on getting that closer first)

Some of that went over my head. I assume that 5Vpp means 5Volts from Peak to Peak. If the sheet says it expects .55vpp though, I like that because my sync signal currently sits at 0.5V peak to peak (but apparently the high points need to be at about 1.5V, or so my experimentation has found).

I have a very nebulous understanding of the term impedance and while I can measure the impedance of the sync line leading into the chip I will have next to no knowledge about what to do with that. I will read more about impedance as it effects video signals.

And you are completely correct, my capacitor was centering the sync line at 0V. Putting it up to 1.5V did the trick. Now I must begin to play with the Luma line some more to get the picture less washed out. I also wonder what value of cap I should place on it if I wanted to center the signal around 0V (which I think they're basically supposed to be at? Right now mine is at about 1.5V which I doubt is harmful but my TV is precious to me).

Oh, and, yeah the discrete attempt came pretty close. Basically I moved away from it because I was hoping that trying something else would teach me more about how to fix that one. I was having a lot of difficulty getting the picture to be bright enough and there was some weird capacitance problems causing the screen to gradually darken after going to a bright image.

Right. The reason I said that is that Composite Sync is a yes/no signal. I would naively assume that a signal that was digital (yes/no) would be running as a full-scale signal, going from one rail (in this case, +5V) to the other (ground, 0V).

So, looking at the actual contents of the datasheet...

The datasheet says that the SYNC input looks like:


Assuming the BJT is a "normal" BJT, then it's effectively a diode pointed from the R2/R3 junction to ground. So the voltage there can't ever really get above 0.7V, give or take.

If R2=15k and R3=10k, then those together make a "voltage divider", taking the input voltage and multiplying it by 2/5 (10/(10+15)). The SYNC input has to drive this node to above ≈0.5V before the BJT can even start conducting before the behavior changes. (Undoing the voltage divider, the voltage of SYNC at which this changes is 0.5V*5/2, or 1.25V.

So, super approximately:

SYNC below 1.25V: input is off, all current is just flowing through R3
SYNC above 2.5V: R3 is effectively shorted out by the BJT; effectively all current is flowing through the BJT
in between: ???

1.5V is perfectly safe.

I'm following you! I like what I've got so far. My picture could stand to have slightly better definition in the dark colors, but I'm not sure where to work with that and my experiments haven't taught me much so far so I might work with this for now.

I want to start adding the color difference signals, but nothing is coming out of the pins 1 and 24. I am going to assume that this is similar to the sync predicament and that looking for input information on the datasheet will be my next step, so I'm doing that now.

EDIT: Okay I'm not sure why my scope seems unable to measure the signals coming out of pins 1 and 24 but the TV sure shows them. Okay, I can work with this.

Paging lidnariq! Or anyone else who knows a lot about this chip.

I've been adjusting my circuit and experimenting with things right and left and I think I need to know more about this chip. Specifically the pedestal clamp pulse pin. Let me explain.

My current image is more or less the correct hue and saturation, and very sharp, and I'm very happy about that. However, I'm running into two major problems with it.
The less pressing issue (which I believe has nothing to do with my use of the chip) is that there seems to be some kind of wind-up time when going from black pixels to white pixels. For instance, if I put a blank, white screen up with a black circle in the center, the circle casts a faint shadow that extends off to the right by about half the screen's width. If I put the black circle so close to the edge that the shadow is cut off on the right, it loops onto the left SMB2USA style. I think this has something to do with something called "impedance matching" and I think it's entirely up to me to fix it but if I'm wrong I would love to know about it.
The second, more irritating problem is something that I'm pretty sure you'd call gamma correction. If I adjust the picture to be brighter over all, I get a lot of detail and contrast between dark colors like you would expect from RGB, but the brighter colors blend together and for instance Twelve's default costume in SF3 Third Strike is almost a white silhouette. If I adjust the picture to be darker over all, I get a lot of detail and contrast between bright colors but dark colors just become indistinguishable blackness. I can't have both.
My first impulse is to try and correct this by means of a non-linear-impedance-opamp. I've got no idea where to start with that though.
What I want to know is how the SNES does it. I don't see any kind of gamma correction in the RGB inputs for the encoder on the schematics, so I assume that either the RGB video is already just fine further up the pipe or there's an aspect of the encoder that I'm not taking advantage of.

If I tie PCP to 5V, nothing seems to happen, but if I remove that bridge then for just a split second my darks and light all work together. That makes me think that I need to send a pulse to the PCP pin but the only pulse I have available is H/V/Csynch so before I go nuts with delays I would like to know if I'm on the right track.

...anyone who knows something about this chip, anything you have to say is valued. Even if it's just a new set of words I can google with. Thank you!

Sounds like it, specifically reflections due to impedance mismatch.

The easiest way to make sure is to use a different length of cable to connect it... but I have to admit that I'm surprised you're seeing tens of microseconds of echo.

http://www.linear.com/solutions/1316

Not certain it's actually the right solution for you.

Both VGA and the SNES emit video in a linear sense, and expect the CRT itself to apply the only gamma correction at all. Without more information about the specific source you're testing against, it's hard to say whether that's related.

Both TV (SNES) and VGA expect a gamma near 2.2, so you shouldn't be seeing this kind of radically wrong results here.

If you are using a PC source, you probably can find a knob in your graphics card drivers to adjust the gamma.

Well, the Pedestal happens once on every scanline, so ... it could be a place that hsync goes.

This is the kind of thing my cable length effects? Interesting. I happen to be running the signal through about a 3 foot cable that goes into an analog video switch I built and then through another 3 feet of wire before getting to the CRT, but that makes no difference to my other video sources. Will experiment anyways.


Might not be, but I'll read about it anyways.


I am in fact using VGA. I might try hunting around in the drivers to adjust the gamma, but I expect it not to have this option. CRT Emudriver might be amazing but it's still made by just one guy.


I knew that it happens on every scanline, so I tried connecting Csync to it (theoretically the only difference is that it's got the Hsync pulses, which shouldn't do anything because the laser is deactivated for so long or at least that's how I see it) but no luck. It has the same effect as tying it to 5V.

Reading about video pedestals and looking at the timing chart in the datasheet I can see that I need to send the PCP a little after Hsync, and it has to not last quite as long. I have no exact timings though so once I figure out a way to delay and shorten the pulse I'll probably have to put it on some kind of adjustable factor.

Now, because the SNES works at a weird aspect ratio I don't know if this is a good idea or not, but I'm thinking about hooking up my scope to the encoder inside of a working SNES and just watching whatever happens. Maybe I'll see something enlightening on the PCP pin. Maybe the extra impedance will jack something up. I don't know.

If it's actually a reflection, yes, it's a function of the speed of electrons in the wire. That's usually around 1/3 the speed of light, give or take.

In the "shitty cables on VGA" days with a pixel clock of 100MHz (→10ns), a reflection of 100ns was both relatively easy to achieve and very noticeable. But ... getting a reflection ≈20µs later makes it much less likely—that should be kilometers of wire, not just a meter.

I know the Windows Intel and ATI drivers have it, as a monitor calibration option. I expect everything does. (Linux can use either "xrandr" or "xcalib")

No need to 'scope it, we have jwdonal's redrawn schematics. /BURST from PPU2 is tied to both /PCP and /BFP.

/BURST should be low during the colorburst, which is a time that—in the absense of Macrovision—should be 0 IRE on average. So a delayed copy of /HSYNC that's only true during some subset of the "breezeway", colorburst, and "back porch" would be the signal you'd want.

Isn't all of that time just a little shorter than the sync pulse? I'll have to mess around with this once I get some kind of variable delay working.

I just thought to mention that when my near-black colors are not coming up on screen they are still visible on the scope. It looks like my blanking up to black is not the IRE value we were talking about before. In fact it looks like my black video sits at the blanking level. This seems like a key factor in the problem. Maybe there's a different way for me to stage inputs.

To the best of my memory, they're both ≈4.7µs?

Not to the severity you're talking about...

Then I'm off to dick with timing delays then! Thanks again lid. Good talk, see you again in another month or so.

EDIT: Oof, I really hope this delay thing pans out because if the PCP clamp doesn't fix my contrast problem then solving it through gamma correction is surprisingly expensive. At least through the only way I've found so far.