PS2 Graphics Synthesizer Mode Selector (GSM)

App for changing resolution

  1. 1,430
    1,101
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,430
    Likes Received:
    1,101
    Trophy Points:
    347
    Gender:
    Male
    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.

    Here you can get GSM public releases (by doctorxyz and dlanor).

    STATUS:
    Beta testing stage.

    Releases:

    [​IMG]
    GSModeSelector by doctorxyz.

    Chanelog:
    [​IMG]
    GSModeSelector v0.23x(2010.06.30) by doctorxyz and dlanor (compiled by dlanor)

    NB: Due to space limitations changes for many versions have been removed.
    NB: Please check the changes.txt file in the latest release for a more extensive changelist

    GSM Memory Card Icon:
    [​IMG]
    Source (@github):
    https://github.com/doctorxyz/gsm.
     

    Attached Files:

    Last edited: Aug 14, 2018
  2. 708
    1,246
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    708
    Likes Received:
    1,246
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    Also on psx-scene:
     
    jolek likes this.
  3. 708
    1,246
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    708
    Likes Received:
    1,246
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:

    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.
     
    sandungas likes this.
  4. 708
    1,246
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    708
    Likes Received:
    1,246
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    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.

    Today's build: https://www.sendspace.com/file/zx5umn
     
  5. 1,430
    1,101
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,430
    Likes Received:
    1,101
    Trophy Points:
    347
    Gender:
    Male
    @sp193 Is there a chance for 576p support in FAT consoles?

    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?

    Thanks for new version.
    No matter which GSM (GSM+OPL) version I choose
    I've a problem with Legacy of Kain: Defiance when I enable 480p.
    For now 576p it is not working with my fat console.

    With progressive scan (480p) font is "ugly" (hard to read).
    When I enable "Emulate FIELD flipping" image is flickering.
     
    Last edited: Aug 1, 2018
  6. 708
    1,246
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    708
    Likes Received:
    1,246
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    What is your ROM version? 1.90?
    Can you also check if your console has the "Progressive" option in the DVD player?

    Unfortunately, we cannot shrink (in any dimension) or change the size of the frame buffer.
    The hardware only allows for upscaling, in integral factors.

    You might want to look at those widescreen hacks, I guess.

    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?

    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.
     
  7. 1,430
    1,101
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,430
    Likes Received:
    1,101
    Trophy Points:
    347
    Gender:
    Male
    For SCPH-50004, PlayStation 2 Identification Tool v0.832 "says":
    ROMVER 0190EC20030623.
    I can send you Dump system ROM if you like.

    I can only turn on Progressive Scan for NTSC DVDs:
    [​IMG]
    I works (my TV shows 480p).
    With PAL DVDs this option does not exists.

    With God of War II screen is still horizontal squished (when I enable 480p):
    [​IMG]
    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.
     
  8. 708
    1,246
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    708
    Likes Received:
    1,246
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    Yes, please do. There's no hurry though, so please take your time.
    But I haven't decided on how to address this. Ideally, I would figure out how the DVD player determines what is a supported console.

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

    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.
     
  9. 1,430
    1,101
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,430
    Likes Received:
    1,101
    Trophy Points:
    347
    Gender:
    Male
    Sent.

    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.

    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.
     
  10. 708
    1,246
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    708
    Likes Received:
    1,246
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    • The check for whether the console supports 576P or not, has been changed to v2.10 (DESR-5500, DESR-7500) and above.
    • Added code for setting up the DVE for 576P mode, for ROMs that do not support it natively. Code was based on the code from Kernelloader.
    Today's build: https://www.sendspace.com/file/xctayp

    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.

    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...

    Ah okay, thanks for the clarification. So yes, this is working as intended (unfortunately).
     
    jolek likes this.
  11. 708
    1,246
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    708
    Likes Received:
    1,246
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    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.

    There are a two parts to it:
    1. The part that writes to the undocumented GS privileged registers.
    2. The part that writes to the DVE. This is only required for VESA and the DTV video modes. DVE functions can be found here.

    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.
     
    Last edited: Aug 5, 2018
    svotib and jolek like this.
  12. 1,430
    1,101
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,430
    Likes Received:
    1,101
    Trophy Points:
    347
    Gender:
    Male
    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.
     
  13. 708
    1,246
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    708
    Likes Received:
    1,246
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    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.
     
  14. 1,430
    1,101
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,430
    Likes Received:
    1,101
    Trophy Points:
    347
    Gender:
    Male
    Not you. [​IMG]
    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.

    I don't know how to write it, but maybe soon someone can ask about support for 720p 50 Hz.
    Probably Kernelloader don't have support for that mode, but...
    like I wrote someone can ask about it. [​IMG]

    Even so, thanks for many updates that you made for OPL and GSM.
     
  15. 1,054
    546
    222
    TnA

    TnA Senior Member

    Joined:
    Jul 1, 2018
    Messages:
    1,054
    Likes Received:
    546
    Trophy Points:
    222
    Gender:
    Male
    Location:
    Germany --> Saxony
    @jolek : 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! ;)


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


    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.
     
    Last edited: Aug 3, 2018
    jolek likes this.
  16. 1,430
    1,101
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,430
    Likes Received:
    1,101
    Trophy Points:
    347
    Gender:
    Male
    You're killing me. [​IMG]
    Of course my TV supports 576p (even 1080p).
    I've tested this resolution (576p) with SCPH-77004 and it worked.
    Although it was some time ago.
    Natively only SCPH-75000 and later should support 576p.
    Not only I have problem with this res:
    http://psx-scene.com/forums/f291/gs...ment-feedback-61808/index301.html#post1218231.

    But soon maybe it'll change thanks to SP193 updates

    BTW I can also select this resolution with PS3 and everything is fine.

    [​IMG]

    I knew it: [​IMG]
    Even eliminate black borders.
     
    Last edited: Aug 3, 2018
  17. 1,054
    546
    222
    TnA

    TnA Senior Member

    Joined:
    Jul 1, 2018
    Messages:
    1,054
    Likes Received:
    546
    Trophy Points:
    222
    Gender:
    Male
    Location:
    Germany --> Saxony
    The picture should be exactly the same, so if a game has black borders in 720p or 1080i @60Hz, it should be exactly the same for @50Hz! ;)

    However... Those timing-dependent glitches probably could be circumvented.
     
    jolek likes this.
  18. 708
    1,246
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    708
    Likes Received:
    1,246
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    Today's build: https://www.sendspace.com/file/sk9g5g

    • 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). [​IMG]
    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

    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.

    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...

    Other than figuring out the pixel clock rate and some settings under SMODE1: http://psx-scene.com/forums/f291/gs-mode-selector-development-feedback-61808/#post457673
    The SYNC* registers should be updated as well, since the signal probably has different characteristics from the normal 60Hz signals. The DVE might need to have other settings applied too.

    Thank you for your continued support.

    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.

    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?
     
    Last edited: Aug 3, 2018
    Tupakaveli and kozarovv like this.
  19. 1,430
    1,101
    347
    jolek

    jolek Senior Member

    Joined:
    Dec 29, 2017
    Messages:
    1,430
    Likes Received:
    1,101
    Trophy Points:
    347
    Gender:
    Male
    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),
    [​IMG]
    [​IMG]
    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:
    It was a quick test so I only tested 576p and 480p V-modes.
    I'll try to understand at least some of stuff that you wrote. [​IMG]
    It will be nice if standalone GSM also have:
    • DTV 576p for consoles with ROM below 2.10
    • Emulate FIELD flipping
     
    Last edited: Aug 3, 2018
    sandungas likes this.
  20. 1,054
    546
    222
    TnA

    TnA Senior Member

    Joined:
    Jul 1, 2018
    Messages:
    1,054
    Likes Received:
    546
    Trophy Points:
    222
    Gender:
    Male
    Location:
    Germany --> Saxony
    @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! ;)
     

Share This Page