PlayStation Development Network

Heyho everyone,

I'm heavily confused about the PSX and the screen resolutions. I already created a thread about that for the NO$PSX Emulator, because I thought there was a configuration problem. By now I'm not so sure about that anymore and felt like this is a separated issue. If others disagree with that: sorry for the double post xO

Anyway lets dive into my issue. I wonder what resolution the PSX (really?) has! I'm reading the documents from PsyQ and I thought to see clear instructions there:
Table 8-1 says that the following combinations can be used for the Display Area and Drawing Area:
Width 256, 320, 360, 512, 640px
Height: 240, 480px

Later it also states that you should choose 256 or 512px for PAL devices. OKAY! Makes sense! So, as stated in my old thread, I created a 320x240px NTSC screen, but No$PSX gave me a 320x224px screen. Every other emulator I tried gave me 320x240px however. Interestingly, those emulators ignored my settings for moving the screen - only No$PSX took them into account. So, I thought that the emulator was simulating an old CRT monitor. I read, that you are not really able to determine the resolution of a CRT screen in pixels, because of the way they function. Also they cut parts of the screen at the bottom and top, for the cathode to readjust. To me, it made sense why No$PSX was reducing the height of my screen - to simulate that effect.

However... When I went for a 320x256 PAL screen, then I suddenly ended with 320x264px screen - that debunked my theory, because suddenly the screen was way bigger!

I then decided to try something else. I wrote an application to render two triangles - a blue and a red one - filling each half of the screen I defined. I also integrated a switch for compiling it as NTSC/PAL and using the Gs* functions or not. The setup code looks like that:
(I didn't knew how to proper name the "USE_GPU" macro, but it is used to switch between GS* and non GS* functions)

I used No$PSX again and opened there the I/O Map. I compiled the code with 4 different settings and got the following:

PAL defined and USE_GPU defined
Display X-Range: width=320x8
Display Y-Range: height=256
Display Mode: 320x264 PAL 15bpp (0x9)

PAL defined and USE_GPU undefined
Display X-Range: width=320x8
Display Y-Range: height=240
Display Mode: 320x264 PAL 15bpp (0x29)
--------------------------------------
I... didn't understood this! When using the Gs* functions I definitely passed them 256, but they set the screen to 240?! While setting the display mode to 264?

So I ran the same code with NTSC

PAL undefined and USE_GPU defined
Display X-Range: width=320x8
Display Y-Range: height=240
Display Mode: 320x224 NTSC 15bpp (0x1)

PAL undefined and USE_GPU undefined
Display X-Range: width=320x8
Display Y-Range: height=240
Display Mode: 320x224 NTSC 15bpp (0x1)
--------------------------------------
There, the Gs* functions didn't made any difference! Urgh...

On top of this, I never read the mentioned Display Modes and there resolutions in any document yet! Where are those values coming from? To add to the confusion, I also checked Wikipedia about the resolutions of the PSX. The English Wikipedia says:
Resolution: 256×224 to 640×480 pixels (480i)
Which aligns to the documents

But the German Wikipedia (Greetings from Germany x3) say:
Auflösung: 320 × 240 bis 640 × 480 (NTSC, interlaced) bzw. 512 × 384 (PAL) Pixel
Which aligns to the English Wiki for the NTSC values, but the PAL values are suddenly 512x384, which I never read in the documents nor in No$PSX.

I'm still a complete noob with developing for the PSX, but the thing with the resolutions bothers me since almost 2 weeks and I just wonder... where do all those numbers come from? Who is right?

I also attach the source code for my programm.

Did you check the documentation that comes with PSY-Q?
There is a guide explaining the differences between making games for PAL and NTSC that should have some info about this.
It's in DOCS/TECHNOTE/palguide.pdf inside the PSY-Q folder called "Guidelines for PlayStation PAL titles".

Also, you shouldn't be basing this kind of stuff off the output of an emulator. As far as the PlayStation is aware, the real resolution is the one you set to render the framebuffer. For the resulting signal output from the console itself, I'm pretty sure the screen offset is just setting the offsets of the chip that generates the video signal that tells it what scanline to start outputting the image from the framebuffer to the TV. For more info on that you'll need to look up how analog video signals work. Alternatively, look up the chip the PlayStation uses to output video signals, I don't know if there is datasheet available for it, but it would be your best bet to find out this information.

What you seem to be talking about here is how NO$PSX is simulating the overscan area of a CRT TV, and yes, it is.
It's just that it behaves differently for NTSC and PAL games. There is an option in NO$PSX that controls this called "Force Screen Auto-Centering" that changes how this is applied.

Edit-
Here is the datasheet for one of the video output chips used in the PlayStation:
https://console5.com/wiki/CXA1645

Lets see if I manage to quote multiple times :/

ArthCarvalho wrote: ↑November 28th, 2019, 12:20 pm Did you check the documentation that comes with PSY-Q?
There is a guide explaining the differences between making games for PAL and NTSC that should have some info about this.
It's in DOCS/TECHNOTE/palguide.pdf inside the PSY-Q folder called "Guidelines for PlayStation PAL titles".

Yes! That is where I picked up my knowledge about the overscan area....

ArthCarvalho wrote: ↑November 28th, 2019, 12:20 pmAlso, you shouldn't be basing this kind of stuff off the output of an emulator.

But there must be a reason why No$Cash choosed those screen values... I just try to understand this...

ArthCarvalho wrote: ↑November 28th, 2019, 12:20 pmWhat you seem to be talking about here is how NO$PSX is simulating the overscan area of a CRT TV, and yes, it is.
It's just that it behaves differently for NTSC and PAL games. There is an option in NO$PSX that controls this called "Force Screen Auto-Centering" that changes how this is applied.

I disabled that feature... But I still don't get how the values from No$Cash align to the PsyQ documentation and the values from Wikipedia... It just freaks me out that 3 sources tell me different things .w.

ArthCarvalho wrote: ↑November 28th, 2019, 12:20 pm Edit-
Here is the datasheet for one of the video output chips used in the PlayStation:
https://console5.com/wiki/CXA1645

I... have no idea about that :/ I'm not that smart >o<"

There are no specific values for overscan because it was not fixed, different brands and models had different overscan adjustments. You could even adjust the beam alignment yourself using a knob on some very old models.

ArthCarvalho wrote: ↑November 29th, 2019, 6:34 am There are no specific values for overscan because it was not fixed, different brands and models had different overscan adjustments. You could even adjust the beam alignment yourself using a knob on some very old models.

How does it come then, that NoCash choosed a higher screen resolution for PAL devices? I mean.... requesting 256px but getting 264px is like the opposite of a overscan....

Also... why does Wikipedia has different height values then PsyQ documentation? Is it like a black box? Kinda "the developer does not need to know the real resolution, 256px is enough for him"? I mean... if a lot of screen is covered by the overscan, then it would have a certain advantage if you tell the developers that they have a height of 256, while outputting a higher height, this would make more of the screen visible... But still... I'm making that up right now :/

According to the information inside palguide.pdf:

For NTSC, vertical resolutions such as 240 and 480 have full overscan.

For PAL, vertical resolutions of 256 and 512 have no overscan (288 would be required).

It means that the PlayStation by design has 32 "padding lines" when using PAL mode.

When Sony designed the PlayStation it was very obvious that they prioritized NTSC TVs over PAL (Being a Japanese console, at the time Sony and other Japanese companies focused a lot in their internal market).
The PlayStation VRAM was 1024x512 pixles, two 320x240 framebuffers fits nicely on top of each other, 288 vertical lines would be a big problem, specially if you consider that a lot of games were going to be ports, and a lot of games used two framebuffers aligned vertically so it would cause a lot of problems when porting.

They decided that 256 pixels was a good compromise because it wouldn't require as much RAM as 288 pixels (required for a full image) and would make porting slightly less complicated.

The direct implication for PlayStation game products is that your NTSC title probably
does not draw a tall enough display to fill a PAL TV screen. For example, a common
resolution to run an NTSC PlayStation game is 320 pixels wide by 240 pixels high. On an
NTSC TV, 240 pixels high is enough to fill the screen. On a PAL TV, 240 high is not tall
enough to fill the screen; 256 pixels high is about right. This means that you may have to
make some changes to the way your game draws its display, and find some mechanism for
filling the extra space.

The problems with digital manipulation of analog video are ages old and continues to confuse developers to this day.

In the PSX, you program graphics to be displayed according to timings you define (PAL / NTSC, hor. resolution).
I believe the PSX has no programmatic control over the number of lines, ie: NTSC will always output 262, PAL always 312 lines (ignoring interlaced output and other minute details).
So what your programming does is, it configures a GPU display clock (to allow for different hor. resolutions), sets up hardware timers for either PAL or NTSC output, and then the GPU pulls the graphics from the framebuffer and maps them to the available video lines.
You can specify how many video lines you want, but this only affects how the GPU maps the framebuffer content to the available hardware video lines.

So with this overview in mind, you can see how the line count that you specify in your program is constrained by / only affects how the GPU maps the framebuffer content to available video lines.
If you specify less lines, simply more of the screen will be black.
If you specify too many lines, some of your graphics will end up in overscan, and not be visible on a CRT.
You can never make the GPU output more or less actual lines.

(All this then leaves the GPU chip, to be converted to the actual analog video.
You have no more control over those steps, so at least you don't need to read any of the others chip's datasheets ;p)

Thank you ArthCarvalho and rama3!! That really helped me! I understand the subject a bit better now.

rama3 wrote: ↑November 29th, 2019, 10:47 pm You can specify how many video lines you want, but this only affects how the GPU maps the framebuffer content to the available hardware video lines.

How do I do that? Are those values set via "SetDefDrawEnv""SetDefDispEnv"?

Edit:
Mentioned the wrong function xO