PlayStation Development Network

When Sony designed the PSX GPU, it had provision for operation in both PAL and NTSC modes, and had a separate clock input for each mode. However, the retail consoles had regional lockout and were only capable of playing software from their region, and hence only in one video mode.

As a result, Sony laid out the board to only accept one oscillator, and installed the correct one for the video mode the console was supplied to work in. This has the result that when you switch the console to the other mode, it produces an out of spec signal, which doesn't display properly due to the frequency error in the color subcarrier, and which also runs about 1% slow or fast depending on what the native mode of the console was.

This modification describes how to modify the PU-18 board to include both reference oscillators - after the mod, the console will produce both correct PAL and correct NTSC signals - since the GPU already has two clock inputs, no manual switching is required.

Note that about the only source for the oscillators I have found is on PSX boards, so effectively you need both a PAL and an NTSC console to do this.

Hi, nice tutorial there. Just one quick question. I have a broken PU-7 board can i take the oscillator and swap it to my (SCPH-1002) PU-8 board ? Do i need to swap the resistor too?

ady05113 wrote:Hi, nice tutorial there. Just one quick question. I have a broken PU-7 board can i take the oscillator and swap it to my (SCPH-1002) PU-8 board ? Do i need to swap the resistor too?

Yeah, you need the resistor, RF choke and caps - but depending on which PU-8 model you have there might already be spaces on the PCB for both sets of color reference oscillators.

Take a look at the board, and see if there are extra pads next to the installed oscillator on the board - if there are, take a photo and I will indicate the needed components.

Take a look at the board, and see if there are extra pads next to the installed oscillator on the board - if there are, take a photo and I will indicate the needed components.

Thanks for a fast reply. Here is some images i take just now. Hope you can clarify which part i need to swap to.

NTSC (PU-7) :
http://i.imgur.com/LGHyIMo.jpg
http://i.imgur.com/MZaBye7.jpg
http://i.imgur.com/qZ6KNMm.jpg

PAL (PU-8) :
http://i.imgur.com/WguhJ14.jpg
http://i.imgur.com/xNe2iIu.jpg
http://i.imgur.com/M8ee0tG.jpg

OK, you have the right board to install the PAL/NTSC mod using the traces already on the board.

The mod is pretty simple - you just remove the oscillator module and the 3 SMT parts just above it and them install them on the PU8.

The cap goes on the back of the board and you also need to remove a zero ohm link that connects the PAL and NTSC clock inputs on the GPU together - this is on the back of the board just behind where the oscillators are

I've attached some marked up versions of your photos - hopefully they make sense, but if not feed free to ask.

Omg @TriMesh. You make it look sooooo easy! The picture you attached can be understand easily. It shows everything what to do. Thank you so much. I'll let you know when i finish swapping them all.

***Edited***
Finished swapping the oscillator and resistor.



Here is the results. NTSC games in colour!

Very nice work Ady!

Yeah, the mod is simple if you have the correct PU-8 to do in on - which luckily you did (the early PU-8 version with the old GPU and VRAM doesn't have those pads). The approach I used on the PU-18 in the document posted in this thread is electrically the same, but more fiddly because the PU-18 only has the space for one oscillator.

The other nice thing is that now it runs at the correct speed in NTSC mode (a PAL console in NTSC mode with the original oscillator has line and frame rates that are about 1% slow - not much, but annoying once you know about it).

Shadow wrote:Very nice work Ady!

Thank you sir. I'm so happy joining this forums and get support from great members and developers.

TriMesh wrote:The other nice thing is that now it runs at the correct speed in NTSC mode (a PAL console in NTSC mode with the original oscillator has line and frame rates that are about 1% slow - not much, but annoying once you know about it).

As long as it plays in colour that good enough for me. Hate to play in black and white lol. Thank you for helped me out. But first i must buy you a cup of coffee. It that okay?

ady05113 wrote: As long as it plays in colour that good enough for me. Hate to play in black and white lol. Thank you for helped me out. But first i must buy you a cup of coffee. It that okay?

Sure, but there could be some practical problems - like the fact that I'm in Hong Kong

TriMesh wrote:The other nice thing is that now it runs at the correct speed in NTSC mode (a PAL console in NTSC mode with the original oscillator has line and frame rates that are about 1% slow - not much, but annoying once you know about it).

It's more than annoying, if you play Japanese DDR games on an PAL console then there are timing errors. Back in the day people used action replay codes for timing fixes. I don't know if anyone ever tried adding an extra oscillator.

smf wrote:

TriMesh wrote:The other nice thing is that now it runs at the correct speed in NTSC mode (a PAL console in NTSC mode with the original oscillator has line and frame rates that are about 1% slow - not much, but annoying once you know about it).

It's more than annoying, if you play Japanese DDR games on an PAL console then there are timing errors. Back in the day people used action replay codes for timing fixes. I don't know if anyone ever tried adding an extra oscillator.

Hi, from what i read PAL console will display full colour when using RGB SCART cable without need to add extra oscillator or colour correction module for NTSC Games. Is that true? If yes how is the framerate? Does it dropped by 1% too?

AFAIK, RGB is RGB. There is no NTSC/PAL war there.

See this:
http://www.analog.com/en/audiovideo-pro ... oduct.html

And this:
http://www.eecg.toronto.edu/~tm3/ad722.pdf

RGB to component:
http://www.linear.com/solutions/1311

So in general... yeah, shouldn't be any difference, but if you are still in doubt, it would be easier and cheaper to get a 2nd hand NTSC PSX.

ady05113 wrote:Hi, from what i read PAL console will display full colour when using RGB SCART cable without need to add extra oscillator or colour correction module for NTSC Games. Is that true? If yes how is the framerate? Does it dropped by 1% too?

Yes, the timing is slightly wrong if you play NTSC games on a PAL console that uses the original oscillator for PAL/NTSC, no matter how it is displayed. You don't notice it in most games, but it's there.

Some of the debug consoles don't have the oscillator hooked up to both inputs, so if you display the wrong one then you get no image at all.

smf wrote:Some of the debug consoles don't have the oscillator hooked up to both inputs, so if you display the wrong one then you get no image at all.

This is true for some NTSC retail consoles, too - I've had a couple of SCPH-1001s that would simply lock up when you selected PAL mode (they stopped generating VSYNC). If you look at the back of the PU-8 board where the oscillators are (same place that's in the photos I posted above) there are two zero-ohm link positions - the one in that photo is for the PAL consoles, but the NTSC ones don't have that - they have a link installed in the position to the right which just grounds the PAL clock input on the GPU.

You can fix the lockup problem by moving the link to the same position it's in on the PAL units - although obviously installing both parts is a better solution if you have them available.

TriMesh wrote:This is true for some NTSC retail consoles, too - I've had a couple of SCPH-1001s that would simply lock up when you selected PAL mode (they stopped generating VSYNC). If you look at the back of the PU-8 board where the oscillators are (same place that's in the photos I posted above) there are two zero-ohm link positions - the one in that photo is for the PAL consoles, but the NTSC ones don't have that - they have a link installed in the position to the right which just grounds the PAL clock input on the GPU.

Is there any pattern to it or is it random whether an NTSC console will have NTSC & PAL clocks linked?

I think the reason that PAL consoles always have the NTSC & PAL clocks linked is because the GPU boots in NTSC mode. I have an LCD TV that detects PAL consoles as NTSC.

It's hard to tell - I haven't really seen enough of them to reach a clear conclusion.

What I have figured out is this:

PU-7 and PU-18 have both inputs linked. So do PU-20, PU-22 and PU-23 (they have different clock circuits, though).
The early PU-8 with VRAM has both inputs linked.
The later PU-8 with SGRAM has the inputs linked on the PAL units, but in most cases the PAL input is grounded on the NTSC machines. I have seen a couple of later production units that had the link in the same place as the PAL machines (they both had the new CPU, but I don't know if this was a pattern or just a coincidence).

The NTSC clock input has to be present, or the chip simply won't work - I suspect this is also the clock for the majority of the internal logic, and the only thing the PAL clock does is generate the subcarrier frequency and PAL video timing.

I have been unable to find any negative effects from running both clocks from the NTSC oscillator (and this is what the PU-18 does, so I guess Sony came to the same conclusion).

TriMesh wrote:The NTSC clock input has to be present, or the chip simply won't work - I suspect this is also the clock for the majority of the internal logic, and the only thing the PAL clock does is generate the subcarrier frequency and PAL video timing.

I suspect that the chip defaults to NTSC and without the NTSC clock it doesn't work enough to be able to switch to PAL, where the PAL clock takes over completely.

Hello everyone.
PS1 SCPH-5000 PU-8. I did it and it works great. Thanks.

I'm just converting the SCPH-5903 with PU-16 board to PAL. For getting the PAL colors, I've just wired a 4-pin 4.43361875MHz oscillator to the RGB-to-Composite converter, ie. about as described here: http://www.psxdev.net/forum/viewtopic.p ... =444#p4751
The advantage is that that oscillator is cheap and widely availbale, and that it's always producing PAL colors, no matter if the console is in 50Hz or 60Hz mode (my TV set supports both frame rates and does even adjust the pixel aspect ratio accordingly, but it can't handle NTSC color encoding).

Instead of installing a second 53.xxxMHz oscialltor on the GPU side, I've just shortcut the two GPU clock inputs with each other (thanks for pointing out that the "not connected" input is GNDed via a 0 ohm resistor hidden on the PCB bottom side, without removing that resistor it wouldn't work too well). The timing is good enough for me. But having the exact PAL and NTSC clock source might be useful in some cases (like bug-testing a game for both regions, or avoiding compatiblity issues in some import games).

smf wrote:I suspect that the chip defaults to NTSC and without the NTSC clock it doesn't work enough to be able to switch to PAL, where the PAL clock takes over completely.

I would have thought so, too. But then, I've just tested some things, and the GPU doesn't seem to be completly dead when not having the PAL clock in PAL mode (so either it's still using the NTSC clock for certain things, or it's doing those certain things via some other clock, like the CPU clock).
My test results for PAL mode without PAL clock are...

Things that don't work so well:
-- Screen goes black, no picture is shown
-- Gpustat.bit31 is no longer toggled (so a "waitvblank" function that waits for that bit to change will hang)

But what is still working is:
-- Switching back to NTSC mode does still work (I've waited some million cycles in PAL mode, and then restored NTSC mode)
-- Vram-to-Vram transfer via GP0(80h) is still working (of course, not visible due to black screen, but becomes visible when restoring NTSC mode).