I apologize ahead of time if I'm not posting this in the right area. I had a quick question that's been on my mind: Here's the scenario: Say I have an NTSC PS1 connected to an NTSC consumer TV using an RGB SCART to component converter. The PS1 has a mod chip to enable me to play games from other regions. Here are my questions: Can I play a PAL game on my NTSC TV with no issues? Will the game run at 50HZ? Will I have issues with color? My guess is the color won't be an issue because RGB is RGB so it won't use a PAL color space but I'm curious if I'll run into other issues. Thanks! ~ FiZiX
Hy FiZiX, Here is a good conversation on this matter: https://assemblergames.com/threads/...pal-ps1-ps2-and-vice-versa.68051/#post-960645
Sorry but that didn't quite answer my question. They're talking about playing NTSC games on a PAL console where as I'm asking about playing PAL games on NTSC console. I did see this quote: But I'm curious if this affects RGB output via SCART or just composite output? Can someone with experience chime in?
From what I've understand only the composite output is affected. But for a better clarification you can talk with TriMesh or maybe he will post here; he is very knowledgeable in this matter.
This is important in terms of whether your TV supports 50, 60hz or both. I have used my PAL PSX to play NTSC games on a TV which supports 60hz and the picture is black and white over composite, but colour over RGB.
RGB will display in colour no matter what. NTSC -> PAL, PAL -> NTSC, it doesn't care - but composite is where you'll run into issues. I'm not sure how the difference in frequency will affect things though, I've been lucky in that all of my TV's came from Japan and could handle 50/60Hz signals, so it's never been an issue for me.
The subcarrier only matters for encoded formats like composite and Y/C - it's not used with an RGB connection. One other thing to watch is that if you want to use a CRT the vast majority of US spec CRT TVs were 60Hz only, although 50Hz support is better on flat screens.
Okay, thanks. I guess I'll just have to try it and see. I have a Sony Trinitron produced around year 2000. I doubt it supports 50Hz.
Highly unlikely your trinitron can do 50hz but if you had a wega sdtv there's a very good chance of it working.
So is there a way to make it run at 60Hz by using a different oscillator? Or would that screw up the timing in the game?
If your using original games then I don't think it will work as the games would need to be patched to 60hz. If you have a hdtv there's a good chance it can do 50hz but then again it would have to support component 240p.
Only by patching the game to make it run in 60Hz mode - and in that case you won't need another oscillator because your NTSC console already has the right one. Note that depending on how the game was localized for PAL in the first place this may or may not work well - some games took the lazy approach of only rendering 240 lines per frame and these look fine running at 60Hz (in fact, better than they do in PAL mode) - but some games actually expanded the image size to use the additional scanlines offered by the PAL format and these will display with part of the image clipped off. If possible, try and get a TV than can handle 50Hz. Unless it was a special order multi-standard TV, it's extremely unlikely that your 2000 vintage US market Trinitron will be able to.
Thanks for your reply. I actually have a TV that can handle PAL but it doesn't have RGB inputs. I was going to sell it but I guess I could hang on to it for the occasional PAL game via S-video.
Sorry to ask you this TriMesh but why RGB doesn't have this restriction for consoles that support it? It is because of the nature of RGB signal to be the true signal of the consoles? I want a technical explication if you can. Thanks!
It's because the color encoding formats like NTSC, PAL or Y/C encode the color difference signals on a very precisely defined carrier frequency. The way the encoding works is that there is a reference burst of the color carrier at the start of each line and the decoder in the display locks onto this and uses it as a phase reference for decoding the color. If the frequency is too far away from the nominal one, then the oscillator inside the display will not be able to phase lock to it and hence will treat the input signal as being black and white. RGB doesn't have a color burst because it's not encoded and hence as long as the line and frame rates are close enough to allow the display to lock to the video it will give a correct image. The error introduced by the use of the wrong clock oscillator for the video mode is about 1% - small enough for the line and frame rates to be acceptable to the display, but at the same time too large for the color decoder to lock up.
