gc-forever - Gamecube/Wii Forums

Considering how large the "Cloning the GameCube component cable" thread is, I figured a new thread might be better to tackle this specific usage, and would be easier to find for others who may need help.

So, I've got this thing wired up and programmed but for the life of me, I can't even get a "no support" out of my TV, just "no signal." I've checked my wiring a thousand times, even did continuity all the way to the FPGA pins. And I've used the same wire to wire it to a Gamecube before too(34 gauge.) I've checked all the basic stuff, N64 has been outputting video over composite from the normal DAC the whole time, GCVideo is getting 3.3v, etc. Even tried using IDE for the clock and dsync wires.

I've got a few questions, mostly just to help me establish a frame of reference so that I can continue troubleshooting:

1. Has anyone else successfully programmed a GCVideo lite using the .svf file on the github? I don't see any reason it shouldn't work, but I'd like to be sure. The method I've been using so far is...rough.
2. Does anyone have any pictures of this wired up and working?

Thanks.

Alright, so I've pressed a little further on this but I'm still coming up empty...

I've got a plethora of different TVs/monitors I've tested GCVideo on GC with, and they all produce the same result with the N64 svf: NO SIGNAL.

1. BenQ monitor w/VGA input - supports 240i/p 480i/p etc. Doesn't give a shit, seems to display anything.
2. RCA flatscreen CRT - has component input, but doesn't support progressive. Only recently started testing with this one.
3. Assorted other VGA monitors, don't like any interlaced video, so I've really only tested 480p on them.

So I'm not getting ANYTHING at all on any of them, which just strikes me as odd. But I feel like I've atleast ruled out any progressive vs interlaced issues. Although I already knew that the N64 is interlaced only, this was more just to establish that I've tested different setups.

The next thing I moved onto was resolution. At first, all of my testing was over VGA, and my friend Aurelio pointed out that any resolution below 640x480 over VGA is non-standard. I had incorrectly assumed that the N64 always outputs a 640x480 signal, and my first set of testing was using OoT, which is around 320x240. So, to compensate for this, I changed testing games to Pokemon Stadium 2, which, when an expansion pak/ram swap is present, is reported to output 640x480. Unfortunately though, this changed nothing, so I figure I can rule out resolution as well.

I'm not really sure where to go from here. I feel confident that the GCVideo is programmed properly, and I know that it's okay electrically as well as I tested it on a GC shortly before programming it, and all continuity tests are checking out as well on the N64 wiring. I really wish I could get verification form someone else that the pinout in the github is correct, as well as the SVF file. Then it would have to be something I'm doing wrong.

ShockSlayer wrote:Has anyone else successfully programmed a GCVideo lite using the .svf file on the github?

Yes, a long time ago to verify that it actually works - but only using Impact to program a Lattice chip.

So I'm not getting ANYTHING at all on any of them, which just strikes me as odd. But I feel like I've atleast ruled out any progressive vs interlaced issues. Although I already knew that the N64 is interlaced only, this was more just to establish that I've tested different setups.

It feels a bit as if you might mistake progressive/interlaced to 30kHz/15kHz - both are distinct "qualities" of a video signal and only a single out of the four combinations is a signal that is likely to be accepted by any VGA input (but the others may work anyway, depending on the monitor).

At first, all of my testing was over VGA

That is probably not a good place to start - to get a Gamecube to output a VGA-like 480p signal, you must first boot a game that supports that resolution and tell it to switch to it. The N64 doesn't support 480p at all.

I had incorrectly assumed that the N64 always outputs a 640x480 signal, and my first set of testing was using OoT, which is around 320x240.

Fortunately, horizontal resolution doesn't matter for analog video signals.

So, to compensate for this, I changed testing games to Pokemon Stadium 2, which, when an expansion pak/ram swap is present, is reported to output 640x480. Unfortunately though, this changed nothing, so I figure I can rule out resolution as well.

Not completely - I'm not familiar with the resolutions used by specific N64 games, but if the game outputs 640x480, it will still be a 15kHz signal (TV-like), so its's 640x480i (interlaced). Some monitors accept that via VGA, some do not. 240p is the same 15kHz TV-like scan rate, but without interlacing - if a monitor supports 480i over VGA, it may or may not support 240p over VGA.

I'm not really sure where to go from here.

Try settings the GCVideo-Lite board to component mode (remove whatever you used to short the two pads labelled "RGB" in the corner) and connect the green output to the component or composite input of a TV. If you get a black-and-white picture, the board is programmed and installed correctly.

If you don't get a picture, but happen to have something that can measure frequencies, e.g. a multimeter: Measure the frequency between the "H" and "-" pins (all "-" are identical) on the output side of the GCVideo-Lite board as well as between "V" and "-".

A picture of your install might be helpful. (Generic advice for photographing console mods: Use more light. If the camera doesn't want to focus, increase the distance.)

Thanks for the reply! I'll use component from here on out, plus it's the only thing the CRT will take.

Here's what my wiring looks like:
http://i.imgur.com/ZO5FdWt.jpg

Green cable in composite doesn't show anything, same deal on component as well.
With my multimeter, I get a lot of different frequencies on the H and V pins, there weren't any clear values, and I didn't see 15kHz or anything that close to it. Most of the values were around 2 - 5 kHz.

Somewhat rarely, when everything's plugged in normally, I'll get a red tinted/distorted flash of the image for a split second, and then it disappears.
http://i.imgur.com/DE9pMqm.png
http://i.imgur.com/tyafZCb.png
http://i.imgur.com/CjpkJ0k.png

If I plug the only the red plug into the green port on the TV, whenever I hit the title screen I get a solid, but distored black-and-white image, which only changes a little bit when the other two are plugged in. I also get the same thing on composite.
http://i.imgur.com/AVOuTC2.png

Here's the full video that I grabbed these frames from:
https://www.youtube.com/watch?v=mEXEv57Bvgo
(upload may still be processing)

That's all I've been able to find so far. Thoughts?

ShockSlayer wrote:Green cable in composite doesn't show anything, same deal on component as well.
With my multimeter, I get a lot of different frequencies on the H and V pins, there weren't any clear values, and I didn't see 15kHz or anything that close to it. Most of the values were around 2 - 5 kHz.

That could indicate that the FPGA does not output any syncs, which would explain why your TV doesn't show an image.

Somewhat rarely, when everything's plugged in normally, I'll get a red tinted/distorted flash of the image for a split second, and then it disappears.

Since that signal (likely...) comes from GCVideo, I would guess that the FPGA is programmed and can at least partially decode the N64's video data.

If I plug the only the red plug into the green port on the TV, whenever I hit the title screen I get a solid, but distored black-and-white image, which only changes a little bit when the other two are plugged in. I also get the same thing on composite.
http://i.imgur.com/AVOuTC2.png

This one is quite interesting - although the Cr channel does not contain any syncs, the contents of that particular signal seem to be regular enough so the TV (mis)detects parts of it as a sync. What it shows it quite interesting - the area that should be the blanking space with a sync in it is shown in the center of the screen and it appears to repeat the last pixel value until it gets a new one when the next line starts. That's not what I wrote in the source code! ;) The corresponding bit on the digital side is sent on D2, but since you mentioned that you checked your wiring up to the FPGA pins is probably not a connection issue.

The colors are weird though - if I remember correctly, the yellow/red colors from the title should show up as white on Cr, not black as in your picture. Assuming that my memory is correct, either you swapped the red and blue outputs or the FPGA constantly misreads the input data. That could also explain why the blanking is wrong and why you don't see a reasonable frequency on the sync outputs, but I currently have no idea why that would happen - if it was due to interference, I would not expect it to happen consistently over a full frame as in the screenshot.

Thoughts?

Need to think about it some more. I currently believe that the FPGA is programmed correctly (it seems to process the data and it's unlikely that a partial/incorrect bitstream passes the CRC check) and that there are no shorts on the input wiring (composite still looks fine).

Sounds good. Let me know if there's anything you need me to test!

There was a problem in the code, so my wonderful friend Aurelio sent me an updated SVF and we got it working!



I'm told that the IO voltage level in Bank 3 wasn't set, which is the bank that contains sync(which I guess explains everything.) He told me he's going to make a pull request on the github for the fix. I didn't change my wiring at all either, so that wasn't the problem. I'm guessing you had probably fixed this already, but it didn't update in the github.

So happy that it works, now I'll be making the same face on N64 that I get with Gamecube GCVideo!

ShockSlayer wrote:There was a problem in the code, so my wonderful friend Aurelio sent me an updated SVF and we got it working!

Cool!

He told me he's going to make a pull request on the github for the fix.

He did and I merged it.

I'm guessing you had probably fixed this already, but it didn't update in the github.

I didn't, the old version works for me - maybe I was just (un)lucky enough that my installation had enough margin to work anyway.