Abusing the BA6592F as a general purpose encoder

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
Guilty
Posts: 93
Joined: Fri Apr 08, 2016 5:58 pm
Location: California, USA

Abusing the BA6592F as a general purpose encoder

Post by Guilty »

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:

Code: Select all

01 - Pr Out
02 - GND
	03 - PCP? tied to bfp?
04 - SW - power off chip? Tied to VCC in SNES schematics
05 - VCC
06 - Chroma out
07 - Composite out
08 - Combined sync in
	09 - Luma in? connects to 23 indirectly
	10 - Pb in? connects to 24 indirectly
	11 - Pr in? connects to 1 indirectly
12 - Blanking? - 10kOhm to ground in the SNES schematic
	13 - volt c...?
	14 - volt b...? indirectly tied to 13
		15 - volt a...?
		16 - Burst flag pulse?
		17 - pha?
		18 - pdo?
19 - NTSC/Pal switch tied to VCC in SNES schematic
20 - Analog Red in
21 - Analog Green in
22 - Analog Blue in
23 - Luma out
24 - Pb out
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?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Abusing the BA6592F as a general purpose encoder

Post by lidnariq »

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.
User avatar
Guilty
Posts: 93
Joined: Fri Apr 08, 2016 5:58 pm
Location: California, USA

Re: Abusing the BA6592F as a general purpose encoder

Post by Guilty »

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.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Abusing the BA6592F as a general purpose encoder

Post by lidnariq »

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)
User avatar
Guilty
Posts: 93
Joined: Fri Apr 08, 2016 5:58 pm
Location: California, USA

Re: Abusing the BA6592F as a general purpose encoder

Post by Guilty »

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.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Abusing the BA6592F as a general purpose encoder

Post by lidnariq »

Guilty wrote:Ah, so the Pedestal is the 40 ire from the sync pit up to black (0 ire)?
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
the sync is ALL OVER THE PLACE to say the least.
that sounds like your scope is failing to sync...
I am not sure how to identify the voltages at each horizontal line of my scope.
"real" oscilloscopes control the vertical scale and tell you the "Volts/div", where a "div[ision]" is the spacing between between horizontal lines.
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.
Well, try adding pullups and/or pulldowns on the analog inputs?
User avatar
Guilty
Posts: 93
Joined: Fri Apr 08, 2016 5:58 pm
Location: California, USA

Re: Abusing the BA6592F as a general purpose encoder

Post by Guilty »

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.
Last edited by Guilty on Sun Jul 09, 2017 4:22 pm, edited 1 time in total.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Abusing the BA6592F as a general purpose encoder

Post by lidnariq »

Guilty wrote: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!)
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.
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.
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.
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?
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)
User avatar
Guilty
Posts: 93
Joined: Fri Apr 08, 2016 5:58 pm
Location: California, USA

Re: Abusing the BA6592F as a general purpose encoder

Post by Guilty »

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.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Abusing the BA6592F as a general purpose encoder

Post by lidnariq »

Guilty wrote:Some of that went over my head. I assume that 5Vpp means 5Volts from Peak to Peak.
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).
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).
So, looking at the actual contents of the datasheet...

The datasheet says that the SYNC input looks like:

Code: Select all

                    +--- somewhere
SYNC ---R2---+----|<
             |      |
            R3     gnd
             |
            gnd
R2=15kΩ ; R3 = 10kΩ
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: ???
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).
1.5V is perfectly safe.
User avatar
Guilty
Posts: 93
Joined: Fri Apr 08, 2016 5:58 pm
Location: California, USA

Re: Abusing the BA6592F as a general purpose encoder

Post by Guilty »

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.
User avatar
Guilty
Posts: 93
Joined: Fri Apr 08, 2016 5:58 pm
Location: California, USA

Re: Abusing the BA6592F as a general purpose encoder

Post by Guilty »

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!
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Abusing the BA6592F as a general purpose encoder

Post by lidnariq »

Guilty wrote: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.
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.
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.
http://www.linear.com/solutions/1316

Not certain it's actually the right solution for you.
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.
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.
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.
Well, the Pedestal happens once on every scanline, so ... it could be a place that hsync goes.
User avatar
Guilty
Posts: 93
Joined: Fri Apr 08, 2016 5:58 pm
Location: California, USA

Re: Abusing the BA6592F as a general purpose encoder

Post by Guilty »

lidnariq wrote: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.
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.
http://www.linear.com/solutions/1316

Not certain it's actually the right solution for you.
Might not be, but I'll read about it anyways.
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.
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.
Well, the Pedestal happens once on every scanline, so ... it could be a place that hsync goes.
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.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Abusing the BA6592F as a general purpose encoder

Post by lidnariq »

Guilty wrote:This is the kind of thing my cable length effects? Interesting.
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 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 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")
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.
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.
Post Reply