GS Mode Selector: Development & Feedback

[doctorxyz]

@kekken3,

You're welcome!

@urbigbro,

Thanks for helping the new psx-sceners join us here, clarifying them about how contribute more effectively!

I am analysing the source code differences between v0.21 and v0.22 releases in order to discover what happened to that nice SYNCV VGA@60Hz vmode, that work only on v0.21 release.

@all,
After reading this thread from ps2dev (http://forums.ps2dev.org/viewtopic.php?p=81630), I infere that uufyugi could help us on better understanding of undocummented GS Registers.

I've already tried to register myself into the ps2dev site a dozen times without success... :-(...

So, if someone reading this thread could contact uufyugi, asking him for help us, giving information about undocummented GS Registers, this simple - but useful - action would much appreciated!

@all german-speakers psx-sceners,
If when reading this thread (http://www.ps3-tools.de/thread.php?g...065cde2a33eee6) you find something useful for our thread, please translate the essential and put here okay! Tks in advance.

BR,

[Vegeta]

After reading this thread from ps2dev (http://forums.ps2dev.org/viewtopic.php?p=81630), I infere that uufyugi could help us on better understanding of undocummented GS Registers.

I've already tried to register myself into the ps2dev site a dozen times without success... :-(...

Please check your PM

[doctorxyz]

Please check your PM

I've just posted on that thread and sent a PM to uufyug, too!
Tks for your help.

EDIT:SYNCV VGA vmodes back to the life!
@all

I finally got the Interlaced SYNCV VGA 1280x896i@60Hz vmode again in a v0.22g beta version (mine) based on v0.22c beta version (dlanor).

Due to my restrictions of time, I focused the tests only to get GT4 gameplay built-in progressive(480p) and HTDV(1080i) functionality without BSOD when playing at my VGA LCD Monitor.

For one hand, I had to disable the independent GS Register patch to got it; unhappily I will have no time to discover on next weekend the exact reason of that failure, in order to have SYNCV vmodes together with independent GS Registers patching (no time for coding, just for testing).

For other hand, I realised that we could keep the FFMD field unchanged when patching the SMODE2 register, at least on GT4 title when forcing it to Interlaced SYNCV VGA 1280x896i@60Hz.

I dunno if we could use the same approach for a progressive SYNCV VGA 1280x896i@60Hz. I dunno even if such mode would work.

So more study and testing are needed when forcing other titles into this vmode; in order to achieve this goal, I intend to test some titles on this weekend.

@dlanor,
ASAP I will send to you my source code in order to mix up with your latest beta relase okay!

BR,

[urbigbro]

EDIT:SYNCV VGA vmodes back to the life!
@all

I finally got the Interlaced SYNCV VGA 1280x896i@60Hz vmode again in a v0.22g beta version (mine) based on v0.22c beta version (dlanor).

Awesome, this is the "VGA" mode that works the best for me so far. I realize that it is not progressive, and will test it on some other displays, to see what results I can get.

Seeing as we already have this somewhat "Hybrid" video mode, can any others be done? Two that I can think of right now are, PAL 60i, and PAL resolution with NTSC color encoding.
I'm specifically interested in the the PAL resolution with NTSC color encoding, because many of us in North America would love to play some games only released in PAL format, without having to use the inferior PAL-NTSC patching that cuts off part of the games resolution.

Many HDTV's sold in North America have PAL and NTSC support. Many of the SD TV's also have support for PAL, but almost none have a SCART connector, so unless the TV has component-in were screwed.
I multi-system SD TV. It will display PAL games resolution correctly, but only has s-video in, so the color is only black and white.

If this can't be done, that's cool, I realize that this video format may not even, be recognized by a TV, even if it is possible.

[DarkCrono666]

Hi guys!
This is a great elf, have a lot of potential.
Well, I just bought a component cable to my ps2. I have a 700XX modded with a matrix clone. My PS2 are conected to my pc monitor AOC 15" trough a vga tv box (ZOGIS Real Angel HD1680).
I did some tests with a sort of games, but none of the vga modes has a correct screen.
- VGA 640 @ 60Hz = purple colors. I've try to change the color cable mode on ps2 to RGB with no changes. ZOGIS tell me 480P @ 60Hz
- VGA 640 @ 75Hz = don't turn any data to my monitor. My ZOGIS warn me that the mode was 720P @ 50Hz!!!
- VGA 640 @ 72Hz = same as above
- VAG 1024 @ 75Hz = same as above
I really don't know why, but it say @50Hz
Some of the others modes are functing well except the PAL and 576P, I think my PS2 model doen't work with them.

The games: With de P modes neither GT4 and FFXII functioned
But XII with 1080I gone very well.
Killzone worked well with all modes until the loading of the game, it freeze at some part. Really great graphics at 720P, but still freezing.
Someone knows why the original 720P and 1080I from the GT4 doesn't get stored? Even if I put OK it backs to 480I...
If was good to you I can put more results.

(In Portuguese)
Doctorxyz eu sou do Brasil, então se quiser perguntar alguma coisa em português é só dizer, no que eu puder ajudar é claro!

[dlanor]

I finally got the Interlaced SYNCV VGA 1280x896i@60Hz vmode again in a v0.22g beta version (mine) based on v0.22c beta version (dlanor).

I have received your v0.22g update file in email, and am ready to start merging it with my own sources.

Due to my restrictions of time, I focused the tests only to get GT4 gameplay built-in progressive(480p) and HTDV(1080i) functionality without BSOD when playing at my VGA LCD Monitor.

I see. I only hope this did not lead to any changes that will affect other games or tools badly in enforced vmodes. Focusing only on one test program can be risky.

For one hand, I had to disable the independent GS Register patch to got it;

And ? What is the problem with that ?

In my v0.22c beta I added the ability to disable/enable independent patches, as I know that some games require them (because I have such games), but also suspected that some games might show negative effects of such patching. I don't think we will ever be able to invent any default settings that will satisfy all games, and adapting settings 'on the fly' to suit different games will not be easy to do either. So for the present (at least) it will for some games be necessary that the user tweaks some settings in the GSM GUI, so as to adapt its usages for games with special needs.

unhappily I will have no time to discover on next weekend the exact reason of that failure, in order to have SYNCV vmodes together with independent GS Registers patching (no time for coding, just for testing).

As far as I could tell you have not removed the independent register patching from the new source code anyway, so I have no problem merging it. As I see it we can already have SYNCV vmodes together with independent register patching, as long as the patch values do not mess up the vmode setup. And if that happens we'll just have to modify how/when we apply those patches, or simply disable the separate patching in the GUI. We may also need to add more custom modes for specific games, but since we use button combos for almost everything, we are not going to run out of combinations for a while yet.

For other hand, I realised that we could keep the FFMD field unchanged when patching the SMODE2 register, at least on GT4 title when forcing it to Interlaced SYNCV VGA 1280x896i@60Hz.

For some cases we can do that without problems, but not for all cases.

I dunno if we could use the same approach for a progressive SYNCV VGA 1280x896i@60Hz. I dunno even if such mode would work.

It's a contradiction in terms anyway, to speak of progressive and 896i for the same vmode, but aside from that there are some real problems involved too. One of those is to pump VRAM data at 1280x896p@60 speed, which I'm not sure we can do without affecting some games badly. But if you can make it work, so much the better

So more study and testing are needed when forcing other titles into this vmode; in order to achieve this goal, I intend to test some titles on this weekend.

Good, but I'll focus more on the HDTV usage for my own testing.

@dlanor,
ASAP I will send to you my source code in order to mix up with your latest beta relase okay!

I have it and will proceed with my merging.
Expect a release later tonight or tomorrow.

Btw: Did you manage to make the "-save-temps" flag work right under MinGW+MSYS yet ?
It really is a great way to debug some things, so I hope you can get it to work as intended.

Best regards: dlanor

[dlanor]

Hi guys!
This is a great elf, have a lot of potential.
Well, I just bought a component cable to my ps2. I have a 700XX modded with a matrix clone. My PS2 are conected to my pc monitor AOC 15" trough a vga tv box (ZOGIS Real Angel HD1680).
I did some tests with a sort of games, but none of the vga modes has a correct screen.
- VGA 640 @ 60Hz = purple colors. I've try to change the color cable mode on ps2 to RGB with no changes. ZOGIS tell me 480P @ 60Hz
- VGA 640 @ 75Hz = don't turn any data to my monitor. My ZOGIS warn me that the mode was 720P @ 50Hz!!!
- VGA 640 @ 72Hz = same as above
- VAG 1024 @ 75Hz = same as above
I really don't know why, but it say @50Hz
Some of the others modes are functing well except the PAL and 576P, I think my PS2 model doen't work with them.

The ZOGIS TV 'boxes' are in fact converters intended to get normal HDTV signals on its component inputs and transform this into VGA output signals for a computer monitor.

But when GSM is producing VGA signals, the ZOGIS box doesn't know how to deal with them, since that is not what it was created to deal with. (effectively converting VGA to VGA). The result is therefore the same as you get when connecting VGA signals to Component inputs of an HDTV set not intended for RGB input, which always gives those purplish screens.

If you want to test the VGA modes of GSM, then you need to use a much simpler adaptor to connect it to the VGA monitor, and if that is a Sync-On-Green monitor such an adaptor can be very simple indeed. All it takes are six separate connections to the VGA connector, as follows:

Component RCA connectors                    --> VGA connector
  Y   Signal == RCA 1 center (Green signal) --> VGA Pin 2 == Green Signal (with SoG)
  Y   Ground == RCA 1 shield (Green shield) --> VGA Pin 7 == Green Ground
Cb/Pb Signal == RCA 2 center (Blue signal)  --> VGA Pin 3 == Blue Signal
Cb/Pb Ground == RCA 2 shield (Blue shield)  --> VGA Pin 8 == Blue Ground
Cr/Pr Signal == RCA 3 center (Red signal)   --> VGA Pin 1 == Red Signal
Cr/Pr Ground == RCA 3 shield (Red shield)   --> VGA Pin 6 == Red Ground

This is what I use myself, and it works fine, but it demands a Sync-On-Green monitor.
Otherwise extra circuits are needed to produce the separate sync signals.

The games: With de P modes neither GT4 and FFXII functioned
But XII with 1080I gone very well.

FFXII released for NTSC regions works in all interlaced modes, but no progressive modes.

FFXII released for PAL regions works only in "PAL 512i" and "HDTV 576p" (so with this one progressive mode does work), but it does not work in any other modes, not even the interlaced ones where the game releases for NTSC regions do work.

Apparently FFXII has custom patching of its own for GS registers that we do not as yet control, which leads to some kind of vmode conflicts. Hopefully that can be fixed in the future, but for the present the choice of vmodes for FFXII remains quite limited.

GT4 has special problems which doctorxyz has been working on.

Killzone worked well with all modes until the loading of the game, it freeze at some part. Really great graphics at 720P, but still freezing.

Many games work only in vmodes 'close' to what they were originally made for. So try it lower rez modes too, like 480p and if you have a modern PS2 also 576p (will not work on older consoles though).

Someone knows why the original 720P and 1080I from the GT4 doesn't get stored?

I don't understand exactly what you mean by 'get stored' here. If you mean that the game changes the vmode to its original mode anyway, so that GSM has no real effect, that is a possibility with some games, as they can even reinstall the trap system completely, totally removing our GSM traps too. But I don't think it is quite so bad with that game, since doctorxyz reports some success in adapting GSM to it. But apparently this demanded some extra attention beyond what works for other games.

(In Portuguese)
Doctorxyz eu sou do Brasil, então se quiser perguntar alguma coisa em português é só dizer, no que eu puder ajudar é claro!

I agree that you and doctorxyz may find it easier to converse in portuguese, this being your native language, but perhaps it is better if you use PM for conversation that the rest of us can't understand well. And then doctorxyz can inform us of any news this leads to here in the forum.

Best regards: dlanor

[DarkCrono666]

The ZOGIS TV 'boxes' are in fact converters intended to get normal HDTV signals on its component inputs and transform this into VGA output signals for a computer monitor.

But when GSM is producing VGA signals, the ZOGIS box doesn't know how to deal with them, since that is not what it was created to deal with. (effectively converting VGA to VGA). The result is therefore the same as you get when connecting VGA signals to Component inputs of an HDTV set not intended for RGB input, which always gives those purplish screens.

If you want to test the VGA modes of GSM, then you need to use a much simpler adaptor to connect it to the VGA monitor, and if that is a Sync-On-Green monitor such an adaptor can be very simple indeed. All it takes are six separate connections to the VGA connector, as follows:

Component RCA connectors                    --> VGA connector
  Y   Signal == RCA 1 center (Green signal) --> VGA Pin 2 == Green Signal (with SoG)
  Y   Ground == RCA 1 shield (Green shield) --> VGA Pin 7 == Green Ground
Cb/Pb Signal == RCA 2 center (Blue signal)  --> VGA Pin 3 == Blue Signal
Cb/Pb Ground == RCA 2 shield (Blue shield)  --> VGA Pin 8 == Blue Ground
Cr/Pr Signal == RCA 3 center (Red signal)   --> VGA Pin 1 == Red Signal
Cr/Pr Ground == RCA 3 shield (Red shield)   --> VGA Pin 6 == Red Ground

This is what I use myself, and it works fine, but it demands a Sync-On-Green monitor.
Otherwise extra circuits are needed to produce the separate sync signals.

So I can't get any use until I use a vga SoG to vga adaptor... I'll try to find it to buy.

FFXII released for NTSC regions works in all interlaced modes, but no progressive modes.

FFXII released for PAL regions works only in "PAL 512i" and "HDTV 576p" (so with this one progressive mode does work), but it does not work in any other modes, not even the interlaced ones where the game releases for NTSC regions do work.

Apparently FFXII has custom patching of its own for GS registers that we do not as yet control, which leads to some kind of vmode conflicts. Hopefully that can be fixed in the future, but for the present the choice of vmodes for FFXII remains quite limited.

My PS2 is a old one, from 2005, will not work...

GT4 has special problems which doctorxyz has been working on.

Maybe we can try it on Tourist Trophy, same GT4 tecnology, just to see the results.

Many games work only in vmodes 'close' to what they were originally made for. So try it lower rez modes too, like 480p and if you have a modern PS2 also 576p (will not work on older consoles though).

I've tried on the others too, still freezing in some part of the loading. The Menus until the game begins are ok.

I don't understand exactly what you mean by 'get stored' here. If you mean that the game changes the vmode to its original mode anyway, so that GSM has no real effect, that is a possibility with some games, as they can even reinstall the trap system completely, totally removing our GSM traps too. But I don't think it is quite so bad with that game, since doctorxyz reports some success in adapting GSM to it. But apparently this demanded some extra attention beyond what works for other games.

My problem are solved, GT4 just don't store the progressive or 1080I options, so any time you turn off the ps2 you have to change it again.

I agree that you and doctorxyz may find it easier to converse in portuguese, this being your native language, but perhaps it is better if you use PM for conversation that the rest of us can't understand well. And then doctorxyz can inform us of any news this leads to here in the forum.

Best regards: dlanor

Sorry about my poor english. The portuguese part was just some kind of warn, maybe I can help he in some way since in portuguese I can explain better my results

I have a ideia too. If possible, you can add others loaders, just like HD_Gui from the VMC emulator. Or a configurable path to a especific loader.
And a question, what will happen if I just put a loader with the HD_loader.elf name other than HD_loader? Could I load uLE in this way?

Congrats for your great job!

---------------------------------------

My tests with the Tourist Trophy return a strange result:
With the same graphic engine, GT4 get BSOD after the SCEA logo, in this game it's never showed up, I've tried in all graphic modes.

[doctorxyz]

@all

Since my English is poor, I believe it could better to clarify some personal motivations behind some of my actions, in order to avoid misunderstandings okay!

GT4 is just my favourite game and I frequently play it on my VGA LCD monitor, and rarely on my LCD HDTV set (if I do this latter frequently instead, probably this thread does not exist).

My motivation started when I used to play GT4 on my monitor using MI (Matrix Infinity) modchip built-in target VGA vmode enabled, but it worked only when forcing a target VGA@60Hz vmode from the source (and default) GT4 vmode: Interlaced (480i). The final results was very poor, compared to my HDTV set. Naturally, I tried solve it, just changing the source (GT4 built-in) vmode to Progressive(480p) or HDTV(1080i) using the GT4 built-in menu - Since I knew that the framebuffer and real game resolution have better quality when selecting those modes... But it was without success: MI always gave me a display doubled in heigth, cutting off the bottom half part of game screen!

After that, I decided to start a extensive research for a solution to my problem, that worked also with HDLoader... Some months later... Here we are my friends! ;-)

So, please do not worry when I am focus my testing on GT4 game okay!

I know that are many people interested on GSM (thank God for it) and I will try to respect all your different needs and opinions; this is the reason we are improving this project in order to work with many titles, vmodes, and people as possible (let's recognize tht all of them is, in fact, impossible).

Awesome, this is the "VGA" mode that works the best for me so far.

For me too.

I realize that it is not progressive, and will test it on some other displays, to see what results I can get.

Seeing as we already have this somewhat "Hybrid" video mode, can any others be done? Two that I can think of right now are, PAL 60i, and PAL resolution with NTSC color encoding.
I'm specifically interested in the the PAL resolution with NTSC color encoding, because many of us in North America would love to play some games only released in PAL format, without having to use the inferior PAL-NTSC patching that cuts off part of the games resolution.

Many HDTV's sold in North America have PAL and NTSC support. Many of the SD TV's also have support for PAL, but almost none have a SCART connector, so unless the TV has component-in were screwed.
I multi-system SD TV. It will display PAL games resolution correctly, but only has s-video in, so the color is only black and white.

If this can't be done, that's cool, I realize that this video format may not even, be recognized by a TV, even if it is possible.

It could be done in a GSM future release, by implement patching only for the SetGsCrt Mode parameter, i.e., changing it from 3(PAL) to 2(NTSC), leaving other vmode parameters unchanged (DW,DH,MAGH,MAGV). Then, test it to see what happens. Maybe some DX and DY adjustment should be needed here.

I have received your v0.22g update file in email, and am ready to start merging it with my own sources.

I see. I only hope this did not lead to any changes that will affect other games or tools badly in enforced vmodes. Focusing only on one test program can be risky.

Do not worry about that. It is just a question of personal interest and time for testing. Nothing more than this, as I stated in the beginning of this post okay!

And ? What is the problem with that ?

The problem is... I see how you improve the quality of source code, despite of it is not perceived by final user. It would be a pity to just cut it off from GSM before making a deeper investigation in order to discover the real reason why the SYNCV stopped to work on v0.22 release.

In my v0.22c beta I added the ability to disable/enable independent patches, as I know that some games require them (because I have such games), but also suspected that some games might show negative effects of such patching. I don't think we will ever be able to invent any default settings that will satisfy all games, and adapting settings 'on the fly' to suit different games will not be easy to do either. So for the present (at least) it will for some games be necessary that the user tweaks some settings in the GSM GUI, so as to adapt its usages for games with special needs.

As far as I could tell you have not removed the independent register patching from the new source code anyway,

I hope you realised that what I did on v0.22g was - among other things - putting the breakpoint setting back to trap writes for DISPLAYx GS Registers only, disabling the ones the SMODE2 and SYNCV GS Registers.

so I have no problem merging it. As I see it we can already have SYNCV vmodes together with independent register patching, as long as the patch values do not mess up the vmode setup. And if that happens we'll just have to modify how/when we apply those patches, or simply disable the separate patching in the GUI. We may also need to add more custom modes for specific games, but since we use button combos for almost everything, we are not going to run out of combinations for a while yet.

For some cases we can do that without problems, but not for all cases.

I see your point. FYI: The old Blaze VGA app has specific seems to have specific patchs for some titles, since that app has a optional game list that you can choose after booting the title from CD/DVD.

It's a contradiction in terms anyway, to speak of progressive and 896i for the same vmode

It was a distraction.

, but aside from that there are some real problems involved too. One of those is to pump VRAM data at 1280x896p@60 speed, which I'm not sure we can do without affecting some games badly. But if you can make it work, so much the better

I see.. Anyway I will give a chance more for that vmode... If it won't work, I will forget it. Okay, maybe I am a sttuborn person! ;-)

Good, but I'll focus more on the HDTV usage for my own testing.

This is great for the project, since you are focusing on the HDTV testing and me on the VGA one; they are complementary and improve the development/testing speed.

I have it and will proceed with my merging.
Expect a release later tonight or tomorrow.

No problem about that, do it when possible.

Btw: Did you manage to make the "-save-temps" flag work right under MinGW+MSYS yet ?
It really is a great way to debug some things, so I hope you can get it to work as intended.

After better analysing, when enabling that flag, before get the error some .i and .s files are created (and not deleted), so the flag is working. There are something bad with my ps2toolchain, since a problem occurs right after that, because the compiler suddenly stops and gives me the following error message:

C:/msys/1.0/local/ps2dev/ps2sdk/ee/startup/crt0.o(.text+0x134): In function `_ex
it':
src/crt0.s:150: undefined reference to `main'
make: *** [GSM.ELF] Error 1

I've just inspected the crt0.s:150 row here

C:\msys\1.0\local\ps2dev\ps2sdksrc\ee\startup\src\crt0.s

I dunno if this is the correct .s file related for the crt0.o file on that error messae, anyway here it is a code excerpt with row #150:

(...)
	.ent	_exit
_exit:
	# Call global deconstructors through _fini().
	la	$8, _fini <--This is the row #150!
	beqz	$8, 3f		# does _fini() exist?
	nop

	jalr	$8
	nop
3:
	# Call ps2sdk's libc deinitialisation.
	jal     _ps2sdk_libc_deinit
	nop
	
# If we received our program arguments in a0, then we were executed by a
# loader, and we don't want to return to the browser.
	la	$4, _args_ptr
	lw	$5, ($4)
	beqz	$5, 1f
	move	$4, $2		# main()'s return code

	lw	$6, ($5)
	sw	$0, ($6)
	addiu	$3, $0, 36
	syscall			# ExitDeleteThread(void)

# Return to the browser via Exit()
1:
	addiu	$3, $0, 4
	syscall			# Exit(void)
	.end	_exit

(...)

(In Portuguese)
Doctorxyz eu sou do Brasil, então se quiser perguntar alguma coisa em português é só dizer, no que eu puder ajudar é claro!

I agree that you and doctorxyz may find it easier to converse in portuguese, this being your native language, but perhaps it is better if you use PM for conversation that the rest of us can't understand well. And then doctorxyz can inform us of any news this leads to here in the forum.

The portuguese part was just some kind of warn, maybe I can help he in some way since in portuguese I can explain better my results

DarkCrono666,
Cool. So let's exchange info in Portuguese by PM whenever necessary okay!

dlanor,
Last week a "more and less" similar episode happened on Open USB Loader and I politely asked for our german mates to write in English.

all,
In my modest opinion, since PSX-Scene is a English forum it is reasonable to write only on this language; moreover, this is a great chance to improve writing skills.

Maybe we can try it on Tourist Trophy, same GT4 tecnology, just to see the results.

It makes sense and you certaily could do that.

I've tried on the others too, still freezing in some part of the loading. The Menus until the game begins are ok.

(Which follows is just my speculations) The reason of these freezing could be:
- V-Blank miss (due to not enough optimization on DisplayHandler routine... This is expected since we are in beta stage of project)
- Lacking of proper branch delay slot handling on DisplayHandler (maybe we have this solved soon, candidate code already sent to dlanor validation).
If you didn't understand, do not worry. It is a Martian explanation... BTW: I am a Martian ;-)

I have a ideia too. If possible, you can add others loaders, just like HD_Gui from the VMC emulator. Or a configurable path to a especific loader.

ASAP. We are focusing on the main functionalities first;anyway...

And a question, what will happen if I just put a loader with the HD_loader.elf name other than HD_loader? Could I load uLE in this way?

...I believe this turnaround be enough for you, or you could use FMCB menu instead (learn more on that on its threads).

Congrats to your great job!

Thanks a lot!

BR (=Best Regards),

[dlanor]

@doctorxyz:
Like I told you in email too earlier today, I have now analyzed your v0.22g beta closer and have found where you disabled the monitoring and patching of other GS registers than DISPLAY1 and DISPLAY2 in our access trap routine. I assume it was needed for making GT4 work like you want it to, but I am sure other ways can be found to the same effect.

The extended register control is definitely needed for other games, not at all working well with current GSM (including your beta), such as FFXII (and especially the PAL versions of it).

I am getting the GT4 game myself, so I can look for a solution also compatible to it, but this will delay the next release a bit. However, I see little point in making a release at this stage using the main source file of v0.22g, since that just works like v0.21 did, plus one new vmode and some new menu commands with no effect (as they control multiple register patching).

If you think that it should be released anyway, feel free to do so, but I will hold off on releases myself until I can make one with more significant changes (and still working with your GT4 )

As for the HDTV vs VGA testing, I really can do a little of both even without using my VGA monitors for it, since my HDTV set has a VGA input with SoG support and I made an adaptor for connecting my PS2 component cable to that VGA port. This works fine, so I can test all currently implemented VGA modes of GSM on that HDTV set.

Best regards: dlanor