gcvideo - Open source GameCube component cable solution

How would you make it 31kHz mode perhaps?

 

Do you mean without adding a custom DAC? I don't see how that would be possible. From what I gather, the output of the Gamecubes GPU feeds its on-PCB DAC chip ("AVE N-DOL" for NTSC, "AVE P-DOL" for PAL) with inputs sufficient to produce a 15kHz output. It also feeds the Digital-Out port with the higher-res signal, and then Nintendo's Custom Component cable has its own DAC, which converts to 31kHz output. Though I haven't found a good description of the AVE chip, so I could be mistaken.

 

Hello everyone. I'm new to the forums and I have been following this project for a couple months now. Great work to all of those involved! You have saved me from wasting the money I don't have on an official Component cable. I have a few questions I would like to ask and some ideas for those wanting to make a cable.

1. What parts would I need for the DVI version?

2. Can I use a custom connector and keep it all external?

3. Can both the analog version and the digital version be installed at the same time?

4. I have an American NTSC DOL-101. Is there any way to get at the very least RGB out of my Cube or will I have to get a DOL-001? If so, can someone get it up and running?

I also have an idea for cable makers. Can we make a box with the Digital AV connector (once it is recreated) that plugs into the back of the system (designed like the PS2 Network adapters) and has HDMI out for Video and possibly audio, TOSLINK for Digital Audio, a custom VGA port with support for both RGBHV and YPbPr, and a multi-out pass-through that has RGBS added?

 

The FPGA board (Pluto IIx-HDMI von KNJN) mentioned in the documentation and some way of programming it, for example with a TXDI/FTDI board from the same manufacturer.

Yes, as long as you keep the wires short. My development cube has ~20cm of wires hanging out of it and I would not recommend more than that.

In theory yes because both only receive signals from the cube without sending any(*) to it, but I haven't tested it.

(*) Minor exception: The "cable detect" signal on pin 1 flows from the external board to the cube, but it's just connected to 3.3V. You could just wire that one to 3.3V (pin 17) directly in the cube and not connect it to the converters at all. Things would work without that signal, the Cube just won't give you the option to switch to 480p.

I assume it it possible to connect a GCVideo board to a DOL-101 cube by wiring it directly to the AV encoder, but it will require some code changes because AFAIK there is no 54MHz signal available in those systems. This would also rule out any possibility of using 480p mode. I don't have access to a DOL-101 system, so I can't test that.

 

Thank you Unseen. I was planning on making a box that attaches to the back of the GameCube with a standard DB25 parallel port and put everything in it. Is there any way to generate the 54MHz signal needed so we could get 480p out of the DOL-101s? If you need a DOL-101 I might be able to help with that.

 

No - it's not just about a missing clock signal, the graphics chip must be switched to 480p mode first which as far as I know is disabled by the IPL on DOL-101 systems.

 

Can that be changed so its enabled?

 

I happened to come across this topic. Apparantly there still is a 54MHz clock signal on the board.

It seems he is also able to still get 480P. Doesn't that mean that the VDATA inputs can run at the 54MHz rate even if there is only a 27MHz clock going into the encoder?

I might want to mess around with this some day. What is an easy way to get 480p from a PAL cube? Also, does the 480p (and also other resolutions) comply to any standard? I believe 4:3 480p is supposed to have 858 pixels horizontally and 525 lines. I am worried that if the GC does not closely follow that spec some displays will not accept the HDMI output, since you provide a clock for the pixels there.

 

Interesting - on the GC forever forums there was a claim that no 54MHz clock could be located on the board. If the details from the topic you linked are correct, GCVideo should work with DOL-101 cubes if you don't mind wiring it directly to the pins shown there instead of the regular connector.

Yes, that is also what happens on a DOL-001 in 480p mode. The onboard encoder doesn't produce a usable signal in that situation.

Easiest? Pay a lot of money for an original Cube component cable - they should also work on a PAL cube, but you need to use either Swiss to force 480p (or 576p) or use NTSC versions of the games because the PAL ones do not support 480p.

Ignoring any blanking/active display area issues (see below), the Gamecube outputs more-or-less standard consumer video signal timings. There might be minor differences if you compare against CEA-861, but I never bothered to check every last line/pixel.

That is the total horizontal/vertical resolution including blanking and sync, the active area is just 720x480. The Gamecube almost always generates an even smaller active window, e.g. 666x448 in Mario Kart Double dash, but GCVideo DVI adds black pixels around that to increase the resolution "seen" by the monitor to 720x480. For the analog version there isn't even a need for this padding because the display cannot tell the difference between black pixels in the active area and the blanking area around it.

That is no problem, the video signal of the GC always uses a 13.5MHz (480i/576i) or 27MHz (480p/576p) pixel clock, which is exactly what HDMI expects for those resolutions. The two clocks on the digital output of the GC are exactly twice that because the cube outputs two bytes per pixel.

And for those who know about the finer details of NTSC: The 1000/1001 factor is much smaller than the 1% pixel clock frequency deviation allowed by HDMI.

(How to obtain rather detailed knowledge about video signals: Build something that converts/outputs them =) )

 

So all I would have to do to my cube is wire everything up to a custom connector and then attach the GCVideo to it? What connector would be best for this? I was thinking of using either a 25 pin printer port or a 15 pin VGA port to transfer the signals to the outside of the case. Also, will digital audio via TOSLINK or Coax be added to the DVI version?

I also have an idea for you Unseen:
Can you make a DVI version that supports both analog and digital like many PC Video cards?

Thank you everyone for the info on the DOL-101s! Now I don't have to buy a "new" GameCube.

 

I would recommend a connector that can't be mistaken for some other commonly-used connection to avoid frying either the cube or whatever is plugged into it. Also, the original connector has quite a few ground pins between the signals and I would recommend keeping it that way, it it useful for signal integrity. A DA-26 connector (similar to the 15 pin connector of old analog PC joysticks, but with 26 pins in three rows) might be a good option.

Yes, it will be in the next update. I'm not sure when it will be released though.

In theory, yes. In practice, the FPGA board I chose for the DVI version doesn't have that many I/O pins available (even after the next update which will eliminate the three "jumpers") and attaching a simple DAC would require 24 pins just for the three colors. Multiplexing them to reduce the number of pins required would be possible, but that would need Yet Another Custom Board[tm]. An off the shelf HDMI2VGA converter could be a cheaper option for this.

 

I'm having a hard time finding that connector online. Do you know where I can find it?

Take your time. I don't have enough money for all of the components at the moment.

Maybe one day it could be done. Are there any games on the cube that require a CRT for certain features?

 

It's certainly not the cheapest source for connectors like these, but Mouser part no. 636-180-026-102L001 and 636-180-026-202L001 at least have pictures of the connector I meant.

Smash Bros players seem to suffer from extreme paranoia about (imaginary?) lag, but other than that I'm not aware of any game that requires a CRT.

 

Allright, so the GC seems to output video that more or less complies with CE-861. I checked on of the HDMI spec documents (I believe those are not supposed to be available freely), but could not really find much about the signal timings (number of pixels per line, number of lines, blanking periods etc.). That surprises me a bit. Do you happen to have a source with the timings for different video modes more detailed?

I have been working on an N64 to VGA mod and planning to add HDMI once I have new PCBs. The N64 video has some really weird timings. It has about 773 pixels per line. I do not think every TV would accept this signal if it was converted to HDMI directly, since the 773 pixels is kind of weird (if it is 240p you first line double it of course, but then you still have the weird 773 pixels). Do you have any idea if it would be possible to get a more standard video output (640x480 with 800 pixels per line for instance)?

I would be able to write the image to a framebuffer and then read out the image and output it with more compliant timings. Ideally you would then use two framebuffers, one for reading and one for writing and switch between these. Otherwise you would get tearing. However, in that case an N64 and a VGA frame need to take exactly the same amount of time (the VSYNC of the N64 and VGA are then sort of "phase locked"). That seems really hard to do.

Perhaps you have any suggestions how to solve this problem. Currently I just use one framebuffer which I write to and read from at the same time. I do not really notice any tearing. That way I can also output VGA that is close to timing specs.

 

As far as I know the HDMI specs just point to CEA-861 for that.

I think the best solution for the N64 would be to horizontally resample the signal to a standard resolution. It's quite far off any standard, so you would need a rather tolerant display to display it as-is and even then there could be aspect-ratio issues.

You don't necessarily need a full frame buffer, just a line buffer since the line rate is still (close enough to) standard. Keeping the timing in sync for both input and output isn't that hard, you just need to ensure that the input and output "processes" run at the correct and constant frequency ratio.

You would need a partial or complete frame buffer if the line-rate or frame-rate is non-standard and you want a standard-compatible output. One example of this is the Gameboy Advance, it refreshes its display about 60 times per second (good), but with a line rate of about 13.something kHz (bad). For that system you would need to buffer a larger part of the image to be able to output it in a monitor/TV-compatible manner, but frame sync would still be possible (but more complicated).

It may be just me, but I tend to not notice tearing if it happens frequenly and always changes its Y-position on consecutive frames. For example the picture below shows three consecutive frames which look horrible in the screenshot (multiple tear lines due to line-tripling and completely async input/output), but were not really notiable to me in motion: (picture spoilered because it's very wide)

Spoiler

When I tried to sync at least the input and output frame rates, tearing suddenly became extremely visible because the tear line always hovered around the same Y position (no capture available, sorry).

(Disclaimer: Certain contents of this post may suggest the existence of currently-unreleased hardware projects. I can currently neither confirm nor deny the existence of such projects. Furthermore, the existence of these contents does not imply any plans for future release of any such projects, existing or nonexisting, by me or anyone else. Do not use the contents of this posting as basis for financial decisions. This posting does not constitute financial advice. Void where prohibited by law. Do not taunt Happy Fun Ball.)

 

I agree.

This is what I have been thinking off as well, but when I thought about how to do it, it seems kind of hard. In one line for the N64 we have 773 pixels (actually there is also a half pixel as well, but let's ignore that). If we would line double it, we would need a VGA clock that is twice as high. Let's say we also want to switch to 800 pixels per line for VGA, so it complies with 640x480 specifications. Then you would need to multiply the N64 pixel clock by 2*(800/773). I do not think a PLL in an FPGA can give you this level of preciseness. Unless it is okay to sometimes give 779 clocks per line and sometimes 801 for instance. Maybe I am overthinking this whole thing?

Also I believe N64 has 263 lines in 240p, so if line doubled we would end up with 526 lines. This is most likely not an issue for most monitors/TVs.

 

That depends on the chip, for example some Lattice chips have PLLs that can use fractional synthesis with 16 bit resolution. This increases the jitter, but that may or may not be a problem. Changing the number of pixels per line would probably work with an analog output since the display would just see a slightly increased jitter on the HSyncs, but my guess is that it would cause lots of problems with DVI/HDMI.

For DVI/HDMI modulating the output pixel clock slightly so that it has the correct value on average may be an option, but I have no idea what the maximum allowed jitter is for those transmission standards. The non-standard pixel clock of the N64 is basically the main reason why I'm not looking into building a digital video solution for it myself and instead wait for someone else to solve these problems.

 

What do you mean with modulating the output pixel clock? Calculating the clock output by using a higher clock?

I noticed the Neo Geo HDMI project does that but then for the Neo Geo clock itself. Here is the code snippet:
[TABLE="class: highlight tab-size-8 js-file-line-container"]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]// Neo Geo Clk Gen[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]////////////////////////////////////////////////////////////////////////[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"][/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]`define NEOGEOCLK_LIMIT (`FULL_WIDTH*`FULL_HEIGHT*5) // 5x as TMDS clock is 5x pixclk[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]`define NEOGEOCLK_ADDITION (`NEOGEO_FULL_WIDTH*`NEOGEO_FULL_HEIGHT*2) // 2x as want 2 transitions[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"][/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]reg [23:0] neoGeoClks;[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]reg neoGeoClk;[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"][/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]initial[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]begin[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"] neoGeoClks=0;[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"] neoGeoClk=0;[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]end[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"][/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]always @(posedge clk_TMDS)[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]begin[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"] if (neoGeoClks>=`NEOGEOCLK_LIMIT)[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"] begin[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"] neoGeoClks<=neoGeoClks+`NEOGEOCLK_ADDITION-`NEOGEOCLK_LIMIT;[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"] neoGeoClk<=!neoGeoClk;[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"] end[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"] else[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"] neoGeoClks<=neoGeoClks+`NEOGEOCLK_ADDITION;[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[TD="class: blob-code js-file-line"]end[/TD]
[/TR]
[TR]
[TD="class: blob-num js-line-number, align: right"][/TD]
[/TR]
[/TABLE]

I tried the opposite: calculating the pixelclock for VGA from the N64 pixelclock. I tried to use a clock as high as possible for the calculation process (so multiply the N64 pixel clock as much as possible). I got it to work at 350 MHz. I took a look at the pixelclock on an oscilloscope and it would jump from 24-26 MHz. The picture showing on screen was still looking fine. I have something weird however, my N64 is PAL and when I run NTSC games (through a flashcard) the framerate is 61 Hz. I think the PAL console has some input frequencies differently. One thing however, the VGA picture was now 61 Hz as well. The N64 frames and VGA frames are not in sync yet however (checked it with signaltap), but I think I did the calculation wrong slightly.

When I finally have my board with HDMI I will give this pixel clock generation a try to see if HDMI accepts the jitter in the clock.

 

Yes. You basically switch between dividing the fast clock by n and n+1 so that the average output clock has the value you want. In some cases you may be able to route that output clock through another PLL on the FPGA to reduce the jitter, I think there is a frequency synthesizer example project for the Spartan 3 starter board that uses this method.

GCVideo uses the same method to generate the SPDIF master clock from the 54MHz video clock which needs a ratio of 128/1154.

Yes, there are a number of consoles that have slightly off-spec video timing when they're switched from 50 to 60Hz or vice versa. On the nfggames forum someone has released a crystal oscillator replacement with switchable output for consoles that need a slightly different master clock frequency for these two video standards. It might be usable for the N64 too.

Random idea: Maybe you could use a completely asynchronous clock source (FPGA board oscillator) for the output and sync up input and output by modifying the length of the VSync pulse? I'm not sure how displays would react to that though and designing with two async clock domains in an FPGA can be a pain.

 

I was thinking of the last thing. The lower the clock you generate the lower the jitter is relatively. I was thinking of generating a pixel clock/2 (perhaps I can go lower, but I can not find it in the datasheet, using cyclone IV FPGA) and then feed it to a PLL to multiply it by 2 again. Not sure exactly how a PLL works, but if it then averages the clock again, the resulting output may have less jitter again, which might make this thing viable as HDMI clock.

I'll give the PLL method a try this weekend. I also need to see if I can get the N64 frames and VGA frames to sync correctly with this method.

Oh yeah, and I will try to swap some oscillators on my N64 at some point.