What would be a good way to change a Gamecube's composite and s-video between NTSC or PAL?
I can rule out these clearly convoluted/expensive options...
A: Chop up a component cable for its MX chip, attach it to a separate encoder, then try to find space to wire everything up to relative Nintendo standards.
B: Swap chips between console models without sufficient documentation to do so.
An external converter from component may be idiot proof, and I'm not a modder myself, except it misses the point. (and again the price )
theclaw wrote:What would be a good way to change a Gamecube's composite and s-video between NTSC or PAL?
I can rule out these clearly convoluted/expensive options...
A: Chop up a component cable for its MX chip, attach it to a separate encoder, then try to find space to wire everything up to relative Nintendo standards.
B: Swap chips between console models without sufficient documentation to do so.
An external converter from component may be idiot proof, and I'm not a modder myself, except it misses the point. (and again the price )
Look up GC-Video. If you already know about it, then I'm confused about what your goal is. It has RGB output capability, which is what I assume you're wanting.
bobrocks95 wrote:Look up GC-Video. If you already know about it, then I'm confused about what your goal is. It has RGB output capability, which is what I assume you're wanting.
I've got a component cable. It shouldn't be too different from RGB.
The idea is to demonstrate successfully switching the color system, and write a mod installation guide to cement that it works for the benefit of the community. Unless of course somebody out there who already achieved said mod in private cares to reveal their handiwork?
Attaching an analog GC-Video to a composite/s-video encoder would absolutely qualify. As long as the assembled unit fits inside the console.
Cutting a hole in the case is easiest and allows for component+VGA plugs if desired.
A more "perfectionist" alternative is neither a hole, or loss of compatibility with official Nintendo video cables. For that you'd route the new composite/s-video signals (plus RGB on NTSC systems) to the multiAV pins (it has enough room, SNES did all three), while keeping the digital port's functions intact.
If you have a display capable of switching between NTSC/PAL colour encoding, then you have a display capable of switching between NTSC/PAL timings, which means there's no point in switching between encodings. Just region mod the console and you can play both PAL and NTSC games on the same display on the same console without any problems.
Unseen wrote:Design a new video encoder chip/board that takes the digital video signals and creates composite and S-Video signals from it.
It was staring right at me, huh. Thank you! The only roadblock is drawing up schematics.
After that, everybody can reproduce the design at their leisure figuratively speaking.
Guspaz wrote:If you have a display capable of switching between NTSC/PAL colour encoding, then you have a display capable of switching between NTSC/PAL timings, which means there's no point in switching between encodings. Just region mod the console and you can play both PAL and NTSC games on the same display on the same console without any problems.
I suppose, I don't think heard of minor glitches in forcing 60hz.
The humorous fringe benefit of getting NTSC consoles working in color on old PAL CRTs that cannot support NTSC timings doesn't matter.
theclaw wrote:It was staring right at me, huh. Thank you! The only roadblock is drawing up schematics.
After that, everybody can reproduce the design at their leisure figuratively speaking.
Some time ago acutally considered building something similar as an april fools joke.
I suppose, I don't think heard of minor glitches in forcing 60hz.
Why are you trying to push the topic in a direction that has nothing to do with your initial question?
Unseen wrote:Why are you trying to push the topic in a direction that has nothing to do with your initial question?
Can't I have a little fun in my own topic? This may be serious technical discussion, but it doesn't have to be all dry and lifeless like a court document.
theclaw wrote:Can't I have a little fun in my own topic?
I don't mind the sarcasm, but I suspect that your initial question is based on incorrect assumptions because you suddenly mentioned glitches when forcing 60Hz.
theclaw wrote:Can't I have a little fun in my own topic?
I don't mind the sarcasm, but I suspect that your initial question is based on incorrect assumptions because you suddenly mentioned glitches when forcing 60Hz.
Glitches when forcing 60Hz are a product of a game's programming.
Which leads into the biggest assumption the initial question is based on: that the color encoding format of a GameCube cannot be changed between NTSC and PAL through software. If that assumption were incorrect, hardware solutions lose much of their purpose.
In the meantime I'll offer a simple alternative I should've been exploring from the start. Attach an NTSC/PAL switchable composite/svideo encoder to the RGB lines of a PAL console. Nintendo already gave us an RGB DAC, why not use it?
theclaw wrote:Glitches when forcing 60Hz are a product of a game's programming.
Which leads into the biggest assumption the initial question is based on: that the color encoding format of a GameCube cannot be changed between NTSC and PAL through software.
This assumption as stated is correct. However, I still don't see the point of your planned modification - if you don't use software like Swiss to force the video mode of a PAL game to 60Hz, it will run at 50Hz no matter if you use a PAL or NTSC cube. So why would you want to use a PAL cube and modify or transcode its output to get NTSC50 if you can already get that from an unmodified NTSC cube running the same game?
As you can see, getting NTSC resolution and 60Hz or PAL resolution and 50Hz is possible on both cubes, the only difference is the colour encoding for composite/s-video. However, since RGB doesn't have colour encoding, an NTSC game on a PAL cube displaying in RGB (or component) is pretty much NTSC output. Because of this, a PAL cube running RGB is a very good "universal" solution for 240p/480i RGB, although if you are using the digital output, then PAL vs NTSC doesn't matter because you can get PAL or NTSC resolution/framerate out of both consoles.
There are some minor timing differences doing NTSC output from the PAL console as I understand it, but I don't think that they would matter unless you're getting into really off-spec stuff like GBI-ULL's weird framerate.
Guspaz wrote:There are some minor timing differences doing NTSC output from the PAL console as I understand it, but I don't think that they would matter unless you're getting into really off-spec stuff like GBI-ULL's weird framerate.
As far as I know the timing should be identical on PAL and NTSC system - a 13.5 MHz pixel clock works for both and all the clocks in the Cube happen to be integer multiples or fractions of 54 MHz (=4 * 13.5)
Unseen wrote:This assumption as stated is correct. However, I still don't see the point of your planned modification - if you don't use software like Swiss to force the video mode of a PAL game to 60Hz, it will run at 50Hz no matter if you use a PAL or NTSC cube. So why would you want to use a PAL cube and modify or transcode its output to get NTSC50 if you can already get that from an unmodified NTSC cube running the same game?
For me personally, success is the point. I achieve nothing other than the satisfaction of owning the world first cube able to be NTSC50, NTSC60, PAL50, or PAL60, no unsightly external box required.
But it has a few rare applications others might enjoy. For instance owners of NTSC-only TVs (where PAL60 will turn black and white) could play 60Hz games on a PAL cube in NTSC60, with the convenience of not having to force the additional languages like on an NTSC cube.
Guspaz wrote:As you can see, getting NTSC resolution and 60Hz or PAL resolution and 50Hz is possible on both cubes, the only difference is the colour encoding for composite/s-video. However, since RGB doesn't have colour encoding, an NTSC game on a PAL cube displaying in RGB (or component) is pretty much NTSC output. Because of this, a PAL cube running RGB is a very good "universal" solution for 240p/480i RGB, although if you are using the digital output, then PAL vs NTSC doesn't matter because you can get PAL or NTSC resolution/framerate out of both consoles.
Do you have any recommendations for off the shelf RGB to NTSC/PAL encoder ICs, small enough to put inside the console?
theclaw wrote:For instance owners of NTSC-only TVs (where PAL60 will turn black and white) could play 60Hz games on a PAL cube in NTSC60, with the convenience of not having to force the additional languages like on an NTSC cube.
Ok, serious question: What would be the difference between a PAL cube with NTSC video encoder and an NTSC cube with a PAL IPL ROM?
theclaw wrote:For instance owners of NTSC-only TVs (where PAL60 will turn black and white) could play 60Hz games on a PAL cube in NTSC60, with the convenience of not having to force the additional languages like on an NTSC cube.
Ok, serious question: What would be the difference between a PAL cube with NTSC video encoder and an NTSC cube with a PAL IPL ROM?
I'm not sure. If I may take a wild guess...
An NTSC cube with a PAL IPL ROM is a freaky hybrid. s-video and European languages (at the expense of Japanese), yet still invalid color in 50Hz mode.
So use an HD Retrovision component cable with your PAL console. No external box, no PAL colour encoding for NTSC games.
Unseen wrote:As far as I know the timing should be identical on PAL and NTSC system - a 13.5 MHz pixel clock works for both and all the clocks in the Cube happen to be integer multiples or fractions of 54 MHz (=4 * 13.5)
My understanding was that the PAL and NTSC cubes had a subtly different pixel clock such that a PAL cube outputting 240p60 would result in different timing than an NTSC cube outputting 240p60. At least this was the answer I got from somebody (Extrems, I think?) when I had wondered why GBI-ULL would sync perfectly fine on my projector using an NTSC cube, but wouldn't sync right coming from a PAL cube. I can't find the original source for this, and I ended up finding that my projector is perfectly happy to accept GBI-ULL over HDMI using an OSSC with passthrough or 4x modes, so it became a moot point.
I... don't understand. You seem to admit that this mod is useless and serves no purpose, but at the same time you want people to help you do it? I'm confused.
Guspaz wrote:I... don't understand. You seem to admit that this mod is useless and serves no purpose, but at the same time you want people to help you do it? I'm confused.
I don't think this line of discussion will end well. May we agree our opinions are different before it degrades to an argument?
Getting back on track, the familiar jrok encoder looks good for adding NTSC composite and s-video to a PAL cube. A pre-assembled board to wire in, output connectors included. Ideally with a sync cleaner since PAL cubes lack c-sync. http://www.jrok.com/hardware/RGB.html