PS2 Graphics Synthesizer Mode Selector (GSM)

[TnA]

@sp193: The idea to implement GSM-standalone was specifically meant for apps, not games!

Both projects essentially would became one; GSM would have a nicer GUI; parts of the code-base possibly can be unified/merged; etc.

Given that OPL probably would not grow too much, that could be interesting!

 

[sp193]

576p 50 Hz is finally working with my SCPH-50004, but...
with this mode I've graphical glitches (in game or even with PS2 logo at startup),

That's strange. I double-checked the values that GSM uses and it seems to match the ones from my SCPH-77006...
If your PS2 was older (GS revision < 1.9), then it could have been because the SYNCH values don't match.
The value in these fields of these registers changed between GS revisions:

• SYNCH1: HBP, HFP
• SYNCH2: HB, HF

For other video modes that were already available on older consoles, there is code for setting the right SYNCH1 and SYNCH2 values for the installed GS revision.
However, mode 0x53 (576P) does not have such a thing.

PS2Linux also had 2 sets of sync values, for the 2 groups of GS versions. However, since it came out before the 576P mode was added, it has no information on the 576P mode.
It also has no information on why the sync values are different.

Since your SCPH-50004 has revision 1.11, it should not be affected by this difference. You wrote that you could use 576P properly with your newer PS2, but was it using this same TV and cable?

To be add, I've notice that image is perfectly centered.

That's great news!

It will be nice if standalone GSM also have:

• DTV 576p for consoles with ROM below 2.10
• Emulate FIELD flipping

It can be backported, which is why I am posting in the GSM forums. But I'm just not so willing to adopt yet another project.

 

[jolek]

Since your SCPH-50004 has revision 1.11, it should not be affected by this difference. You wrote that you could use 576P properly with your newer PS2, but was it using this same TV and cable?

The same TV, same component cable, same room.

Recently @Haker120 made few tests for me.
With SCPH-70003 he had more white stripes an the bottom.

He also checked SCPH-77004, and there where no graphical glitches with HTDV 576p @50 Hz.

@Vedita BR has also problem with this mode:
http://psx-scene.com/forums/f291/gs...ment-feedback-61808/index301.html#post1218245.

On all consoles 480p works fine, 576p works without glitches probably currently only on SCPH-7500X or newer.

I also need to check Max Payne, because also @Haker120 mention that this game
currently will not work with 576p on his consoles (BSOD) without enabling Emulate FIELD.
When he enable this option, screen is flickering
I remember that previously this game worked with 576p (without BSOD).

 

[sp193]

• Fixed 576P add-on code. As with 480P mode, there is not supposed to be a step for enabling the PLL.

Today's build: https://www.sendspace.com/file/olszwh

The same TV, same component cable, same room.

Recently @Haker120 made few tests for me.
With SCPH-70003 he had more white stripes an the bottom.

Thanks. So it means that there is something wrong with the code, and there probably is. I noticed this comment in PS2Linux, and indeed: that step is missing for 480P mode.
I think I added that part, since I couldn't get 576P mode to work in 2012 by just copying the code as it was. Since we can now initialize the DVE properly, it should work now...

I also need to check Max Payne, because also @Haker120 mention that this game
currently will not work with 576p on his consoles (BSOD) without enabling Emulate FIELD.
When he enable this option, screen is flickering
I remember that previously this game worked with 576p (without BSOD).

The video skip option (if available) must not be used, otherwise that is cheating...

 

[jolek]

@sp193 I've checked today's build (OPNPS2LD-180804-GSM-MODE-UPDATE.ELF).

With HDTV 576p @50 Hz on SCPH-50004 I still have these glitches:


Once again everything is fine with HDTV 480p @60 Hz.

 

[Haker120]

I have tested few more games with OPNPS2LD-180804-GSM-MODE-UPDATE.ELF on SCPH-77004:

Metal Slug 3 - without fix BSOD, with fix work well.
Metal Slug 5 - without fix BSOD, with fix flickers.
Max Payne - without fix BSOD, with fix flickers.
Jak & Daxter 2: Renegade - without fix work till press start (with fix the same, I think this is the game bug, the same appears when I mess with modes.)
Need for Speed: Most Wanted - work well without fix.

My assumption is - if a game work, it will be, if fix is needed - flickering can arrive. I did not hit on the game that won't run with 576p@50Hz, all of those that need fix can flicker though.

 

[jolek]

@Haker120 Thanks for the tests, fix means: "Emulate FIELD flipping"?

For mow we know that, HDTV 576p @50 Hz works with SCPH-7500x or newer.
Although option to enable "Emulate FIELD flipping" is needed.
What about SCPH-70003 (console without native support for that resolution)?

 

[Haker120]

Yes, I don't pay attention to names if there is only one thing I can call a fix.

 

[jolek]

Can you also test SCPH-70003 with HDTV 576p @50 Hz (console without native support for that resolution)?

 

[Haker120]

Ooooooooookay. I need to take this 7k console from box with other unused consoles.

 

[sp193]

@sp193 I've checked today's build (OPNPS2LD-180804-GSM-MODE-UPDATE.ELF).

With HDTV 576p @50 Hz on SCPH-50004 I still have these glitches:

Okay, so that did not solve anything, although it is more correct in terms of logic.

I plugged in my SCPH-39006 and there was totally no display when 576P mode is selected.

Then I tried getting SetGsCrt to set up 480P mode first, before changing the GS priviledged registers to set up 576P mode (but without setting the DVE on my own), and SCPH-39006 output 576P video.

So I am quite sure that the problem was with the PS2Linux code that I copied, not supporting any PS2 other than the first models.
Some code was shorter than the equivalent code from my SCPH-39006's kernel. I compared it against ROM 1.20, and it's much more similar... so perhaps the DVE code from PS2Linux was really meant for the early consoles. For later PS2s, it calls the functions from ROMGSCRT, but that still limits you to the modes that the ROM supports (hence no 576P support in older consoles).

I was trying to copy the version from the SCPH-70000, since it was the last PS2 to use the actual DVE hardware before Sony merged the logic into the IOP at the SCPH-75000. But it is taking a while and I don't think I can make a good release today.

I have tested few more games with OPNPS2LD-180804-GSM-MODE-UPDATE.ELF on SCPH-77004:

My assumption is - if a game work, it will be, if fix is needed - flickering can arrive. I did not hit on the game that won't run with 576p@50Hz, all of those that need fix can flicker though.

Thank you. If none of the games have worsened compatibility compared to the GSM (before all my changes), then all is well.

What about SCPH-70003 (console without native support for that resolution)?

Ooooooooookay. I need to take this 7k console from box with other unused consoles.

I think there is no need to conduct further tests for the 576P mode, until I create new code and commit the fix. Thank you both for helping me with this experiment.
As of now, it likely does not work on PS2s after the early SCPH-30000.

 

[Haker120]

Ok, I've tested, on my 70003 576p@50 is horrible, it looks like till 480p (on the lower screen) is ok, and below strange issues like smashed screen and white stripes.

 

[sp193]

Today's build: https://www.sendspace.com/file/909ig1

• Updated DVE code (for add-on 576P mode) to support consoles up to the SCPH-70000.

To cover all test cases, I tested on:
SCPH-15000 (PC CARD type, GH-003)
SCPH-39006 (SSBUS Buffer type, GH-022)

Development TOOLs (DTL-T10000 and similar) will not be supported by the new code. While the code exists in the EE kernels (except for the SCPH-75000 and later), I did not copy that part because GSM cannot really be used on a TOOL and I do not wish to commit resources into testing that part.
For some reason, it is so much longer in length than the code for the CEX. More room for mistakes too.
So if somebody was to choose 576P mode on a DTL-T10000, PAL will be selected instead.

The source code for the commits under the upcoming pull request can be found here. They will go into OPL at some point.
But I am hoping that they'll be included as part of GSM someday. I think it should still be possible to copy the GSM engine back into GSM, but it has been quite a long time since GSM was integrated into OPL.

 

[jolek]

@sp193 I've checked newest release (OPNPS2LD-180805-GSM-MODE-UPDATE.ELF).
For now everything is working on my SCPH-50004, but...

Spoiler

There's no "but".

Thank you very much.

I've been also thinking, does anybody ever used these V-modes without problems:

• PS1 NTSC (HDTV 480p @60 Hz)
• PS1 PAL (HDTV 576p 50 Hz)

Currently with these V-modes I've e.g only half screen.

Maybe you can also update code for EDTV 704x576p @50Hz 16bit
in Display setting-> Video mode?
Because when I select it, I've only black screen (of course with SCPH-50004).

Since 576p start to work on every console, why not also add it into many emulators\apps that you made:
PicoDrive, SNES-Station, WlaunchELF, etc.

 

[sp193]

@sp193 I've checked newest release (OPNPS2LD-180805-GSM-MODE-UPDATE.ELF).
For now everything is working on my SCPH-50004, but...

Spoiler

There's no "but".

Thank you very much.

Thank you for your help!

I've been also thinking, does anybody ever used these V-modes without problems:

• PS1 NTSC (HDTV 480p @60 Hz)
• PS1 PAL (HDTV 576p 50 Hz)

Currently with these V-modes I've e.g only half screen.

IMO some of these were really just from GSM, and might not have a real use for playing games.
There are also those NTSC-NI and PAL-NI modes, which give you half the screen as well (unless the game was already using something like that). It's likely because non-interlaced NTSC/PAL have half the vertical resolution.

Maybe you can also update code for EDTV 704x576p @50Hz 16bit
in Display setting-> Video mode?
Because when I select it, I've only black screen (of course with SCPH-50004).

I have no plans to. If I had things my way, then I would not even have all those modes there. Not just the 576P mode, but all those VGA modes. Although we now have a use for the higher-resolution modes, due to Maximus32's work on hi-fi theme support.

Do we actually need the 576P mode for the GUI? Are there TVs that will only support 576P, but not 480P or 720P? Or is there some quality that the 576P mode has, which we cannot achieve with other video modes?
For games, we cannot really change the frame buffer size and/or game logic, so it is preferable to use a video mode with similar characteristics as the original. However, we are free from those restrictions when it comes to homebrew software that we can change.

Since 576p start to work on every console, why not also add it into many emulators\apps that you made:
PicoDrive, SNES-Station, WlaunchELF, etc.

More like, I don't see a need for it (as I have described above).

We're also taking some things that must be done properly, into our own hands. I would rather rely on the EE kernel for video mode setup, which seems to be bad for some TVs if not done properly.

For games, the 576P mode is really quite important for PAL games because of the typical PAL frame buffer sizes and the refresh rate. But for homebrew software that we can freely change, we are free of any such restrictions.

 

[Haker120]

I confirm, compatible (with no fix) titles work perfect on my 70003 slim, those with fix, as I described earlier, work with or without flickering. @jolek don't demand too much from @sp193, I get the point PAL games (that have no switch between 576i to 480p) really needs those and apps really don't so let sp193 work for something really important.

Oh, @sp193, cheap chinese component cables have a problem with 576p@50 no matter what, 'better' ones work better, on official Sony's component things are of course the best.

 

[jolek]

I have no plans to. If I had things my way, then I would not even have all those modes there. Not just the 576P mode, but all those VGA modes. Although we now have a use for the higher-resolution modes, due to Maximus32's work on hi-fi theme support.

Do we actually need the 576P mode for the GUI? Are there TVs that will only support 576P, but not 480P or 720P? Or is there some quality that the 576P mode has, which we cannot achieve with other video modes?
For games, we cannot really change the frame buffer size and/or game logic, so it is preferable to use a video mode with similar characteristics as the original. However, we are free from those restrictions when it comes to homebrew software that we can change.

I was only thinking about strange situation, when I select (576p) to run game with GSM, everything is fine.
When I select it for GUI, I've only black screen (unsupported video mode) e.g with SCPH-50004.
While everything is OK with e.g SCPH-77004 (no matter when I choose this mode for GSM or for GUI).

More like, I don't see a need for it (as I have described above).

We're also taking some things that must be done properly, into our own hands. I would rather rely on the EE kernel for video mode setup, which seems to be bad for some TVs if not done properly.

For games, the 576P mode is really quite important for PAL games because of the typical PAL frame buffer sizes and the refresh rate. But for homebrew software that we can freely change, we are free of any such restrictions.

I only thought about this option, because 480p uses 60 Hz, 576p 50 Hz.
So some PAL ROMs might runs too fast when I select this resolution or there might be a problems with A\V sync.

BTW I've been also thinking about add 576p for build in DVD-player...
since currently only NTSC DVDs support progressive scan.

@Haker120, I'm not demanding anything, it's simple feedback with additional question about options.
I can't force no one to add it by force or in some other way.

Developer (in this case @sp193) has always final word.

 

[Haker120]

I just tested 1080p@60Hz, for compatible games works great but still, a lot of PAL titles require 50Hz.

@jolek I know, I know, just friendly saying.

@sp193 is possible, for you to do, to remove unused useless options from built-in GSM and add (if possible) 480p@50Hz or other NTSC resolutions in 50Hz?

 

[TnA]

IMO some of these were really just from GSM, and might not have a real use for playing games.
There are also those NTSC-NI and PAL-NI modes, which give you half the screen as well (unless the game was already using something like that). It's likely because non-interlaced NTSC/PAL have half the vertical resolution.

Both modes ('NI' and 'PS1') seem to be quite similar.
I am not entirely sure, what the difference is... Maybe it was rather meant for the standalone-ELF and if someone would like to start a PS1-Game afterwards?

I have no plans to. If I had things my way, then I would not even have all those modes there. Not just the 576P mode, but all those VGA modes.

I think having as many VModes for both (the GUI and in-game) is good not specifically for higher resolutions or better visuals, but especially for compatibility with a broad range of possible displays the PS2 might be connected to!

It gets even more important, how poorer a country is, because it seems their combinations are often quite... 'wild'!

Although we now have a use for the higher-resolution modes, due to Maximus32's work on hi-fi theme support.

First off, I have to note that this is NOT the only reason for all those supported VModes, but - as I said - for a (much) broader compatibility with various screens and connection-types!


Regarding the HiRes-Stuff in OPL...

@Maximus32 provides and works on the backend (basically: gskit, renderman, OPL's theming-engine, texture-management, etc.), but he is not actually working on the themes itself... He did however contribute A LOT to the theming-optimization for the HiRes-Support he implemented and helped out in detail (explaining things)!

This in turn also lead to the first 'HiRes-Approved' theme (by @Krah Jolito and @Tupakaveli) and a lot (of) fixes to previously unknown bugs (in OPL and gskit specifically)!

The real limit of theme-optimization is not yet 100%ly determined, but we are getting closer!

Do we actually need the 576P mode for the GUI? Are there TVs that will only support 576P, but not 480P or 720P?

AFAIK, not every monitor/screen is supporting 576p and if they do, they normally support those 2 modes as well!

Or is there some quality that the 576P mode has, which we cannot achieve with other video modes

It would be useful for games specifically and for the GUI due to the aforementioned compatibility to a broad range of screens and connections!

For games, we cannot really change the frame buffer size and/or game logic, so it is preferable to use a video mode with similar characteristics as the original. However, we are free from those restrictions when it comes to homebrew software that we can change.

Technically (regarding compatibility to games) correct!

However... If we include screen--and connection-compatibility in our conclusions, it is still quite useful! I would rather like to expand or change the kind of VMODE-choice!

For example: I would rather have those current VModes as 'profiles' which could be extended by custom VModes and configurations via a config or similar!

I was only thinking about strange situation, when I select (576p) to run game with GSM, everything is fine.
When I select it for GUI, I've only black screen (unsupported video mode) e.g with SCPH-50004.
While everything is OK with e.g SCPH-77004 (no matter when I choose this mode for GSM or for GUI).

Yes that would be interesting. This part however is more related to console-compatibility to various VModes itself and thus to device-compatibility in 2 ways (new VMODE on old consoles which do not support it and supporting a broad range of screens).

I only thought about this option, because 480p uses 60 Hz, 576p 50 Hz.
So some PAL ROMs might runs too fast when I select this resolution or there might be a problems with A\V sync.

While I (do) agree, that it would be interesting to have a multitude of 50Hz-Modes (or even a separate Hz-Selection next to the resolution), this is not related to the VMODE you were mentioning for the GUI! These GUI-VModes are NOT related to GSM, but use gskit instead!

BTW I've been also thinking about add 576p for build in DVD-player...
since currently only NTSC DVDs support progressive scan.

I agree, that this would be very cool! I however think, that this is not a VMODE-related patch solely, but that the DVD-Player is not prepared for progressive output of PAL-content! :-|

I just tested 1080p@60Hz, for compatible games works great but still, a lot of PAL titles require 50Hz.

@jolek I know, I know, just friendly saying.

@sp193 is possible, for you to do, to remove unused useless options from built-in GSM and add (if possible) 480p@50Hz or other NTSC resolutions in 50Hz?

480p would probably lead to cutting a lot of the picture from PAL-Games (thus stretching the picture to a point where a part of the top and the bottom are not visible).
That's why I rather propose 720p and 1080i both @50Hz! However! Your proposal might still be interesting for a few games, like the PAL-Release of FFX and other PAL-games with thick black borders!

 

[TnA]

I added this post to the previous reply and will add another proposal here soon...


Edit:

An auto adaptive Hz-VMODE would be nice! That should be relatively easy for interlaced modes (and I think possible for progressive modes as well)!

In essence it should be a mode which changes the resolution, but let's the game decide on the Hz-Rate... I suppose that could fix A LOT timing-related issues in games and it should be a rather easy addition (just like 50Hz-fixed modes should be rather easy to implement)!