playing ntsc games on pal ps1-ps2 and vice versa

I was wondering if there are any games that suffer from compatibility issues if played on a (modded) console from a different region. I'm asking that on behalf of a friend, who has a big ps1-ps2 game collection (both pal and ntsc), but has only pal machines to play at, since we live in a pal region country (Greece).
He started considering this, after reading someone stating that the pal cpu and gpu on ps1 consoles, are clocked for PAL signals. Also, ntsc games force those components to run at a higher hz rate that wasn't designed to work at. Is that statement true?

 

It's a real problem, but it probably doesn't affect that many games.

From memory it's mainly rhythm games like Dance Dance Revolution that get upset if you run the NTSC versions on a PAL console & for a long time there were no PAL versions. There were some unofficial patches released for some games.

 

The short answer is that the NTSC and PAL versions have the same chips in them, but slightly different clock frequencies. For example, the PS1 has two different clocks - for a PAL unit they are:

CPU: 67.7376MHz (the actual CPU core is clocked at half this rate)
GPU: 53.203425MHz (selected because it's 12x the 4.43361875MHz PAL color subcarrier)

In a NTSC console:

CPU: 67.7376MHz (same as the PAL one)
GPU: 53.693175MHz (this is 15x the 3.579545MHz NTSC color subcarrier)

So the actual difference is quite small - about 0.1%. When you put a PAL console into NTSC mode, the chip switches over into its 60Hz operating mode, but it's still being clocked using the same 53.203425MHz crystal it was using in PAL mode. As a result, it runs slightly slow.

For most games, this simply doesn't matter and although there is slowdown it's imperceptible to the person playing the game. A more subtle effect is that it also introduces a timing skew between timescales based on the CPU clock and ones based on counting vblanks - the Konami rhythm games smf mentioned are a good example; they have an audio track that's locked to the CPU clock (the SPU is clocked from the same source as the CPU) but the visuals are synchronized to the display refresh so the timing gets more and more out of sync with the audio as you play the game.

 

As for the PlayStation 2:

PlayStation 2 consoles do not have this problem with PlayStation 2 titles, although early models (before G-chassis) seem to be more specialized in either signal format. i.e. an early NTSC set may not output PAL with the exact same characteristics as a native PAL set, although honestly I could not see a difference.
But either way, PAL will still be PAL, NTSC will be NTSC.

PlayStation games on the PlayStation 2 will have a problem with the console's PS1DRV program using its native video mode (i.e. NTSC set will always use NTSC). So if you boot a PAL game on a NTSC set, you will get letterboxing and the game will run faster than normal.
Other than using certain modchips (which will likely also solve things in software), you can use PS1VModeNeg if you want a software-only approach.

 

Thank you all for your input. You were more than helpful on my query
My friend isn't interested in rhythm games, so a pal machine is fine. Let's hope we won't run on any RPG or shmup title that has timing issues..

 

@TriMesh didn't saw that slowness in games and it's the first time I read this.
From what I've understand disc consoles like PS1, PS2, GC, WII, region PAL or NTSC will play the games in the correct mode because the games change the video signal and not the console like the cartridge based NES, SNES, N64, SMS, MD...
Only on a PAL DC if you put a NTSC game on the console will be played in PAL mode (tested by me).
I didn't test the rest of the consoles based on discs.
Please correct me if I'm wrong.

@snobgamergr I can guarantee you that you will not have timing issues.
I have PS1 SCPH-102 and PS2 SCPH-77003/4 and SCPH-90004 plus GameCube PAL and I play on them only NTSC games and I don't saw any timing/speed issues or any problem about incompatibility.
Like a general rule, from my point of view it's not recommended to play games on compatible consoles, for example PS1 on PS2, PS1 on PS3, GC on WII etc.

 

You probably won't see it on most titles on the PS1 - it's running at almost the correct frequency, just not exactly correct. Yes, the game switches the hardware over to 60Hz mode, but it's still being clocked at the correct rate for the 50Hz mode, and so there is a slight timing error.

I've modified some of my PS1 consoles to include both clock oscillators (interestingly, the GPU has separate inputs for the PAL and NTSC clocks and they are just tied together on the board) - this makes NTSC titles run at exactly the right speed and also fixes the composite and Y/C outputs on the earlier boards (up to PU-18). On the PU-20 and later, it fixes the game timing, but the video is still output in a non-standard format due to the way the subcarrier clock is derived.

In fact, a lot of the older consoles are like this - systems like the SNES, Master System and Megadrive have chips you can switch over between 50 and 60Hz mode, but will be slightly off frequency in the wrong mode (the Megadrive actually uses the same clock frequencies as the PS1, 53.203MHz and 53.693MHz for PAL and NTSC respectively) .

The Dreamcast is a special case because the video hardware is designed to be universal - both the NTSC and PAL consoles are entirely capable of generating correctly timed PAL or NTSC signals. The only hardware difference is that the PAL console has a jumper that forces the video encoder to always generate PAL encoding using a 4.43MHz subcarrier. The effect of this is that games that have no 50Hz support will run in PAL60 rather than NTSC (probably because this was much more widely supported by EU spec TVs back when the DC came out).
Apart from this, the video mode is basically controlled by the game and selected according to the region code in the EEPROM. This shows up most clearly with some 1st party titles - for example, if you run the Japanese version of Chu Chu Rocket on a Japanese console then it boots up into 60Hz NTSC mode. If you boot the same disc on a PAL console then it displays a selector asking if you want to run in 50 or 60Hz mode.

 

The only real problem I can think of is that running NTSC PS1 games on a PAL system can theoretically throw newer displays off due to the timing differences.
Using this setup with an XRGB-mini will cause stuttering, incorrect scanline alignment and for some reason a brighter image.
This can be fixed on a PS1 by using the ‘dual frequency oscillator’ mod like trimesh mentions. And on a PS2 with ‘PS1VModeNeg’ like sp193 suggests.

Both methods work fine, although I could never get the latter method working on my PAL PS2 using other than a DMS4 modchip. Tried with a Modbo and Ghost prior to the DMS4.

If your tv correctly displays the image already you have nothing to worry about. The difference in timing is so tiny that you will never know the difference.

 

@TriMesh the "dual frequency oscillator" mod is recommended only on PS1? What about the PAL PS2, GC, WII? They work differently than PS1?
Another question, what PS1 games did you find to have problems with the timings?
I see that you are knowledgeable in this matter.
By the way I live in PAL area and my CRT TV (Sony Trinitron) support both PAL and NTSC signal; on all my consoles (that support) I use only RGB.

Thanks!

 

On the PS2 it's a little bit complicated - the clock on the GS has to change between PAL and NTSC modes but the way this is handled changed during the production run - on the early machines (SCPH-3000x, for example) this clock is derived from an oscillator connected directly to the GS, and will always run at whatever frequency the home region uses. On the later models (like SCPH-3900x), it's derived from a clock synthesizer and the console can select the correct clock for the mode. Having said that, the stock ROM typically doesn't support mode changes and you have to trick it either with a mod chip or with code. So if you have a reasonably late PS2 and a mod chip then it should run at the right speed.

The difference between the PAL and NTSC gamecubes is the IPL - the actual hardware is programmable. Same with the Wii.

Some games that have problems with the slight clock error are the Konami rhythm games like Beatmania and Dance Dance Revolution - the video an audio slowly gets more and more out of sync, which makes the games very hard. There are patches for these.

Another one is if you try to run Wipeout in link mode between a real NTSC console and a PAL console with a mod chip you find that it loses sync because of the time slips - adding the dual oscillator to the PAL console allows it to work.

If you are using RGB on a CRT TV, then you can pretty much ignore the timing errors - the out of spec subcarrier won't matter because you aren't using composite or Y/C and CRTs are very tolerant of frame timing errors.

 

I took a look at the service manuals again and I don't know how I determined that something was changed at the D-chassis. I will update all applicable posts from myself, thanks.

But I didn't notice a change in provided clock input, even between the NTSC and PAL regions. Usually, it is some minor change in parts instead (i.e. to adjust YTRAP). Does the clock generator's input really change between NTSC and PAL models, between A-F chassis?

To add on, this limitation with the PS1DRV program is only a problem when playing PS games on a PS2. All ROMs support the same set of documented video modes.

 

The clock switches between 53.9MHz and 54.0MHz - on the earlier machines it was sourced from a separate oscillator and was simply whatever was soldered to the boards - on the later ones it's derived from a clock synthesizer. For example, on the G chassis the clock is derived from IC106 which is clocked using an 18.432MHz xtal in all regions, but the GS clock frequency is selected between 53.9/54MHz using a signal driven by pin 3 of the SS BUS interface chip IC501.

I'm pretty sure the main clock generator (the one that generates the 400MHz EE clock) is the same on all consoles and has been clocked using an 18.432MHz xtal on every unit I've ever seen, PAL or NTSC. It's just the GS clock that changes.

Edit:

This bit is not PS2 releated, but if anyone is interested in adding a dual oscillator setup to a PS1 this is a description of the process I wrote some time ago - it's written with reference to a PU-18 board (SCPH-55xx), but the same principles apply to other models.

 

Didn't try that mod for PU—18, but PU—8 mobos sometimes have pads for another oscillator. Thanks for your guide on psxdev. I were able to upgrade two of my PU—8 that way. Also I changed default PAL BIOS to NTSC cause it looks more smooth on the boarders. Cause of NTSC of course.
I have many things to ask @TriMesh but due to the thread I wanted to ask one. It's about later boards with 14.318Mhz NTSC and 17.xxxMhz PAL as base clocks that goes on CYxxxx500 and CYxxxx509 programmable clock multiplier and after that to the system IC's. That means there is no way to make Dual Oscillator mod to be able to switch "on the fly" by software (like PU—8 and PU—18 mod did). It needs to be turned off to be able to select input clock, isn't it? The more important question for me is about these clock multiplier CYxxx500 and CYxxx509. Is there any way to reflash it's EEPROM (or it's ROM out there?). Any software suitable for that? There is a Dual Frequency Oscillator mod project ready to build (gerber files and it's software part), for now I think that is the only way to make PAL PSOne bacame NTSC (except MECHACON of cource, that's not a big deal for me what strings display at the boot screen). I have a lot pf PAL PS1 and much more PS1 from Japan. Wanted to make PAL output NTSC signal at least or if I get lucky make them all dual. Wanted to ask few questions about PS1 in PM, if I may, TriMesh?
Thanks for reading.
P.S. Sorry for CYxxx500/509 and all that, I'm pretty far from my computer now and datasheets on it.

 

OK, the chips used in the clock generation for the PU20 and later are mask programmed and you can't change the divisors.

You can still add an additional oscillator because the GPU chip actually has two different input pins, one for NTSC and one for PAL - so you can just leave the existing oscillator wired to the relevant pin and wire the additional one to the other.

The other difference between the PU-7 to PU-18 design and the PU-20 to PM-41 one is the way the subcarrier for the video encoder is generated - on the older boards, it was generated inside the GPU by dividing down the PAL or NTSC clock signal depending on the selected mode - this is the reason the color encoding didn't work on a retail console when set to the wrong mode since the source clock for the divisor was wrong and hence the subcarrier frequency was also wrong.

On the later console design, the subcarrier is directly generated by dividing down the master clock xtal and comes from the clock synthesizer chip - the practical result of this is that it doesn't change when the console changes modes and will always run at the frequency of the native video mode.

For a PAL console, this is not too bad - the PAL subcarrier is obviously correct for PAL and when you switch the console to NTSC mode it generates a 60Hz frame rate signal with NTSC encoding but a 4.43MHz subcarrier - which happens to match the format that some multi-standard PAL VCRs used to use when playing back NTSC tapes (aka "NTSC 4.43") - you can also hardwire the encoder to PAL mode in which case it will generate either PAL or PAL60 - which is a format that also has reasonable support.

For the NTSC boards, it's not so good - they will always generate a 3.58 MHz NTSC subcarrier, and when switched to PAL mode the result is something that could be called "PAL3.58" - except that it's not a format that was ever used for anything and hence nothing will actually recognize it - you can also strap the encoder to NTSC mode and make it generate "NTSC50" - but this also not a format that was ever used.

If you have any other questions, feel free to PM me - or just post it here in case it might be stuff other people are interested in.

 

Sorry to bump this thread, but I find the topic really interesting and wanted to respond to a few points TriMesh raised.

When I looked into this years ago I was surprised to find that PAL Dreamcast's actually don't have any additional jumpers connected. I guess there is no need for any of the jumpers to be used since the SH4 has the ability to toggle the video encoders region over three pins (labelled tvmode0/1/2 on the schematics) which toggle between three different versions of PAL (PAL, PAL-M, PAL-N) As you stated the Dreamcast stores the region in the 1Mbit flash memory, so it seems the SH4 defaults to NTSC unless the region flag in the flash is set to one of these PAL regions, in which case it pulls low one of the three 'tvmode' pins on the video encoder.

There is a common mod to improve compatibility with certain PAL games when played on NTSC Dreamcast systems, whereby you solder a jumper on an unused pad labelled R422:-
http://www.mmmonkey.co.uk/dreamcast-ntsc-pal-r422-mod/
This mod basically forces the video encoder into PAL mode, which improves compatibility with certain PAL software (For instance the PAL DreamKey internet browser disk is 50hz only and displays with a distorted image on NTSC consoles unless you solder a jumper on R422)

Well the GameCube IPL is a mask ROM, so it cant actually be programmed if thats what you meant? Also PAL and NTSC GameCube motherboards differ considerably in their video circuitry, with each having a region specific video encoder. The NTSC encoder supports Composite Video and S-Video, whilst the PAL encoder supports Composite Video and RGB.

I'm no expert on the PlayStation models, so am curious to know if the later PS2 models can definitely switch between the 54Mhz and 53.9Mhz clocks? From looking at the PS2 service manuals it appears the change occured with the F-chassis GH-015, which was the first model to feature the IC106 clock synthesizer, and also the first to use the 3rd revision "CXD2949GB" GS chip. (Although you do have to ignore the strange D-chassis GH-016 revision, which continued to use the old GS chip and separate oscillator - presumably to use up all of Sony's stock of the older GS chip. From the G-chassis GH-017 onwards they do all use the newer clock synthesizer)

Also you mentioned that the PS2 stock ROM doesn't support mode changes, but I wondered if softmods can bypass this limitation?

I was looking at the SCPH-7500 PU-22 service manual and it does appear that although the video encoder now recieves the subcarrier directly from the clock multiplier, the GPU still has the subcarrier output "FSC" on pin 153 but its unused/not connected, so presumably if you turned resistor R501 around 90degrees and then soldered a wire from one end to GPU pin 153 you could also restore the region switching subcarrier signal that was missing from PU18 onwards?

 

They don't have additional jumpers - they have different jumpers - one version has R422 installed and the other has R423. Note that since they are resistors the console can still override the settings if it wants to.

I never liked this mod, precisely because the TVMODE lines are bidirectional - if you follow the Sega approach of just pulling them high or low using a resistor the console can still drive them the other way. Shorting out R422 will cause output contention if the software tries to drive the pin the other way.

You can override the IPL with a mod chip (or even using certain software hacks) and the CPU and GPU are the same - if you get a PAL GC and tell it to go into NTSC mode using one of these methods then you get a correct NTSC signal. Yes, the video output circuits are different, but that just affects what sort of monitor you can connect, not the sort of signals it can output.

Well, I'm not going to claim that I've gone through every chassis revision and verified that they have the clock switching hardware, but all the ones I've looked at that were F-chassis or later had the capability. A softmod certainly should be able to switch it over, but I can't say for sure if they actually do. Some of the modchips definitely know about this signal, since you can see the control line on the clock synth switch over when you boot a 50Hz game on a 60Hz console.

The "not supporting mode changes" also depends on the revision of the boot ROM - the firmware for the various region PS2s converged as time went on, and the slims used a "world ROM" that had code to support all modes and just enabled the correct ones for the console territory.

This works, but you have to appreciate the reason they changed the design in the first place. The pre PU-20 board used a crystal oscillator with good spectral purity to generate the GPU clock, so when you divided it by 12 or 15 (depending on mode) to get the sub-carrier signal it was extremely clean (since a divider reduces the phase noise by 20log(N) dB where N is the division ratio).

On the PU-20 and later, this clock signal was derived from a PLL multiplier, which generates a much dirtier signal than an xtal (especially when you consider it uses a 20 year old clock synth chip), so they picked a master clock xtal that was an exact multiple of the desired subcarrier frequency and directly divided that to get Fsc - the jitter was still on the GPU clock, but that's a much less critical parameter.

So you can do it, but if you do I would recommend replacing the synthesizer for the GPU clock with a more modern one with better spectral purity (or just adding a pair of xtals if you can find them...).

 

check my last thread , maybe you can help me ?

 

which one because you posted the same thread 3 times

 

pick the one you want , they are all the same.... I want to find solution.... im desesperated

 

And that's why I dont feel like I should help you. Dont make 3 duplicate threads