GS Mode Selector: Development & Feedback

[E P]

I'm sure other devs will appreciate the documentation and commenting. (EP has already expressed an interest in this project.) The docs should make the learning process much quicker for new devs.

My interest is particularly from a user standpoint first and foremost. I don't know if I'll be directly contributing to the project in terms of code but you never know. Right now I have a lot of irons in the fire so only time will tell.

On to some of my own tests on my v4 PS2 using an official Sony PS3 component cable:
Primary test sequence with the tv modes listed according to my HDTV. On the left is the listed mode that corresponds to the description that led to the listed mode.

720x480i @60Hz <- started console, free mcboot loaded
720x240 @60Hz <- launched uLE v4.40 using mcboot OSD menu
720x480i @60Hz <- ran ps2link EEUG version off memory card
720x240 @60Hz <- executed GSM.ELF with ps2client
720x480 @60Hz <- set the mode to 480p and went to PS2 Browser
720x480 @60Hz <- Free mcboot splash screen appears
no signal <- PS2 OSD menu
720x480 @60Hz <- listened for sounds through optical out and blindly got back to uLaunchELF, which is half sized do to interlace being off
720x480 @60Hz <- ran ps2link EEUG version off memory card yet again
no signal <- executed GSM.ELF with ps2client where the system shortly locks up after loading the ELF

It probably crashes because it can't catch itself, but it does a fine job at staying alive in the tests. It's nice to see that once the display mode was changed to 480P it stayed pretty well locked in.

I did try out pixel's beats of rage PS2 port in place of reloading GSM.ELF at the final step above. It worked at 720x480 @60Hz, 480P, and the gameplay sped way up. Anyway, this program really looks like it's going to be something to keep an eye on.

[stefanol69]

Exactly what do you mean by "scaling doesn't work"
Inside the GSTest or GSM program scaling NEVER works, but outside it should always work.

It was a note, the uLE, which was run before GSTest gave garbage behind. I treated is as normal behaviour.

Same thing on my v7, but works fine on my v15
This failure means that your GS chip doesn't have 576p

I don't know on that part. From what I remember, I was succesfully using Xploder HDTV with 576p, but back then I was using different TV (42" LG, I will move PS2 to the other room to see what's happening.

If by "uLE in the background" you mean while still inside GSTest/GSM, this is fine
We neverclean out the Framebuffer here (and the garbage is helpful for visual feedback)

This can either mean that your GS chip doesn't handle 1080i, but it can also mean that your TV doesn't like that resolution. Since the console didn't freeze I suspect the TV, as the GS usually crashes for unsupported modes

Again, I have no clue. My External Media Player works in 1080i without problems, but my guess is it is using different 1080i than PS2.

But did they crash PS2 or not ?

No, I was able to switch back to other screen modes. The only one that froze my console was 576p.

There is one more thing you can contribute, and this is something we really want from all who report on GSM results.

What is your console's product code and bios version ?

It is V12, SCPH-70003.
ROMVER is "0200EC20040614"
Version I used was GSTest 1.01

I will perform some more tests later, and hope to provide some pictures. HDLoader loads in 480p with no problems, image looks like 4:3, no matter what mode my TV is set on. GTA Vice City Stories freezes upon loading (black screen), Beyong Good & Evil (which has 480p implemented) gives "No Signal" after blinking a text of some kind.

[dlanor]

I tested ULE through GSM v0.18 and the scaling was identical to how it is in games i.e big borders. I don't know whether it is to do with my GS chip or whether its a combination of PS2 hardware and TV software causing this but I noted down the ROMVER of my V10 PS2:

I think this has to be due in part to some scaling error of the TV, though I can't test that.

0190EC20030623_

Good. As yet we have too little to go on, but in time we may see a pattern between ROMVER version/date and GS abilities.

I have my TVs aspect ratio set to 16:9 and not Auto for testing.

That is the correct setting for all normal testing as we want the response for full-screen mode of the TV.

576p also doesn't work with my PAL V10 PS2 via GSM but it does work with Xploder HDTV Player so I know my PS2 can output at 576p.

That's odd, but not entirely surprising.

We know that the translation from vmode code to physical sync and pixel encoding settings is handled by 'SetGsCrt' to allow compensation for GS chip differencies. This also means that the vmodes SetGsCrt will accept can have other limitations than those needed by the GS hardware.

So it is possible for the Xploder HDTV Player to directly access GS registers with values appropriate for that version of the GS chip, even though the SetGsCrt function in the bios of that console had not been upgraded to recognize that vmode.

Best regards: dlanor

[dlanor]

720x240 @60Hz <- executed GSM.ELF with ps2client
720x480 @60Hz <- set the mode to 480p and went to PS2 Browser
720x480 @60Hz <- Free mcboot splash screen appears
no signal <- PS2 OSD menu
720x480 @60Hz <- listened for sounds through optical out and blindly got back to uLaunchELF, which is half sized do to interlace being off

This half sizing is due to an error in the code of uLE. Our routines for setting up the screen usage never inform the GS about the correct screen height to be used for the DH field of the DISPLAYx registers, so when we switch to non-interlaced mode and reduce the useful part of the screen to 224 pixels (unscaled, thus also 224 raster lines), the GS register is still set up for 448 raster lines, so that is what GSM uses for its scaling.

Since those 448 lines of the virtual vmode are close to the physical 480 raster lines of the physical vmode, GSM can't apply any other scale factor than 1, so the 224 pixel lines rendered by uLE will then be displayed as 224 raster lines on a screen of 480 such lines, thus squashing the uLE screen.

In my 'home' beta I have fixed this by using the correct height value in the gsGlobal struct used to pass parameters to most of the gsKit functions. The critical changes are inside the functions 'setupGS' and 'updateScreenMode' of uLE's "draw.c". These changes have tested out well and will be part of a future uLE v4.41

With those changes in place the non-interlaced screen of uLE will be scaled by GSM to exactly the same height as the interlaced screen, using scale factors of 2 and 1 respectively. With GSM enforcing 480p, the only visible result of switching interlace on/off in the uLE config menu is that the fine detail of lines will change, as interlace shows different pixel lines for all 448 raster lines used by uLE, while non-interlace repeats each of 224 pixel lines twice.

720x480 @60Hz <- ran ps2link EEUG version off memory card yet again
no signal <- executed GSM.ELF with ps2client where the system shortly locks up after loading the ELF

It probably crashes because it can't catch itself,

Not only that, but it also builds an eternal loop by having a routine linked in that at the end jumps to itself, when it should jump to the routine that was installed before the first GSM activation. In principle it tries to do a right thing, since it does link to the previously active routine, but that is not valid when it is an earlier instance of itself, residing at the same address. Then the routine loops forever.

This can be cured by adding code that looks for a previous instance and unlinks it (also deactivating whatever else may be needed in future versions), and then relinks the new instance. Alternatively the new instance of the main program could just leave the old instance of the KSEG code unchanged, once it has identified it as being valid. Either way should eliminate this problem, and allow the GSM GUI to be reentered for fine tuning or changing the enforced mode even while it is is active already.

but it does a fine job at staying alive in the tests. It's nice to see that once the display mode was changed to 480P it stayed pretty well locked in.

Yes, except for attempts to use USBAdvance.

With early versions this simply disabled the GSM work, and with current versions it tends to crash/freeze.

I did try out pixel's beats of rage PS2 port in place of reloading GSM.ELF at the final step above. It worked at 720x480 @60Hz, 480P, and the gameplay sped way up.

Other nice homebrews to use with GSM are SNES-Station and PS2Reality. I never really expected to run the SNES version of 'Chrono Trigger' in 1080i...

Anyway, this program really looks like it's going to be something to keep an eye on.

I believe it can already be used to replace many existing PAL-NTSC conversion methods as well as to force many commercial games to run on VGA monitors. Which is not bad for such an early beta...

Best regards: dlanor

[dlanor]

It was a note, the uLE, which was run before GSTest gave garbage behind. I treated is as normal behaviour.

Yes, that is quite normal. In some future version we will probably display a controlled test pattern instead, to give better visual feedback.

----- re: GS lacking vmode for 576p

I don't know on that part. From what I remember, I was succesfully using Xploder HDTV with 576p, but back then I was using different TV

In fact the vmode code is not implemented in the GS chip at all, but in the bios rom, which translates the vmode code into a set of GS register values intended to produce the correct vmode. Since software normally lags behind the hardware, it is quite normal for the bios to lack implementation for some vmode codes, even when the GS chip is capable of displaying those vmodes, when fed proper register values. And that is what I think the Xploder HDTV Player does, without calling the normal bios function to do it.

----- re: 1080i giving no picture, but not freezing

Again, I have no clue. My External Media Player works in 1080i without problems, but my guess is it is using different 1080i than PS2.

I'm not sure what variations are allowed even. I thought each of the HDTV modes has a definite specification when it comes to sync timing. With the only 'freedom' being how the equipment uses the (presumably) visible signal fields. But I am no expert on that.

But if your TV can handle 1080i and still just shows black screen for the PS2 signal, then it probably means that something is wrong with the implementation of that mode, if not in the GS chip itself, then in the bios function supposed to set up the GS registers.

----- re: VGA modes above 448p not displaying, but also not crashing

No, I was able to switch back to other screen modes.

This should mean that these vmodes are implemented by your console, but the TV will not accept them, or at least not on that input.

It is the same way with my TV. NTSC/PAL signals are accepted both on SCART and component inputs, but HDTV progressive signals and 1080i are only accepted on component inputs, while VGA signals above 448p@60 are only accepted on the special VGA port. Trying to use a signal in a port it is not intended for only leads to black screen.
(The one exception is VGA 448p@60, because it is so close to HDTV 480p standard, but it still gives wrong colours when connected by component)

The only one that froze my console was 576p.

As I understand it that was the last vmode for which support was added, so most older consoles lack it.

It is V12, SCPH-70003.
ROMVER is "0200EC20040614"
Version I used was GSTest 1.01

Interesting. I had thought that maybe all slims had all the vmodes, but evidently the 576p mode was added even later than bios 2.00.

I will perform some more tests later, and hope to provide some pictures. HDLoader loads in 480p with no problems, image looks like 4:3, no matter what mode my TV is set on. GTA Vice City Stories freezes upon loading (black screen), Beyong Good & Evil (which has 480p implemented) gives "No Signal" after blinking a text of some kind.

Most likely games that have their own support for non-PAL/NTSC vmodes will poke GS registers directly, and at present we only guard two of those registers, so if what we do with those two doesn't fit what the game does with the other registers, then all hell can break loose, which normally leads to either freezing or just black screen.

And as you've probably seen, black screen is also the normal result with games that really need interlaced mode, due to inappropriate coding methods of these games. (or so we theorize anyway...)

Best regards: dlanor

[E P]

In my 'home' beta I have fixed this by using the correct height value in the gsGlobal struct used to pass parameters to most of the gsKit functions. The critical changes are inside the functions 'setupGS' and 'updateScreenMode' of uLE's "draw.c". These changes have tested out well and will be part of a future uLE v4.41

Sounds great and there hasn't been a need to update the gsKit then. I recall ragnarok2040 making note of some necessary library changes, but I didn't know to what extent. I didn't know if it was anything that required updating uLE's gsKit library. However, I do know from my brief glances at the newer revamped gsKit sources that unofficial LaunchELF would need an overhaul of it's own to be made compatible. Judging from what I've both seen and heard, I take it applications should be mostly compatible with whichever gsKit version was used for most homebrew applications.

Not only that, but it also builds an eternal loop by having a routine linked in that at the end jumps to itself, when it should jump to the routine that was installed before the first GSM activation. In principle it tries to do a right thing, since it does link to the previously active routine, but that is not valid when it is an earlier instance of itself, residing at the same address. Then the routine loops forever.

I could see it make an attempt and then it just trips all over itself.

Either way should eliminate this problem, and allow the GSM GUI to be reentered for fine tuning or changing the enforced mode even while it is is active already.

Yeah, I was mainly interested in doing incremental tests, but I could see that as not a viable option at this time.

Other nice homebrews to use with GSM are SNES-Station and PS2Reality. I never really expected to run the SNES version of 'Chrono Trigger' in 1080i...

Nice, I pretty much consider Chrono Trigger is one of if not the greatest RPG's of all time. I played it to death back when I bought it for my Super Nintendo in 1995. The RPG glory days when new squaresoft games were 80 dollars a piece on plastic cartridges. My fear is if I dare start playing it again I might not be able to stop again.

I believe it can already be used to replace many existing PAL-NTSC conversion methods as well as to force many commercial games to run on VGA monitors. Which is not bad for such an early beta...

Yeah, I'm sure in the right hands it can be molded into something even better. It certainly took me by surprise.

[urbigbro]

Twisted Metal Head-On (patched w/VMC fix using save from MC)
480p- sped up game play, skip movies to prevent freezing of game
576i- works fine
1080i- works fine
720p- freezes
other modes untested

This seems to prove that the VMC fix is not affected by this program. Thank goodness!
I'll test MLB 09 sometime soon to verify it works also.

I wonder what weirdness may happen when I try to play a Guncom game designed for 480i, at 576i on my dual region compatible CRT TV? I don't have the proper non-CRT compatible gun to test for higher resolutions, but I will test VGA on my CRT monitors.
I'll test Crisis Zone that way and report back in a few days.

576p works great on the new SMS build just released, but will not work when selected in GSM .18. (blackscreen)
This is still with the same NTSC-U v9 PS2, and HP 2335 monitor.
PS2 ROM ver. ? guess I need to figure out how to get that

[unclejun]

Good. As yet we have too little to go on, but in time we may see a pattern between ROMVER version/date and GS abilities.

dlanor, there are some utilities that displays the GS revision such as Sony's official QATool 1.2 and the bios dumper called PS2Dump v2.0.



I'll test this GS Mode Selector soon...

[dlanor]

I do know from my brief glances at the newer revamped gsKit sources that unofficial LaunchELF would need an overhaul of it's own to be made compatible.

But that is a characteristic of many other libs too that have been updated without much regard for backwards compatibility. The entire PS2SDK is a typical example...

Judging from what I've both seen and heard, I take it applications should be mostly compatible with whichever gsKit version was used for most homebrew applications.

That is a good sign at least, so we might have better success at using a new version of this than we've had with the latest PS2SDK revisions. But then again, we don't know yet if that new gsKit version is dependent in any way on the new PS2SDK...

----- re: Re-launching the GSM GUI while GSM is already active

Yeah, I was mainly interested in doing incremental tests, but I could see that as not a viable option at this time.

Not quite yet, but it is high on my list.

Nice, I pretty much consider Chrono Trigger is one of if not the greatest RPG's of all time. I played it to death back when I bought it for my Super Nintendo in 1995. The RPG glory days when new squaresoft games were 80 dollars a piece on plastic cartridges. My fear is if I dare start playing it again I might not be able to stop again.

I've spent a lot of time with this game too (probably hundreds of hours). It is truly a great game, and so is also its non-sequel relative 'Chrono Cross' for the PS1 (though very different).

Anyway, I've decided to focus next on the GSM relaunch issue, as that is something which can accelerate the testing process, and thus help resolve other issues too.

Best regards: dlanor

[dlanor]

Twisted Metal Head-On (patched w/VMC fix using save from MC)
480p- sped up game play, skip movies to prevent freezing of game
576i- works fine
1080i- works fine
720p- freezes
other modes untested

It's interesting to note that the game works in 480p but froze in 720p. Assuming of course that the freezing only occurred after the game had started to launch (otherwise it is a normal GS/bios issue).

This seems to prove that the VMC fix is not affected by this program.

I would say so too, though I'm a bit vague here on what you meant by "using save from MC". For proper VMC usage this should mean that the save was loaded from a virtual MC residing on other media. But your statement is not quite clear on that point.

I wonder what weirdness may happen when I try to play a Guncom game designed for 480i, at 576i on my dual region compatible CRT TV? I don't have the proper non-CRT compatible gun to test for higher resolutions, but I will test VGA on my CRT monitors.
I'll test Crisis Zone that way and report back in a few days.

Most likely the game will work in at least some vmode, but with completely inaccurate gun, since the game's aiming algorithms will be based on a different physical vmode. And on an LCD or plasma screen, where the light intensity of a pixel is not a scan-induced pulse, I expect no gun aiming functionality at all. For such use an entirely different hardware implementation is needed.

576p works great on the new SMS build just released, but will not work when selected in GSM .18. (blackscreen)
This is still with the same NTSC-U v9 PS2, and HP 2335 monitor.

This fits in with other reports, as even the v12 model is reported to lack support for 576p in its bios, though it clearly does work in the GS hardware even of older models.

In the long run we must solve this by using some other means than the current "SetGsCrt" function to set the active vmode. If the bios is not in any way aware of how to use the newer vmode codes, then we have no choice but to set such modes by direct GS register access, which is a rather complex method. (It's not just a single value or a single register.) And this may need some research to work right.

Hmmm... I wonder how it was done in early versions of SMS ?
Since those versions were open-source, they are available for inspection.
If they too used register access for vmode setting, that might give us some leads for how best to do it.

PS2 ROM ver. ? guess I need to figure out how to get that

This is easily done in uLE, using "MISC/Debug Info" to display the rom0:ROMVER file.

Best regards: dlanor