PS1:Video Output Notes: Difference between revisions

From ConsoleMods Wiki
Jump to navigation Jump to search
(A somewhat rambling description of the PSX clocking and video generation)
 
m (Forgive me - removing "PSX" name since this site also contains info about the PSX DVR)
Line 1: Line 1:
The video subsystem on the PSX works in sometimes confusing ways, especially if you are running software that uses a video standard different from the one that the console was intended to operate in. In addition to this the behavior changed slightly between the PU-7/PU-8/PU-18 board and the PU-20 and subsequent boards.
The video subsystem on the PS1 works in sometimes confusing ways, especially if you are running software that uses a video standard different from the one that the console was intended to operate in. In addition to this the behavior changed slightly between the PU-7/PU-8/PU-18 board and the PU-20 and subsequent boards.


To make sense of this, you need to look at how the clocking in the PSX works - there are two basic clock sources, one for the CPU and one for the GPU.  The CPU clock source is the same across all models and regional variants and is always 67.7378MHz - the actual CPU is clocked at 1/2 of this and this somewhat strange looking frequency was chosen so it could also be used for the sound subsystem as it's an exact integer multiple of the 44.1kHz CD sampling rate.
To make sense of this, you need to look at how the clocking in the PS1 works - there are two basic clock sources, one for the CPU and one for the GPU.  The CPU clock source is the same across all models and regional variants and is always 67.7378MHz - the actual CPU is clocked at 1/2 of this and this somewhat strange looking frequency was chosen so it could also be used for the sound subsystem as it's an exact integer multiple of the 44.1kHz CD sampling rate.


The GPU clock is about 53MHz, with the exact frequency changing between NTSC and PAL - NTSC uses 53.693(18) Mhz and PAL uses 53.203425 MHz - the reason the NTSC reference contains a repeating decimal is that it's actually defined as "315/88 MHz".  The difference between these 2 frequencies is the reason that a PSX set to the "wrong" mode generates incorrect timing, because the logic in the CPU uses the correct divisors for the intended mode even when the external clock is wrong. A practical example of the result of this is that if you have a PAL console and run NTSC software on it the intended frame rate of about 59.94Hz will actually come out as 59.39Hz - an error of about 1% slow.  The same principle applies in reverse when running PAL software on an NTSC console, except here the error is in the opposite direction and the game runs about 1% fast.
The GPU clock is about 53MHz, with the exact frequency changing between NTSC and PAL - NTSC uses 53.693(18) Mhz and PAL uses 53.203425 MHz - the reason the NTSC reference contains a repeating decimal is that it's actually defined as "315/88 MHz".  The difference between these 2 frequencies is the reason that a PS1 set to the "wrong" mode generates incorrect timing, because the logic in the CPU uses the correct divisors for the intended mode even when the external clock is wrong. A practical example of the result of this is that if you have a PAL console and run NTSC software on it the intended frame rate of about 59.94Hz will actually come out as 59.39Hz - an error of about 1% slow.  The same principle applies in reverse when running PAL software on an NTSC console, except here the error is in the opposite direction and the game runs about 1% fast.


A more significant problem arises because these early boards (up to PU-18) also derive the color reference from the GPU and do it using a fixed divider from the GPU clock - this is 15 in NTSC mode and 12 in PAL mode, and hence the resulting color reference also has about a 1% error when using the wrong clock source. Since the tolerance that the TV has to this specific error is very small this will either result in no color at all or random colors. One solution is to use RGB, since that effectively bypasses the color encoder.
A more significant problem arises because these early boards (up to PU-18) also derive the color reference from the GPU and do it using a fixed divider from the GPU clock - this is 15 in NTSC mode and 12 in PAL mode, and hence the resulting color reference also has about a 1% error when using the wrong clock source. Since the tolerance that the TV has to this specific error is very small this will either result in no color at all or random colors. One solution is to use RGB, since that effectively bypasses the color encoder.

Revision as of 01:00, 17 April 2023

The video subsystem on the PS1 works in sometimes confusing ways, especially if you are running software that uses a video standard different from the one that the console was intended to operate in. In addition to this the behavior changed slightly between the PU-7/PU-8/PU-18 board and the PU-20 and subsequent boards.

To make sense of this, you need to look at how the clocking in the PS1 works - there are two basic clock sources, one for the CPU and one for the GPU. The CPU clock source is the same across all models and regional variants and is always 67.7378MHz - the actual CPU is clocked at 1/2 of this and this somewhat strange looking frequency was chosen so it could also be used for the sound subsystem as it's an exact integer multiple of the 44.1kHz CD sampling rate.

The GPU clock is about 53MHz, with the exact frequency changing between NTSC and PAL - NTSC uses 53.693(18) Mhz and PAL uses 53.203425 MHz - the reason the NTSC reference contains a repeating decimal is that it's actually defined as "315/88 MHz". The difference between these 2 frequencies is the reason that a PS1 set to the "wrong" mode generates incorrect timing, because the logic in the CPU uses the correct divisors for the intended mode even when the external clock is wrong. A practical example of the result of this is that if you have a PAL console and run NTSC software on it the intended frame rate of about 59.94Hz will actually come out as 59.39Hz - an error of about 1% slow. The same principle applies in reverse when running PAL software on an NTSC console, except here the error is in the opposite direction and the game runs about 1% fast.

A more significant problem arises because these early boards (up to PU-18) also derive the color reference from the GPU and do it using a fixed divider from the GPU clock - this is 15 in NTSC mode and 12 in PAL mode, and hence the resulting color reference also has about a 1% error when using the wrong clock source. Since the tolerance that the TV has to this specific error is very small this will either result in no color at all or random colors. One solution is to use RGB, since that effectively bypasses the color encoder.

On the later (PU-20 and onwards) boards, the situation is similar, except that the two oscillators used in the older models are replaced with a frequency synthesizer that generates both the CPU and GPU clocks, and also directly generates the color encoder color reference rather than via the GPU. On these machines, the PAL and NTSC versions have different clock synthesizer chips and crystals, so the PAL and NTSC versions will always generate the color subcarrier for their original mode. Since the mode select input on the video encoder is still controlled by the GPU this results in non-standard video modes being output when playing imported software.

For example, a PU20+ PAL console running NTSC software will generate NTSC color encoding but with a 4.43362MHz PAL subcarrier. This is normally called "NTSC4.43" - it's not an official video mode that was ever used for broadcasting, but it was used on some multiple standard VHS players when playing back NTSC tapes, and a lot of European spec TVs can handle it. Going the other way with PAL software on NTSC hardware results in 50Hz PAL encoded video but with the NTSC standard 3.579(54)MHz NTSC color reference, and unfortunately a large majority of US spec TVs can't handle either 50Hz or PAL encoding.

Also note that although installing an extra GPU clock or DFO on these later consoles will fix the frame timing back to standard it won't change the color subcarrier unless you also disconnect that from the clock synthesizer chip and wire it back to the GPU.