PS2 Graphics Synthesizer Mode Selector (GSM)

DISCLAIMER:
GSM IS DISTRIBUTED "AS IS". NO WARRANTY OF ANY KIND IS EXPRESSED OR IMPLIED. YOU USE AT YOUR OWN RISK. THE AUTHORS, WILL NOT BE LIABLE FOR DATA LOSS, DAMAGES, LOSS OF PROFITS OR ANY OTHER KIND OF LOSS OR DAMAGES WHILE USING OR MISUSING THIS SOFTWARE.

Welcome to the Graphics Synthesizer Mode Selector (aka: GSM) Project.

GSM intends to make on-the-fly conversion from the original graphic mode of PS2 game (or application) choosen by user, to the ones he/she wants to force.

One of benefits of using GSM is have a progressive scan output for a game originally designed to use interlace output. Or have a VGA output in your CRT/LCD Monitor for your preferred games. It seems great, isn't ii?

Well, GSM just makes a simple upscaling. It doesn't making interpolation (i.e. it doesn't add extra pixels / lines). So it doesn't increase the internal(=original=source) resolution, only the output (=forced=target) one.

So, there is no miracle here... The greater the quality of source (original) resolution of the game, the better will be the results that will be displayed on target (forced) resolutions - specially on the higher ones, where the images naturally tend to be pixelized.

GSModeSelector v0.36b (2013.01.16) by doctorxyz
- GUI can be bootable and relaunchable by FCMB E1 launch keys (due to DeInitGSM, New IOP reboot sequence, simplified Makefile, new Launcher based on uLE v4.42a, ...)

GSModeSelector v0.36(2011.02.26) by doctorxyz and dlanor (compiled by doctorxyz)
(This release was prepared by me having in mind both GSM standalone neeeded code improvements and future OPL integration)
- Simplified OSD: buttons for video modes, SELECT for launch method, PAD for X and Y-axis offset and START to launch
- In order to avoid gsKit issues, now GSM only is enabled only after selecting video mode, launch method and pressing START
- Optimized C and ASM source code, many comments were rewritten
- Fixed the access trap mask method to trap GS registers for all kernel segments
- Implemented x-axis and y-axis offset inside core for better fine tuning on special cases
- Always enabled: Automatic adaptation, DISPLAYx fix, SMODE2 fix and SYNCV fix
- Main routines names changed from ModdedSetGsCrt to Hook_SetGsCrt and from DisplayHandler to GSHandler
- Improved compatibility: Re-enable GSHandler whenever Hook_SetGsCrt is called
- Other improvements/adjustment I can't remember for now
(some releases were skipped intentionally, they are used only on doctorxyz private development/testing)

Click to expand...

GSModeSelector v0.23x(2010.06.30) by doctorxyz and dlanor (compiled by dlanor)

Fixed mistake in GSM adaptation formula, removed Read Circuit adaptation, removed recording of the interlace & FFMD settings from SetGsCrt since it will also be recorded from SMODE2.

GSM will now consult the _GetGsDxDyOffset syscall for board-specific offsets (if supported).

When Target_Width (or Target_Height) < Source_Pixels_Width (or Source_Pixels_Height), it used to use Target_Width.
As a result, the region beyond the ends of the frame buffer will be drawn (hence the graphical glitches in games like the Sonic Gems Collection).

Click to expand...

SP193 said:

I somehow read it wrong and those expressions were correct. In fact, it seemed like I no longer got those graphical glitches, even without changing those lines.
I guess it is related to the change in parameters to the 480P and 576P modes, since the previous commit had that changed...

I've done some more fixes, related to the sync instruction:

GSM: changed all sync after mtc0 to sync.p as it has to be sync.p. Changed all lq to ld for the branch evaluations, as only the low 64-bits are supposed to be considered.

Removed unnecessary sync.l & sync.p instructions.

GSM: Changed preservation and restoration of context to better match the original Level 2 exception handler and preserve LO+HI registers.

Optimized GSM engine.

When I wrote "unnecessary", I mean those that I see no need for. Whereby the EE instruction manual doesn't indicate a need for those.
The description for the mtc0 instruction states that a sync.p (not just sync) is required to ensure that the write to the cop0 register completes.
GSM will now use only k1 (and its backup location at address -0x20 via kseg3) to preserve the context. It will also preserve LO+HI register pairs (lo, lo1, hi, hi1), which get changed by multiplication and division operations.

@doctorxyz once wrote that there is some risk involved in doing this, but I would like to try to make the code more efficient.

For optimizations, the beqzl instructions were replaced with normal beqz instructionsto maximize use of branch slot. nops were reduced to reduce code size, but interlocks will still occur.
The EE mult MMI is used, so that we can save on some instructions.

Since the removal and/or changes to the placement of sync and sync.p might cause game compatibility to change, I would appreciate it if somebody can let me know if any game suddenly became incompatible.
Test: https://www.sendspace.com/file/aorh8n

Is it possible to somehow fix screen size for some games when
I launch them with progressive scan (576p)?

Here is how screen size look in e.g God of War II 576i (almost full screen):

Here is how it looks like when I enable progressive scan (576p):

Click to expand...

Some games might use a frame buffer size like 512x448. That is one of the allowed sizes for NTSC.
The DW for NTSC and PAL are both 2560.
2560 / 640 = 4x, while 2560 / 512 = 5x. These are all nicely supported.

While DTV 480P's DW is likely 1440, given that the documented horizontal resolution is 720 and libgraph multiplies the width by 2.
1440/640 = 2.25x. 1440 - 2x640 = 160px. Not perfect, but the border will be quite small (11%).
1440/512 = 2.8125x. 1440 - 2x512 = 416px. 28% of the screen will go into borders.

What happens is that it'll round down the magnification factor to the nearest integer and center the video. That's why you get large borders.
You can try the other video modes, but none of them will be perfect for such a case. I don't think we can fix this perfectly, since the problem is that the game wasn't designed for other video modes.

From feedback, I have made the FIELD emulation setting an option. It is disabled by default.
I think not emulating the flipping for those games that use the half-pixel offset trick is the more correct thing to do, given that they were using a low-resolution buffer and GSM is already doubling the height of such frame buffers - hence why the video is pixelized. As of now, I don't have a way to deinterlace the video anyway.

I have also removed the last sync.l instruction before the eret instruction. I wasn't sure if it was a good idea to remove it, but because the kernel doesn't have such a thing... it might not be necessary.
So if there are any new incompatible games compared to yesterday's build, please let me know.

Some games might use a frame buffer size like 512x448. That is one of the allowed sizes for NTSC.
The DW for NTSC and PAL are both 2560.
2560 / 640 = 4x, while 2560 / 512 = 5x. These are all nicely supported.

While DTV 480P's DW is likely 1440, given that the documented horizontal resolution is 720 and libgraph multiplies the width by 2.
1440/640 = 2.25x. 1440 - 2x640 = 160px. Not perfect, but the border will be quite small (11%).
1440/512 = 2.8125x. 1440 - 2x512 = 416px. 28% of the screen will go into borders.

What happens is that it'll round down the magnification factor to the nearest integer and center the video. That's why you get large borders.
You can try the other video modes, but none of them will be perfect for such a case. I don't think we can fix this perfectly, since the problem is that the game wasn't designed for other video modes.

Click to expand...

What about an option to stretch some games?
I'm asking for that because with progressive scan some games looks like they were in 4:3 ratio,
no matter if I choose widescreen in option or not.

BTW it is strange that if a game (God of War II NTSC, True Crime: New York City PAL) has built in 480p
I've almost full screen, when I launch it with GSM screen is squished.
Some cheats?

From feedback, I have made the FIELD emulation setting an option. It is disabled by default.
I think not emulating the flipping for those games that use the half-pixel offset trick is the more correct thing to do, given that they were using a low-resolution buffer and GSM is already doubling the height of such frame buffers - hence why the video is pixelized. As of now, I don't have a way to deinterlace the video anyway.

I have also removed the last sync.l instruction before the eret instruction. I wasn't sure if it was a good idea to remove it, but because the kernel doesn't have such a thing... it might not be necessary.
So if there are any new incompatible games compared to yesterday's build, please let me know.

BTW it is strange that if a game (God of War II NTSC, True Crime: New York City PAL) has built in 480p
I've almost full screen, when I launch it with GSM screen is squished.

Click to expand...

Is it still like that, as of this most recent test?
Previously, GSM tried to use some resolution like 640x480, but that is not the resolution that Sony documented. So now that it is using 720x480, does it still look squished?

With progressive scan (480p) font is "ugly" (hard to read).
When I enable "Emulate FIELD flipping" image is flickering.

Click to expand...

When you have a low-resolution (as seen under 480P) game that flickers when the FIELD emulation option on, it probably uses the half-pixel offset trick. The benefit of that trick, was that you get to have double-buffering with memory savings. But it does not work when a progressive video mode is used.

So for at least now, we have to choose between upscaling its true frame buffer resolution or living with two sets of scan lines that do not merge.
Personally, I think it may be best to use the original video mode for these games.

The only time when I think it is a cause for concern, is when the game looks worse now than when older GSM versions are used.

Is it still like that, as of this most recent test?
Previously, GSM tried to use some resolution like 640x480, but that is not the resolution that Sony documented. So now that it is using 720x480, does it still look squished?

Click to expand...

With God of War II screen is still horizontal squished (when I enable 480p):
I'll try to test my PAL games using 576p mode as soon as I can get to my slim console,
to get more accurate tests.

With God of War II screen is still horizontal squished (when I enable 480p):

I'll try to test my PAL games using 576p mode as soon as I can get to my slim console,
to get more accurate tests.

Click to expand...

Hold on. Are you using 480P mode by GSM on this game, but with the game using its usual NTSC/PAL?
I thought you meant to say that it looks squished when you select 480P within GSM and used the progressive option in the game. Now to think about it, that doesn't make sense. I must be tired.

GOW II uses 512x512 for PAL, which isn't a factor of the 480P/576P screen width (Frame buffer width does not divide DW). The remainder is so huge that 28% of the screen goes into those borders.
I guess it might use some other resolution for 480P mode. The resolution can be changed during runtime and this may be one of those games.

How strange! Wasn't it supposed to be for all regions if it is a supported console?
Maybe I misunderstood how that feature worked.

Click to expand...

Maybe it's like that because there was no official 576p mode?
For NTSC DVD-Video it should be 480p (60 Hz).
For PAL DVD-Video it should be 576p (50 Hz).
Maybe that's why DVD player has got only progressive scan for NTSC-Video.

Hold on. Are you using 480P mode by GSM on this game, but with the game using its usual NTSC/PAL?
I thought you meant to say that it looks squished when you select 480P within GSM and used the progressive option in the game. Now to think about it, that doesn't make sense. I must be tired.

GOW II uses 512x512 for PAL, which isn't a factor of the 480P/576P screen width (Frame buffer width does not divide DW). The remainder is so huge that 28% of the screen goes into those borders.
I guess it might use some other resolution for 480P mode. The resolution can be changed during runtime and this may be one of those games.

Click to expand...

For FAT console I was using GSM+OPL (OPNPS2LD-180801-MODE-UPDATE.ELF), 480p 60 Hz.
with SCUS_974.81 God of War II (NTSC-US).
Only NTSC version of this game has got an option turn on progressive scan.

This game should starts in 480i (NTSC), but since I'm using GSM,
I've 480p and a squished image.
When I enable progressive scan in options, screen is almost full (with or without GSM).

I haven't tested PAL games, because currently my fat console doesn't support 576p.

Thank you. So it seems like I was wrong about it and only the SCPH-75000 and later do support 576P.
The PSX is likely an exception to this rule: it supports this mode, despite having a lower ROM version number than the ROM from the SCPH-50000a, SCPH-50000b and SCPH-70000.
The PSX also shares the same GS revision as the SCPH-75000, which is also shared with some SCPH-70000 consoles. So I cannot think of a better way to identify what console supports this mode... other than going with the current homebrew idea of "v2.20 and later".

But for our case, I made it v2.10 and later because there is a PSX with v2.10. It is likely harmless to use the GSM code for setting up 576P mode for the PSX with v1.80.

New functions for initializing the DVE properly for 576P mode, have been added on behalf of the EE kernel. It was based on code from Kernelloader.

Maybe that's why DVD player has got only progressive scan for NTSC-Video.

Click to expand...

The DVD player uses different modes, also for Macrovision protection. So it is likely that even if progressive was ever supported for PAL discs or not, it might not have a relationship with whether the 576P (0x53) mode is usable.
I don't even know what this 576P (0x53) mode was even meant for - it was not documented for use by games and neither did the Sony libgraph support it. No game seemed to have ever used it too...

Regarding SetGsCrt: PS2Linux also reimplemented SetGsCrt in its own way.

For newer consoles that have ROMGSCRT (v1.60 and later), the functions within ROMGSCRT are used instead. ROMGSCRT implements SetGsCrt (yes, it is a duplicate) and _GetGsDxDyOffset.
But for older consoles, it would do things on its own and we can see how it works.

You might already know this, but because the hardware was changed at the SCPH-75000, its equivalent for dve_prepare_bus() doesn't support the old hardware registers anymore (moved to 0xBF8019xx). This might be the reason why Mega Man remarked that this function cannot be used for "newer consoles", although he didn't clarify what models they were.

The "dev9_type_detected" variable is not set in the CEX kernel and is hence likely always 0x00. In the EE kernels, this variable is checked against 0x40, 0x60 and 0x61, rather than whether it is non-zero (in SBIOS).
In TOOLs, this is the value known as "BoardInf", taken with a load byte operation from 0xBF803204. CEX consoles don't even have BOARDINF and also lack any code that deal with it (even within the EE kernel), so I don't know if it is even safe to try to access that register directly.

The "sbcall_setdve" function is a unified function here, but it is split up in the EE kernel; there is one for DTV modes (480P, 1080I and 720P), and other similar functions for the other VESA and DTV video modes (including those for the DVD player).

The 576P (0x53) mode was added with ROM v1.80, for the PSX. The PSX seems to have the same GS revision as the SCPH-75000, even though it was about a year older.
The v1.90 ROM for the SCPH-50000a and SCPH-50000b do not support this mode, as with the SCPH-70000 (v2.00).
The PSX's ROM seems to support all 3 possible DVE interfaces, including whether the DECKARD method is used or not. This depends on whether the highest bit of 0xbf801450 is not set (checks whether the word value is >= 0).

EDIT: The writes to the DVE after setdve() are possibly required.

Within the setdve() function call, 576P mode requires the same settings as 480P. For the code after the call to setdve(), the commands are similar, except that 576P mode has 1 extra write.

I don't know if I understand you correctly, because...
no matter if I use OPNPS2LD-180802-MODE-UPDATE.ELF or previous versions,
I still have BSOD (no video signal) when I enable 576p 50 Hz with my SCPH-50004.
I do not even see PS2 logo, even on my game pad analog mode is off.

In simple words my PS2 is crashing when I enable this (probably unsupported) mode.

I don't know if I understand you correctly, because...
no matter if I use OPNPS2LD-180802-MODE-UPDATE.ELF or previous versions,
I still have BSOD (no video signal) when I enable 576p 50 Hz with my SCPH-50004.
I do not even see PS2 logo, even on my game pad analog mode is off.

In simple words my PS2 is crashing when I enable this (probably unsupported) mode.

Click to expand...

Yes, I understood you perfectly well. I know it is an unsupported video mode, but GSM is supposed to have code that will allow these consoles to output 576P. It is just additional code that these PS2s need.

It is possible that between the 11 new commits, I actually broke that part. But because I only have my SCPH-77006 wired up, I will not be able to test that function normally.

I shall have a look at it tomorrow. It should be a very small, but silly mistake.

Fixed support for J-type instructions. Bits 31:28 were not computed, resulting in failures when the EE jumps from within KSEG.

Removed call to Disable_GSBreakpoint() from within Hook_SetGsCrt(), so that GSM can change SetGsCrt(). It's already being done anyway, during LoadExecPS2(), but before SetGsCrt() is hooked...

576P now again works on older consoles.

576P will now use the user's GCONT setting (RGB/Y Pb/Cb Pr/Cr).

I did tests with my SCPH-15000. I spent quite a few hours working on GSM, thinking that it was a hardware bug because I couldn't even get 480P mode to work there (but it's working on my SCPH-39006 and SCPH-77006).
It turned out to be a bug in GSM's code that handled the J-type instructions.

At the last minute though, I made more changes (the middle point) and I do not have the TV for my use... so I do hope it works.
I do think it will do. haha

Not you.
I was having hard time to understand what you wrote in this topic.
I still have problems with some expressions\technical words,
but I doesn't matter overall.

Click to expand...

No, haha. I was really tired and I started skipping words. Plus my own explanations sometimes become hard to understand because of that. >_>

If you need help to understand anything, please feel free to ask me to clarify myself. This will also make the information here easier to understand, for other developers who might want to continue the development of GSM. Or if doctorxyz ever decides to return.

Basically, the PS2's graphics subsystem is more than just the GS chip.
The SSBUS I/F controller (CXD9566R, CXD9611x, CXD9686x, CXD2955R) is actually also responsible for letting the EE talk to the video encoder (DVE) via a I2C bus, which is also used for enabling the copy-protection (Macrovision). It also determines the input clock for later models, which allows the G-chassis (SCPH-37000) and later to support both NTSC and PAL properly.

I wrote "DVE" here, but that is probably not what it really is in all PS2s. I lack the technical knowledge here to know what it should be called, but I know it was a Texas Instruments device that was replaced at some point with the Sony CXM4000R.

So while GSM had add-on code for enabling 576P on older consoles that did not support it, it lacked the code for telling the DVE that 576P mode is used. Hence it might not have been totally 576P mode until yesterday. It also had the GCONT (RGB/Y Pb/Cb Pr/Br) setting hardcoded, but now it will use the user's setting.

Edit: Btw.: Has anyone ever tried adding some more 50Hz-Modes? I'd really like to have [email protected] and [email protected], because it might eliminate the timing-issues of (some) PAL-Games.

Click to expand...

If such a signal standard exists, it can be done. Unfortunately, only those who deal with TV signals might be able to create such a video mode properly.
When I helped to create the 1080P mode, it was just a copy of the 1080I mode, but with interlace disabled and with the PLL frequency increased. So it was not really a new video mode...

Are you sure your Screen is supporting 576p? It does work for me in the official revisions (I haven't tested one of the test-builds yet.)and with a SCPH-50004!

Click to expand...

It was working, somewhat. It was missing code for setting up DVE and the GCONT setting was hardcoded.
I somehow broke that part recently, but I didn't actually figure out what I broke because it started working again after some rebasing...

But in the process of that, I found an actual bug in GSM: J-type instructions did not have the upper bits computed, resulting in failures if the EE did a jump from within KSEG.
Previously, it was not an issue because GSM was not allowed to monitor accesses in kernel mode, but that also meant that a lot of its extended functionality (i.e. for processing undocumented registers) was also not working. That part wasn't important for most people though.

On another note: I think a (re)implementation of GSM-standalone into the Apps-Menu/Page could be beneficial for both projects (OPL & GSM)!

Click to expand...

Most people probably wouldn't care about the additional settings from GSM, if they just wanted to play games. More choices might mean more room for confusion, to an uninformed user.
What other settings do you need, that OPL currently doesn't have?

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),
I even tried to enable\disable "Emulate FIELD flipping", but with no luck.

When I enable 480p 60Hz everything is fine.
To be add, I've notice that image is perfectly centered.
Probably because:

No, haha. I was really tired and I started skipping words. Plus my own explanations sometimes become hard to understand because of that. >_>

If you need help to understand anything, please feel free to ask me to clarify myself. This will also make the information here easier to understand, for other developers who might want to continue the development of GSM. Or if doctorxyz ever decides to return.

Basically, the PS2's graphics subsystem is more than just the GS chip.
The SSBUS I/F controller (CXD9566R, CXD9611x, CXD9686x, CXD2955R) is actually also responsible for letting the EE talk to the video encoder (DVE) via a I2C bus, which is also used for enabling the copy-protection (Macrovision). It also determines the input clock for later models, which allows the G-chassis (SCPH-37000) and later to support both NTSC and PAL properly.

I wrote "DVE" here, but that is probably not what it really is in all PS2s. I lack the technical knowledge here to know what it should be called, but I know it was a Texas Instruments device that was replaced at some point with the Sony CXM4000R.

So while GSM had add-on code for enabling 576P on older consoles that did not support it, it lacked the code for telling the DVE that 576P mode is used. Hence it might not have been totally 576P mode until yesterday. It also had the GCONT (RGB/Y Pb/Cb Pr/Br) setting hardcoded, but now it will use the user's setting.

Most people probably wouldn't care about the additional settings from GSM, if they just wanted to play games. More choices might mean more room for confusion, to an uninformed user.
What other settings do you need, that OPL currently doesn't have?