Converting 15kHz analog RGB to digital

[miguelvp]

So I got some progress

First I wanted to make sure I could see an image out of the composite output of the SuperScan2 so I programmed the DE0-Nano so it will boot to the VGA pattern posted earlier, power it with the TV USB (Service) plug and feed the Composite input from the converted VGA to NTSC.


Then I took it back to my office and started to probe the FIFO chips.

The Write Clock WCK runs at 25.125MHz, this is what is used to store the data from the 6 bit per color ADC chip into the FIFOs.



The Read Clock RCK runs at 12.690MHz, a bit faster than half of the Write clock.



The reason for this is that the Write Enable is double buffered so it writes half to the odd chips and the other half to the even chips.



The SuperScan2 specs talk about 32bit color, but it really only supports 5/6/5. The ADC is only 6bits per color and they don't use R0 and B0, only the Green channel uses all 6 bits, making it a 16 bit decoder.Now since they double buffered it, it really is using 32bits, tricky bastards.



The output buffer (above the top inputs and below the bottom inputs) are read at half the frame rate all four chips at the same time, so the odd chips will have the odd field and the even chips will have the other half of the data.

This is what DO1 (Half of R2 output) looks like in a single frame at 60Hz



This is a closeup of a single line of DO1 (Half of R2 output) so it flips 16 times for every 256 analog outputs (what you are seeing there is 640 so 256+256+128)



Looking at the green channel that uses all 6 bits, cycling from 0 to 255 will cause the inputs to flip these many times per color bit.

G5 2  times
G4 4  times
G3 8  times
G2 16 times
G1 32 times
G0 64 times

Now I have some soldering to do. Not sure if I'm going to solder directly in the inputs or the outputs. Using the inputs I can use only 16 wires for the RGB 5/6/5 Then use the Write Clock (one common pin) and Write Enable for each bank (two pins) The DE0Nano would not have any problems dealing with a 25MHz input clock from the chip. Also I can probably solder R0 and B0 to get the full 18 bits RGB 6/6/6. Total pins used 21. I will have to make sure I use a pin for the Write Clock that supports external clocks.

The sync signals will already be in the FPGA since i'm going to pass the composite as an input (treated as binary) to extract the HSync and the VSync to feed into the SuperScan. It should not add too much delay compared to the original timing. This will add three pins for a total of 24 GPIOs.

If the FPGA adds too much delay then I will have to use the LM1881/74LS221 to get the VSync and HSync by hardware using pin 4 from the Saturn connector to get the 5 volts needed for the chips.

Like this:



Now to solder and write some code for the capture. I think I'm going to just tap into the inputs since the FIFO buffers don't give me anything that I need since I will have to use twice as many cables to get 16bits color instead of 18bits color.

Edit: I take it back the FIFOs give me a nice place to solder my 40 pin connector into the input signals and the clock plus write enable

Edit: I just noticed the Read Clock is 5 volts, so that seals the deal to use the input signals and forget the FIFO buffering. Write Enable is over 3.3V (around 4V) so I will have to deal with that too.

[Legion]

Looks like you're making good progress. Are you sure those 8 pin DINs will fit? I bought a few from digikey that looked like they'd fit my Master System. But the top two of the pins on the SMS jack are offset. More like a horseshoe instead of a circular arrangement.

[miguelvp]

Looks like you're making good progress. Are you sure those 8 pin DINs will fit? I bought a few from digikey that looked like they'd fit my Master System. But the top two of the pins on the SMS jack are offset. More like a horseshoe instead of a circular arrangement.

We'll find out in 2 to 3 weeks, for the price I don't mind taking the chance. The 10 pin one looks like it will fit at least the pins not sure about the barrel. The 8 pin one on the back of the Genesis looks like a standard patern,.

If it doesn't then I guess I'll have to purchase the adaptor or bend the pins that don't align, or yank them out and drill a hole where they are supposed to go.

Before soldering I think i'm going to work on splitting the c-sync signal (pin 1 on the Saturn) so that the FPGA will produce the right polarity HSync and VSync pulses. I'll figure later how to deal with the full composite video to get the signals since they live in the lowerr 500mV of the signal. I might have to resort to the LM1881 since it will give me the back porch information.

I don't expect all this to give me the final solution either since the write clock and the sampling clock is determined by the SuperScan board, so it's just to wet my feet. Eventually I think a board that has all the needed hardware and a true 8 or 10 bit ADC decoder so I can control the pixel clock with the HSync VSync and backporch information to make it as pixel exact as I can, maybe even substitute the FPGA eventually with a PSoC 4 or something cheap like that.

But if i can get it to record video into the microSD card as a proof of concept then i'm more than half way there

[Legion]

But if i can get it to record video into the microSD card as a proof of concept then i'm more than half way there

If you can get it working with good image quality you should sell them. Those Micomsoft devices go for ~$400.

[miguelvp]

Market is so small that I don't know, but maybe! I always wanted to design a board, this could be a good excuse

Little progress today with some frustrations.

This is my triple channel up to 330MHz 8 bit per color VGA DAC



It hooks directly into Altera compatible GPIO headers (the BeMicro CV has one as well).
By looking at it you will figure that it extends the connector to use the unused pins, right?

So I was trying to use pin1 since it's a clock input, and couldn't see the signal at all, played with buffers and all kinds of i/o input configurations, nothing.

Hooked the scope to the signal and it was fine but I couldn't see anything if I probed pin 1 with the scope on the FPGA. Then it dawn on me to do a continuity test and NOTHING!.

Detached the board look on the bottom:



It's not connected at all! why wouldn't they just add the needed traces between the connectors totally escapes me. I mean, they even have the unconnected pins soldered.

Well I placed it on pin 1 of the opposite header and that's all it was. What a waste of a Sunday.

I can get the signals and they only have 50 ns delay on the rising and falling edge.

Bottom one is the original signal top one is the one coming out of the FPGA

[Ed Herdman]

@ miguelvp:  Sorry for being late, but I believe that sellers of Genesis RGB cables can tailor the sync type.  You wanted composite sync, right?  I am fairly sure that at least some eBay cable makers will add that for you.

But if i can get it to record video into the microSD card as a proof of concept then i'm more than half way there

If you can get it working with good image quality you should sell them. Those Micomsoft devices go for ~$400.

The Framemeister does, but not the PEXHDCAP, the PCI-E card, or the older series Micomsoft upscalers (I've owned three of the older Micomsoft scalers myself, and sold one on).

I'm interested to see what goes on with this project, but I think that a large part of Micomsoft's money is spent on ensuring compatibility for different devices.

Of course, even with the newest Micomsoft upscalers things aren't quite plug 'n' play; there's a dedicated user base that fiddles with the settings to try and find what works best, so if miguelvp's project is flexible enough and priced right it might be worth buying.  I'll wait and see how it turns out.

[miguelvp]

@ miguelvp:  Sorry for being late, but I believe that sellers of Genesis RGB cables can tailor the sync type.  You wanted composite sync, right?  I am fairly sure that at least some eBay cable makers will add that for you.

Thanks for the info,

But I figure that the common use is to make it SCART compatible and that uses Composite Video, so I might as well use that.

Edit: I can always put a jumper that will select between C-Sync or C-Video. C-Video being the best result since using C-Sync I won't have access to the back porch frame data although I can do it via the FPGA since I will know when data is coming in (by looking at the earliest and allowing for a reset if the frame sync changes.

For now I'm going to use the FPGA to generate those signals but I rather have the back porch burst information so the LM1881 is perfect for that. specially since in VHDL I might need to delay my Vertical sync by the width of the horizontal sync. But that should work.
HSync is easy I just have to look at the falling edge of the C-Sync and if we are not currently on a VSync.
To figure out the VSync I have to wait until it passes the width of the HSync to determine it's a VSync.

I'm just going to attempt to get a crude proof of concept with the FPGA, the C-Sync signal and the re-purposed SuperScan2. BTW, I'm including a picture of the back of the device to show that Micomsoft had something to do with it back in 1996.


Edit: Just to clarify that after the crude attempt I'm going for a final solution, maybe using a CPLD (Max V) unless I can use the PSoC chip, plus the LM1881 and a better ADC.

[Ed Herdman]

Just wanted to bump in a word of thanks for the SuperScan2 picture back.  I know some folks will be interested to see that.

[miguelvp]

Just wanted to bump in a word of thanks for the SuperScan2 picture back.  I know some folks will be interested to see that.

You are welcome, sorry for no progress. This work week has been a bear so no much spare time to do anything, I'll resume tomorrow.

[miguelvp]

I got the HSync derived from the CSync from the FPGA, pretty much I just detect the rising and falling edges, at which time I find the current positive or negative pulses. Also I keep track of the minimum and maximum positive and negative pulses.

So on falling edges I initiate the hsync and use the minimum negative pulse as the delta for the sync.


Close up to the HSync pulse:


Note the voltage levels, the derived one (top) has the right level for the superscan card.
Edit: Also I'm currently using a 25.175(or close) MHz clock, I can make the delay of the signal smaller by increasing the clock that I use to sample the rising and falling edges.

Now to work on the VSync, I'm planning to derive that from a negative pulse that is bigger than the minimum negative pulse to start the VSync Count, the wait until a negative pulse is back to the smallest negative pulse to end the VSync.

I think at the end, this TI chip will make my life easier, seems more versatile than the LM1881
http://www.ti.com.cn/cn/lit/ds/symlink/lmh1981.pdf

[miguelvp]

Now I got the VSync out from the Composite Sync signal. The plan is for the FPGA (eventually the LMH1981) to create VGA level HSync and VSync signals to feed to the SuperScan 2. Then use the Saturn's RGB output to feed the SuperScan 2 RGB signals.
Then get the digital version from the SuperScan board and feed that to the FPGA.

Here is the VSync derived from the CSync using the FPGA:


Here is the detail of the VSync signal and the CSync signal below.


I need to wait for the connectors, but I'll start soldering the ribbon to the back of the SuperScan.

In the interim I'm going to hard program the FPGA and see if I can get an image out of the superscan to my TV, driven by the derived HSync and VSync from the Saturn's video feed.

[miguelvp]

In the interim I'm going to hard program the FPGA and see if I can get an image out of the superscan to my TV, driven by the derived HSync and VSync from the Saturn's video feed.

So I did that fed the CSync from the saturn and use some counters to do some red and green ramps (although I think I have a problem with the green algorithm or noise on one pin).



But using the sync and counters it did make the SuperScan lock to the signal and convert it and display it on the TV.

Granted there is unused junk on the bottom but I that's because I'm not deriving a pixel clock nor counting the total lines to derive the pattern, just wanted to lock to the signal so that works.

Edit: To be clear what this is, the Saturn Composite Sync is driving the VSync and HSync, the FPGA other than deriving the sync signals is just putting some RGB ramps for a horizontal count and a vertical count. The color will eventually come from the Saturn.

[miguelvp]

So last night I did hook up the superscan to the video output of a laptop that lives on the TV (you'll probably seen it tucked under the TV bezel), but I had the resolution set at 1920x1080 and it didn't lock (way above the specs), Then I changed the resolution and it will lock but it's intermittent so I think I mess the superscan up.

It does lock but then after 4 seconds or not it jitters all over, then it locks again. The OSD seems fine. Took it back to my office and it seems the clock feeding the ADC is out of whack every so often.

Well it does lock at times so even if I busted it, I can keep going with the proof of concept anyways.

So today, I soldered the 40 pin header to the back of the board.  C-Sync will come from the Saturn and return H-Sync & V-Sync to the VGA cable.
R0 and B0 are not connected, the pins for the ADC for those two values are on the other side (not used by the superscan since it does a 5/6/5 RGB), the 5V I left it unconnected and I left another GPIO wire unconnected so the pinout is organized. I checked for shorts and it all looks good.



Note that the ground is soldered too, that is the same ground I was using to look at the digital data out of the ADC a week back.

Here is how I'm going to wire it up to the VGA and the FPGA. The RGB signals straight from the Saturn to the VGA might not be strong enough but I should be able to see something and then deal with amplifying the RGB signals and change the offset.


Edit: Of course I will connect the ground of the saturn (barrel) with the VGA ground and since the VGA plugs into the SuperScan VGA input it will be the same ground for the FPGA.

I got an email that my connectors where shipped and it seems they'll be here tomorrow, so just in time for hooking everything up.
I will report if the 8 and 10 pin connectors are compatible with the Genesis and the Saturn respectively.

Once I have it all hooked up I will make sure I can get digital data out by probing it with the scope.

Then I will program the FPGA to capture and translate the data into my 3 channel 8 bit DAC and display the output on a VGA monitor.

Then the hard part starts, switching from the DE0-nano to the BeMicro CV, and buffering the data to the SDCard and figure out how to write to it so I can read it on the PC. That last part is going to take a while.

Then later on, I'll move into using the LMH1981 to generate the sync signals and capturing the color burst by using the backporch signal in order to derive the pixel clock. But that is way far in the future. I will have to source a good triple channel 8 or 10 bit ADC that respects the clock given to it I did find some but didn't finish my research on that, then substitute the FPGA with a CPLD or maybe a PSoC. But first we'll see if I can get the digital data out of the board.

[Legion]

Here is how I'm going to wire it up to the VGA and the FPGA. The RGB signals straight from the Saturn to the VGA might not be strong enough but I should be able to see something and then deal with amplifying the RGB signals and change the offset.

I recently modded my N64 for RGB output. The signals are pretty weak so I used this RGB amp: http://www.ti.com/lit/ds/symlink/ths7314.pdf
Might work for you.

[miguelvp]

I recently modded my N64 for RGB output. The signals are pretty weak so I used this RGB amp: http://www.ti.com/lit/ds/symlink/ths7314.pdf
Might work for you.

Thanks that might get handy. I might be able to power it from the console connector.

I did get the connector and you were right about the 8 pin ones for the Genesis. They don't match since they are round like forming an O instead of like the Genesis which forms an U.
I was able to bend the two upper pins and got them to connect but eventually I broke one pin by trying to be able to plug the connector all the way in (good thing I ordered 3), but back to the Saturn.

The 10 pin connector works as far as the pins go, the barrel had to be hacked a little, but I got it to work.

So I soldered the connector including the ground and wired it to the VGA out that will go into the SuperScan2 and also wired it to the FPGA so it can derive the H and V sync to the VGA connector.

I took a picture on how it will end up with the BeMicro CV



Note that I used the wrong header for that picture, the other one is the Altera compatible GPIO
Here is a close up of the BeMicro CV, which has enough fast memory and it also has a micro SD card for writing the final thing.



So other than rotating the board and writing the final code it's all wired up.

Next I'm going to re-attach it to the DE0-Nano and switch the pins to output the HSync and VSync to the other header so it will drive the custom VGA connector.

I got also 75Ohm terminators with the same order and some T connectors (and dust caps for my scope) I already had a VGA to BNC (RGB,VSync,HSync) which I've been using for the scope captures, so I have to start a new FPGA project that only does the CSync to VSync and HSync and see what I get on the VGA connector.

If it looks ok (with all the video coming out of the Saturn) then I will fire up the SuperScan2 and hook it to the TV via the composite output from the SuperScan to see If I can see a thing.
Then I'll work on capturing the digital output and convert it back to VGA on the other header and see if I can get the full video live.

Then to the BeMicro CV and writing the buffer and SD card code.

Edit: So cautious and I soldered C-Sync to pin 8 (composite video) instead of pin 1 (composite sync). It's late so tomorrow I'll move it to pin 1. was wondering why my HSync and VSync looked wierd, it was picking the video signal of the composite as 1's, there was a pattern but not a good one

[miguelvp]

So I had the Composite Sync connected to the Composite Video on pin8 instead of pin1


I fixed it and hooked everything up including the Saturn. The FPGA uses the CSync to generate VGA Levels HSync and VSync, RGB goes directly to the VGA connector and that is fed to the SuperScan2 VGA input connector. Then i had the scope hooked to the converted Composite Video, meaning that the SuperScan2 is actually digitizing the video.


Here is the Composite output with the Saturn Video on it, Not sure what the end of the frame is, seems like uninitialized data.


Here is a single frame captured.

eyeballing 16.68 ms (12x1.390ms) frame length.

Edit: Here is the real direct capture of the Saturn Composite output same timings:


Edit: For reference this is a direct capture of the Saturn Composite output at 16.74 ms frame length so about the same, it seems to be doing something weird.
Edit: Oh this was the Red output from the Saturn, not the composite output. Added the real thing above.


I'm going to move the setup to the living room to see what it shows on the TV, seems like it's only converting half the frame.
I'll post a picture of the TV later when I test it.

In theory I should be getting all the memory write clocks and data available on the FPGA that's the next step and I'll use the 3 channel 8 bit DAC to convert the digitized data to display it on a VGA monitor so I can tell that I'm actually digitizing the video.

[miguelvp]

So I moved everything to the living room since the composite output on the scope showed there was valid video.

This first one is NOT the captured display, this is the Saturn connected directly to the TV using it's own composite.
And this corresponds to the signal that we've been seeing all along (because the RTC battery is dead).


So I connected the whole contraption using the FPGA and the SuperScan2 to the Saturn, and the TV to the composite output of the SuperScan2
Powered it up and:


Note the uninitialized data on the bottom, I might be doing something wrong on computing the horizontal sync signal, maybe it's interlaced and i'm supposed to only generate one HSync per composite horizontal sync. Since the original signal after the backporch is exactly twice as big as my synthesized one. But I can deal with that.

So I powered cycled the Saturn and the bottom part of the frame buffered got some other values that make it look a bit better.


But ever since I tried to push the SuperScan2 to 1920x1080p it looses lock often, it does the same with other VGA inputs as well so It's not due to the FPGA, something went bust but might be on reading the data from the FIFO so I might have a chance to get it stable.


But since it's for proof of concept it doesn't really matter as long as I can get the code done and then use designed hardware for it.

Next step is to half the horizontal sync signal so I get the full screen (should be easy) then to start writing VHDL to capture the digitized data.

Edit: So what I've done so far is to convert the Composite Sync and RGB data into a VGA compatible signal that the SuperScan2 can process.

Edit: Seems like the Saturn displays 320x224, that's why it's locking to only half a frame, pretty much is doing a 240p but locking at 480p, but that means that the SuperScan is really capturing the full image but it doesn't really support 240p so it's showing it at 480p

[miguelvp]

FPGA progress,

I finished setting up the top module as far as the top instance declarations and the pin assignments.

I'm going to embed a portion of it in the post but also have the full top level schematic attached in the post if anyone wants to know the pins used for the DE0-Nano.

The inputs are on the left and outputs are on the right and will describe them at the pin level name instead of the module name.


C_SYNC is the Saturn CSync signal that is sampled with the pll clk clock at 25.175MHz (1007/2000 of the on board 50MHz clock). That generates HSYNC2 and VSYNC2 that goes to the SuperScan's VGA input along with the analog RGB from the Saturn (not in the diagram since it's analog and don't go through the FPGA

I will use the HSYNC2 and VSYNC2 to GenLock with the FPGA to VGA monitor output (those are all the other outputs in the module) to give me a 640 x 480 @ 60Hz video that is converted back to analog via an up to 330MHz 3 video channel 8 bit DAC.
Those signals are: BLANK_N, SYNC_N, VGA_CLK, HSYNC, VSYNC, RED[7..0], GREEN[7..0], BLUE[7..0] (8 bits)

Edit: this is the VGA output board that sits on the other header of the DE0 Nano and the pins assigned on the schematic correspond to what this board needs:


W_CLK is the ADC driven write clock from the SuperScan, That with WE_ODD and WE_EVEN (both active low) will tell the FPGA that data is available on the MEM_RED[5..0], MEM_GREEN[5..0], MEM_BLUE[5..0] as long as W_RST (active low) is not active.

For now I'm just going to pass the digitized values straight to the VGA output and pad them with 0s (Edit: To convert them from 6 bits to 8 bits, I will ground R0 and B0 since they are not connected to the ADC). So I will end up with something similar to what it was on the TV but on a VGA monitor with the difference that now it will actually be displaying the digitized video converted back to analog.

Then I will have to write a buffer that can hold a frame so I can double the values (no interpolation) so it outputs 640x480.

I'm going out with the wife so I can't work on it until later tonight or tomorrow.

[miguelvp]

So I wrote some VHDL code that will capture the RGB values (forgot to ground R0 and B0 so they were floating)

Code: [Select]

-- Read RGB
process (wclk)
begin
  if wclk'event and wclk = '0' then
    if (wrst = '1') then -- I think this is causing some trouble.
      if (weodd = '0') then
        red_signal(0) <= '0';
        red_signal(1) <= '0';
        red_signal(7 downto 2) <= mem_red;
        green_signal(0) <= '0';
        green_signal(1) <= '0';
        green_signal(7 downto 2) <= mem_green;
        blue_signal(0) <= '0';
        blue_signal(1) <= '0';
        blue_signal(7 downto 2) <= mem_blue;
      elsif (weeven = '0') then
        red_signal(0) <= '0';
        red_signal(1) <= '0';
        red_signal(7 downto 2) <= mem_red;
        green_signal(0) <= '0';
        green_signal(1) <= '0';
        green_signal(7 downto 2) <= mem_green;
        blue_signal(0) <= '0';
        blue_signal(1) <= '0';
        blue_signal(7 downto 2) <= mem_blue;
      end if;
    else
      red_signal <= "00000000";
      green_signal <= "00000000";
      blue_signal <= "00000000";
    end if;
  end if;
end process;

Then I used those values for the RGB DAC connected to a VGA to BNC cable to look at the signals:

purple cap is a 75 Ohm terminator, green one is a 50 Ohm one.

The "English" selection on the screen blinks with a red highlight, in this capture you can see when it's mid red

In this one you can see it at full red.

Edit: this is what the original red signal looks like straight from the Saturn connector:


Since I was getting digitized data and the signal look kind of ok I hooked it up to my adapted laptop LCD and only was showing this, the OSD reports 698 by 233 @59


I think the WRST is forcing the other pixels to go to black (all zeros)

The VGA monitor is not quite syncing at that resolution I have to modify the VGA HSync VSync to display at 640 by 480 at 60Hz and Genlock it to the Saturn Vsync.

I was expecting a noisier image since it's just a long ribbon cable that is probably picking all kinds of noise. But at least it shows that i'm capturing digital data! 
Sorry about the crappy camera phone picture but I couldn't use my tablet to take a picture between the Saturn and the display right behind it.

[miguelvp]

So that cutoff reminded me to a previous test I did when displaying a color ramp


In the code I have the video disabled after 639 ticks (640 pixels) but I forgot that i'm running the pixel clock at 25.175MHz, so it was truncating the horizontal line after just 25.382us I changed it to 1279  (50.80437 us).
The captured signal on the scope now shows more data


And the VGA monitor (still locking at 698 by 233 @59) show more video.


I have to do some timing measurements to disable the video at the right time since it's still chopping off the very end of the horizontal line but I know now that I'm capturing the whole data.

I optimized the capturing memory code, well it does exactly the same but less lines of code.

Code: [Select]

-- Read RGB
process (wclk)
begin
  if wclk'event and wclk = '0' then
    if (wrst = '1') then
      if (weodd = '0') or (weeven = '0') then
        red_signal <= mem_red & "00";
        green_signal <= mem_green & "00";
        blue_signal <= mem_blue & "00";
      end if;
    else
      red_signal <= "00000000";
      green_signal <= "00000000";
      blue_signal <= "00000000";
    end if;
  end if;
end process;


[miguelvp]

@Legion,

Could you fire up your Saturn and go to the set language menu on your Sony CRT and take a picture? I just want to compare the colors since my language selection shows the dot as yellow (composite shows it as pretty much white) and the exit button shows a purple and the composite is more bluish.

I just want to make sure my current digitized colors match what it should be on an RGB output.

Thanks.

[Legion]

Here you go...

[miguelvp]

Thanks,

That brings a future feature:

Intensity grading emulation like the scopes do at the expense of a larger file.

[Legion]

I modded my N64 for RGB output a little while ago. As part of the mod I added a THS7314 amp since the signals off the video chip are pretty weak. The amp only amplifies the R, G and B signals. Sync is not amplified. Sync is pulled from the composite video signal. I was playing some Super Mario 64 and I noticed that whenever the brightness level of the screen was high, say from a white screen, sync would be lost and the picture would distort. It kinda tears the top of the picture to the left of the screen.

I'm thinking a sync stripper might help. Maybe a bright picture equates to a large comp signal and it swamps the sync info? I don't really have a good handle on how video signals are encoded. All the info about it just shows timing diagrams. I'd like to see something like a row of pixels and then the video signal below sectioned off to show what each pixel encodes as.

[miguelvp]

I'm thinking a sync stripper might help. Maybe a bright picture equates to a large comp signal and it swamps the sync info? I don't really have a good handle on how video signals are encoded. All the info about it just shows timing diagrams. I'd like to see something like a row of pixels and then the video signal below sectioned off to show what each pixel encodes as.

I think it will help, the color burst part of the composite might be affecting the TV sync, there is a simple lm1881 "circuit" that can probably be hooked up directly. I put circuit in quotes because they just solder the resistor and a couple of caps on the lm1881 and hook it directly to the power on the connector.

Here is a picture of the composite signal out of many frames with that red green and blue pattern I've been showing.


Here is a picture of a single composite horizontal line (red ramp part) I hope this helps visualize the data a bit. Also I pasted in the picture my trigger setting to lock into the vertical sync so you can see specific lines from your scope by scaling to see one line and scroll with the horizontal position of your scope to the line you want to look at.


On the project, I'm still working on the buffer and learning about the Altera's Avalon specification specifically the streaming capabilities, and I also got that Chronos watch, I will try not to let me distract me from this project

Tried to make a double buffer to store 2 lines worth of capture data but that puts the FPGA to it's limits so I rather stream the data to the memory and then to the SD card, but it's going to take some learning.