Cloning the GameCube component cable

[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.

[Unseen]

You can satisfy some sort of morbid curiosity, sure

Since I had the cube set up anyway and I needed the scope to measure something else, I just did that. =)

Test setup: Gamecube running the 240p test suite in 240p mode, showing a pure-white screen. GCVideo Lite on the digital video connector, standard Nintendo composite video cable on the analog output. In the screenshots, the upper (yellow) channel shows the composite video signal, the lower (cyan-blue) channel shows the Y or green channel from GCVideo Lite. The scope (Rigol MSO2072A with 200MHz hack) was set to trigger on a specific line of the composite video signal on channel 1. To ensure that the signals are properly terminated, they were fed into T-connectors at the scope, with the other leg of the T going into two video inputs of a Sony PVM-9L3. All measurements were made with GCVideo set to component output unless noted.

Here is an overview showing multiple frames of the signal:


Zooming in a bit to the start of a single frame you can see that the start of the white image appears to be aligned in both channels, so neither of them delays the signal by a line or more.


Zooming into a single line shows that the upper signal is indeed composite video, you can see the color burst at the beginning of the line:


And here is the money shot:

The cursors (A is the solid one, B the dotted one) are set to approximately the end of the rising edge where the video signal starts to output white. As you can see, the DAC used on GCVideo Lite is slightly overspecified for this purpose. ;) The time difference between both points is -678ns, GCVideo Lite has less delay than the original encoder. Since the current video mode uses a 13.5 MHz pixel clock, this delay corresponds to about 9.1 pixels.

GCVideo Lite is slightly slower when it outputs RGB, because it has to calculate a matrix multiplication for each pixel to convert from one color space to another. This is what it looks like on the scope:

Still faster than the original encoder: -384ns between the rising edges, about 5.1 pixels.

I don't have an original component cable, so I can't make any measurements in 480p mode.

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

Indeed. Now let's see if someone claims that "negative lag" is also bad and the code must be patched to remove it. =)