Cloning the GameCube component cable

[Unseen]

Sorry if I post again. I've a "theory" about my issue. Both my LCD and my TV don't seem to handle 480i, while they show 480p but with those lines. Is it possible that since they can't handle 480i a slight difference in the timings (front/back porch?) can cause those lines? Maybe a LCD capable of handling 480i is more flexible to timings differences and it can handle the video with no issues... could it be right?

No, I don't think it is (directly) related to 480i support.

To test this, I connected a GCVideo Lite board to the VGA input of my TV (does not support 480i on that input) and to an old Sony TFT (PC-only, does not support interlaced at all) and ran the 240p test suite in 480p mode to display a solid, dark gray screen. On the TV, I did not see any vertical stripes at all, but on the Sony there were faint stripes visible. A closer examination of the video signal from the board using an oscilloscope revealed the cuplrit: There is a small interference from the 27MHz pixel clock on the three RGB lines. This does not matter if the display samples the video data with the same frequency because it is just a small, constant offset at each sample point. However, if the display incorrectly interprets the signal as 640x480 instead of 720x480, the phase of the sampling points and the 27MHz interference shifts with every pixel, resulting in vertical stripe artifacts.

Unfortunately, I don't see any option to fix this on the FPGA side - even if you were willing to live with a slightly reduced horizontal resolution, outputting 640x480 instead of 720x480 is not possible with the FPGA on this board because it has no PLL to generate the necessary pixel clock. A modified PCB layout might help, but I'm not familiar enough with low-noise analog circuit design to figure out what needs to be changed. One thing you could try is to solder three 120pF capacitors in parallel with the three 75 ohm resistors (R2/R3/R4) next to the RGB output pads - since the resistors are SMD, stacking a capacitor on top shouldn't be too hard. If this reduces the stripes, but does not eliminate them you could also try higher capacitor values, but the higher you go the more sharpness you'll lose.

Of course if my theory is correct, the best solution would still be a display that samples the signal with 720 pixels horizontally instead of 640.

Oh BTW, I think this might be useful to others. I found a way to flash the FPGA with a cheap Altera USB Blaster clone. This works also on non-Windows OS.

Neat, thanks!

[Aurelio]

Thank you again for helping me. I will try filtering the RGB signals with those caps
In the meanwhile I've also bought a 5" Dalian Good Display which is confirmed to be working with your board by many people. Right now I've a 5.6" Dalian LCD that uses a different board, so maybe it will help.

[Aurelio]

Aurelio, try using the auto adjust on your screen while in the swiss menu.

Check out this thread too
http://forums.modretro.com/viewtopic.php?f=36&t=10690

If that doesn't fix it, I had some problems with the voltage from the regulator going to the gpu being too low.

Sorry, I didn't notice your answer. The problem is the LCD control board. The GPU voltage is fine since I'm using the stock regulator for now.
Anyway, I've received the 5.0" Dalian Good Display and it has a different control board with respect to the one that came with the 5.6" LCD. Also the firmware is slightly different and it has configurable clock setting that removes most of the vertical line effect if tuned a bit.
I will try to dump the firmware of this board and check if I can use it on the board that came with the 5.6" LCD.

[ShockSlayer]

I've had a lot of late night discussions with megalomaniac about GCVideo lite, and once thing I'm curious to know is about latency(in frames I guess) on the onboard GC and Wii video encoders.

Any idea what those numbers might be? or if the GC and Wii are at least different? What about the vanilla GC component cable and GCVideo lite(both component and HDMI?) I've been told that GCVideo lite(component) is 12 frames.

SS

[bobrocks95]

Maybe 12 scanlines. I don't think it would even be possible to design it to take 12 frames, that's ridiculous.

By video encoders you mean the DAC converters? Encoder ICs are limited by transistor gate delays which are influenced by the speed of electrons flowing through a conductor. I'm not sure you could intentionally design one that took even over 10ms, much less nearly 200.

[Unseen]

I've been told that GCVideo lite(component) is 12 frames.

LOL, no - that would be absolutely horrendous lag. The latency should be roughly a dozen pixels, maybe less - I don't remember the exact numer. The FPGA on GCVideo Lite doesn't even have enough memory to store two lines, which would be the minimum to implement linedoubling.

If you prefer that number in frames, it would be around 0,00005 frames lag if my calculation is correct.

[novenary]

Nothing to worry about. The component cable and the built in AV encoder probably have the same order of lag.

[megalomaniac]

The first person to mass produce those boards... woah, if nothing else, you could sell one to every member of the competitive smash community.

But would the smash community really be willing to accept a solution that adds approximately a dozen pixels of lag?

^^^^
i think this is shockslayers concern
(those damn pixels)

[tueidj]

The hardware in the GC and Wii is practically identical in terms of speed. Physically they're a little bit different because the wii has an internal (3-in-1) encoder instead of requiring an overpriced cable.

[ShockSlayer]

If you prefer that number in frames, it would be around 0,00005 frames lag if my calculation is correct.

So just so I'm clear, that's compared the the normal encoder?

Thanks for the responses.

[Unseen]

So just so I'm clear, that's compared the the normal encoder?

No, that is compared to the timing of the digital video signal of the Gamecube. I have no idea how much time the normal encoder needs to output a pixel from that.

[tueidj]

How can the hardware that creates the video signal (the encoder) have lag? It makes no sense.

[ShockSlayer]

I'm sorry if I sound stupid, a lot of this is technical stuff out of my normal endeavors and the majority of what I'm going off of is what I can remember from past discussions. I just know eventually with Melee someone's gonna claim GCVideo is laggy, and I want to know to what degree(even if it's minute) or if it even is. The baseline for "zero lag" is composite out coming from the AVE-DOL.

My whole thing is that the digital video signal that's going to the AVE-DOL also goes to the digital video out port, which would mean in theory that it's possible to plug something in that's faster than the AVE-DOL/MX chip, as I'd assume the conversion there isn't instant. Right now I figure that GCVideo is probably slower, but by how much is what I really wanna know. But I don't really know how to determine that.

[bobrocks95]

The DAC encoding the Gamecube's digital signal into NTSC composite is likely slower than the digital version of the GCVideo.

It's a fool's errand- 1 frame in 60fps is roughly 16 milliseconds, anything GCVideo or the internal DAC or the MX chip in the component cable is doing is happening on the order of microseconds... If someone in the Smash community truly does end up complaining about that in the future they're a complete idiot.

[tueidj]

as I'd assume the conversion there isn't instant.

Well no, it performs a digital-to-analog conversion at the rate of the pixel clock e.g. 27 or 54MHz. That's as theoretically fast as the analog signal can be produced.

[Unseen]

How can the hardware that creates the video signal (the encoder) have lag? It makes no sense.

How can it not have lag? We live in a universe with a finite speed of light, so even a simple cable has to have lag. The interesting question is not "does it have lag", but "is the lag at an acceptably-low level".

I just know eventually with Melee someone's gonna claim GCVideo is laggy

Just laugh at them, repeatedly. ;) If they insist on playing with composite or S-video from the regular output of the cube, ask them how much lag the color decoder in the monitor has and why that lag is acceptable to them.

A little bit of background: When you use an RGB SCART connection, the picture is often shifted to the left a bit compared to a composite signal from the same source. Some TVs automatically compensated for that, others (especially low-end ones) did not and thus some people right-shifted the image a bit in the service menu. Since the composite video signal was commonly used to provide the sync for the RGB signal(*), that left-shift indicates that the image from RGB must arrive earlier than the image from composite. This is because encoding the signal to composite and decoding it again at the TV introduces a bit of delay - "lag" in Melee-Sp33k.

(*) Nowadays people try to avoid composite-video-as-sync to optimize the picture quality, but using it has the advantage that the cable still produces a picture even when the SCART input is not RGB capable, reducing support calls and returns and thus expenses.

The baseline for "zero lag" is composite out coming from the AVE-DOL.

It is possible to measure the lag of the original encoder, but it's quite bothersome to do so - you'd have to connect a (digital) scope to the digital video bus and to the composite video output and display something like a vertical line, where the transition is easily visible both in the digital data and the analog output.

My whole thing is that the digital video signal that's going to the AVE-DOL also goes to the digital video out port, which would mean in theory that it's possible to plug something in that's faster than the AVE-DOL/MX chip, as I'd assume the conversion there isn't instant.

I think the fastest possible way would be to use just the Y part of the data, if you can live with a black&white picture. Since the cube uses 4:2:2 YCbCr, reconstructing the color already requires at least one pixel of delay because you need to wait for the second pixel in a group to fully determine the color of the first.

[tueidj]

How can the hardware that creates the video signal (the encoder) have lag? It makes no sense.

How can it not have lag? We live in a universe with a finite speed of light, so even a simple cable has to have lag. The interesting question is not "does it have lag", but "is the lag at an acceptably-low level".

The definition of "lag" is normally the time between when a signal is generated to some other event i.e. the time between when the video signal is created to when it is displayed, or the time between a button being pressed and the result being visible. Hence measuring the time between when the video signal is generated vs. when the video signal is generated doesn't make a lot of sense to me.

[ShockSlayer]

Well basically it all comes down to "input lag," which is what people want to reduce as much as possible. And you can only influence that by changing how you handle the video, because the signal from the controller hits the cube the same way regardless of everything else.

So for example, the time between hitting a button and seeing it on one TV may be 1 frame, and on another TV it may be 3 frames, and that's all based on the speed of each individual TV's decoder.
Following the same logic, since we're technically using different encoders, the speeds at which they process the video into whatever could be different. I wanted to figure out if these other, extremely attractive options come with any delays. However it's not really possible to determine the relevance of their speed without knowing the actual speed of the baseline AVE-DOL.

It sounds like we need someone to get their hands on a digital scope. Then we can know for sure.

[andre104623]

Well basically it all comes down to "input lag," which is what people want to reduce as much as possible. And you can only influence that by changing how you handle the video, because the signal from the controller hits the cube the same way regardless of everything else.

So for example, the time between hitting a button and seeing it on one TV may be 1 frame, and on another TV it may be 3 frames, and that's all based on the speed of each individual TV's decoder.
Following the same logic, since we're technically using different encoders, the speeds at which they process the video into whatever could be different. I wanted to figure out if these other, extremely attractive options come with any delays. However it's not really possible to determine the relevance of their speed without knowing the actual speed of the baseline AVE-DOL.

It sounds like we need someone to get their hands on a digital scope. Then we can know for sure.

So if i were to solder my input lines right to the pins of the ave-dol instead of the digital port there would be less lag? Not saying that I notice any lag but still

[ShockSlayer]

No. It's been awhile since I've looked at a non-trimmed GC motherboard, but I'm pretty sure the digital port pins come straight off the processor.

[andre104623]

No. It's been awhile since I've looked at a non-trimmed GC motherboard, but I'm pretty sure the digital port pins come straight off the processor.

No there are video filters between the digital port and ave-dol video chip

[bobrocks95]

Somebody better get to work on a neural interface for Melee, all our fingers have way too much input lag!

Unseen is humoring you, but I won't- you're grasping at microscopic straws. Nobody should waste their time using an oscilloscope on this if the purpose is to find out if it affects your Smash playing, because it doesn't. Not at all. 0%. You can satisfy some sort of morbid curiosity, sure- it's kind of interesting to wonder how long the signal takes to reach the digital output. Not useful in any way whatsoever, but interesting. You seem to think though that it needs to be done to prove to the Smash community that this won't affect their precious reaction time when it's a 12-pixel delay on a beam sweeping horizontally 31,000 times a second (to use a CRT as reference).

It's hilarious to me that this EXACT scenario was joked about right when this project was posted, and now here we are.

[ShockSlayer]

Ok.

[megalomaniac]

talking to shockslayer it appears his major concern is how to "easily" explain lag or lack of lag to people in the smash community who would otherwise be quick to cry and complain about lag from gcvideo without even having tried it for themselves but would also be so quick to dismiss it.


as far as smash community is concerned, the baseline is set for video display from the composite / svideo / rgb outputs from the multiAV.
Im not sure how widely understood the notion is that it is possible to have a small bit of lag introduced from the processing of this video data even on a CRT depending on the CRT itself. Yet once new digital TVs are discussed then lag is always the major topic of concern.


so in a nutshell, how can all this information be presented to the smash community to embrace GCVideo rather than discredit it?

[jmlee337]

Even (or perhaps especially) in this modern age of reddit misinformation, Kadano is a figure nearly infallibly trusted when it comes to the technical and mechanical aspects of Melee. He is aware of all the various ways that lag can be introduced into a system, as well as their relative impact. He's also aware of GCVideo, and has specifically stated that he's interested in your upcoming product. I wouldn't worry about this one.