GS Mode Selector: Development & Feedback

[reprep]

That's not quite how it works, you have to use VCK units for your calculations.

NTSC ~ 2560x480 VCK units
480p ~ 1280x480 VCK units

Suppose that we have a game internally rendering at 640x448:

To get it displayed in NTSC a horizontal scale factor of 4 and a vertical scale factor of 1 is used: 2560=640*4 and 480=448*1+overscan
To get it displayed in 480p a horizontal scale factor of 2 and a vertical scale factor of 1 is used: 1280=640*2 and 480=448*1+overscan

No problems here!

Now suppose that we have a game internally rendering at 512x448:

To get it displayed in NTSC a horizontal scale factor of 5 and a vertical scale factor of 1 is used: 2560=512*5 and 480=448*1+overscan
To get it displayed in 480p a horizontal scale factor of 2 and a vertical scale factor of 1 is used: 1280=512*2+black borders and 480=448*1+overscan

Since 1280 isn't a multiple of 512 the black borders are inevitable in such cases, at least as long as we are restricted to using integer (horizontal) scale factors.

If the game developers hadn't used internal resolutions as 512x448 in the first place, we wouldn't have such problems now (and sharper looking games, at the expense of some minor details). Blame Sony for giving such advices!
Let alone all the games using field rendering (the 'great' idea of using alternating 512x224 frame buffers). Oh, and the ever-present overscan bars

That makes things easier to understand. Is there any chance to manually control MAGH and MAGV values?
I know GSM doesn't let us choose them and calculates them on the fly according to DW and DH. But is there a manual override? I mean is there a physical restriction to not being able to use MAGH 4 (it means 5 in fact) and DH 2559 and 480p progressive mode for DISPLAY1/DISPLAY2 six bitfields for perfect match for 512x448 games?

[reprep]

@Ragnarok2040
Thanks a lot for precious info.

@dlanor
I you test*them, no ploblem! ;-)
I just dunno if I will do it today, or tomorrow.

BR,

* And retest them, since I am prone to make misunderstandings and errors :-D

EDIT:

@all

Which follows is the most complete and - and non-tested also - PS2 vmode list we can have for now.

I would be grateful if someone could carefully validate it.

Some rows can be checked only using the mentioned docs; others demand rule-of-three+tendency Excel calculations, binaries calculations and logical thought.

Despite of this contribution be totally optional, this "peer-review" task would be very appreciated here.

BR,

	//
	// Some of following vmodes gives BOSD and/or freezing, depending on the console version and the TV/Monitor set
	// I believe that this symptom is due to a sofware limitation - more specifically, on BIOS - prior than a hardware one
	//
	//	id		description						interlace			mode					field		display							dh		dw	magv	magh	dy	dx		syncv
	//	--		-----------						---------			----					-----		----------------------------------		--	----	----	--	--		------------------
	static GSM_predef_vmode predef_vmode[29] = {
//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
		{ 00 	, "NTSC p@60Hz Half Buffer",	GS_NONINTERLACED,	GS_MODE_NTSC,			GS_FRAME,	(u64)make_display_magic_number(  239 , 2559 , 0 ,   3 ,		25,	632 ,	0x00C7800601A01802	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 01 	, "NTSC i@60Hz Full Buffer",	GS_INTERLACED,		GS_MODE_NTSC,			GS_FIELD,	(u64)make_display_magic_number(  479 , 2559 , 0 ,   3 ,		50,	632 ,	0x00C7800601A01801	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 02 	, "PAL p@50Hz Half Buffer ",	GS_NONINTERLACED,	GS_MODE_PAL,			GS_FRAME,	(u64)make_display_magic_number(  287 , 2559 , 0 ,   3 ,		36,	652 ,	0x00A9000502101404	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 03 	, "PAL i@50Hz Full Buffer ",	GS_INTERLACED,		GS_MODE_PAL,			GS_FIELD,	(u64)make_display_magic_number(  575 , 2559 , 0 ,   3 ,		72,	652 ,	0x00A9000502101401	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 04 	, "VGA 640x480p@60Hz      ",	GS_NONINTERLACED,	GS_MODE_VGA_640_60,		GS_FRAME, 	(u64)make_display_magic_number(  479 , 1279 , 0 ,   1 ,		34,	276 ,	0x004780000210000A	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 05 	, "VGA 640x480p@75Hz      ",	GS_NONINTERLACED,	GS_MODE_VGA_640_75,		GS_FRAME, 	(u64)make_display_magic_number(  479 , 1279 , 0 ,   1 ,		18,	356 ,	0x0067800001000001	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 06 	, "VGA 800x600p@60Hz      ",	GS_NONINTERLACED,	GS_MODE_VGA_800_60,		GS_FRAME, 	(u64)make_display_magic_number(  599 , 1599 , 0 ,   1 ,		26,	420 ,	0x0089600001700001	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 07 	, "VGA 800x600p@75Hz      ",	GS_NONINTERLACED,	GS_MODE_VGA_800_75,		GS_FRAME, 	(u64)make_display_magic_number(  599 , 1599 , 0 ,   1 ,		23,	468 ,	0x0069600001500001	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 08 	, "VGA 1024x768p@60Hz     ",	GS_NONINTERLACED,	GS_MODE_VGA_1024_60,	GS_FRAME, 	(u64)make_display_magic_number(  767 , 2047 , 0 ,   1 ,		34,	580 ,	0x00CC000001D00003	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 09 	, "VGA 1024x768p@75Hz     ",	GS_NONINTERLACED,	GS_MODE_VGA_1024_75,	GS_FRAME, 	(u64)make_display_magic_number(  767 , 1023 , 0 ,   0 ,		30,	260 ,	0x006C000001C00001	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 10 	, "VGA 1280x1024p@60Hz    ",	GS_NONINTERLACED,	GS_MODE_VGA_1280_60,	GS_FRAME, 	(u64)make_display_magic_number( 1023 , 1279 , 0 ,   0 ,		40,	348 ,	0x0070000002600001	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 11 	, "VGA 1280x1024p@75Hz    ",	GS_NONINTERLACED,	GS_MODE_VGA_1280_75,	GS_FRAME, 	(u64)make_display_magic_number( 1023 , 1279 , 0 ,   0 ,		40,	380 ,	0x0070000002600001	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 12 	, "HDTV 720x480p@60Hz     ",	GS_NONINTERLACED,	GS_MODE_DTV_480P,		GS_FRAME, 	(u64)make_display_magic_number(  479 , 1439 , 0 ,   1 ,		35,	232 ,	0x00C78C0001E00006	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 13 	, "HDTV 1920x1080i@60Hz   ",	GS_INTERLACED,		GS_MODE_DTV_1080I,		GS_FIELD, 	(u64)make_display_magic_number( 1079 , 1919 , 0 ,   0 ,		40,	238 ,	0x0150E00201C00005	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
		{ 14 	, "HDTV 1280x720p@60Hz    ",	GS_NONINTERLACED,	GS_MODE_DTV_720P,		GS_FRAME, 	(u64)make_display_magic_number(  719 , 1279 , 0 ,   0 ,		24,	302 ,	0x00AB400001400005	),	// Taken (and calculated) from PS2 Linux Kit (ps2gs.c) / Neoscientists' blue (ps2videomodes.txt)
//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
		{ 15	, "VGA 640x960i@60Hz      ",	GS_INTERLACED,		GS_MODE_VGA_640_60,		GS_FIELD,	(u64)make_display_magic_number(  959 , 1279 , 1 ,	1 ,		40,	275), 	0x004F80000210000A	},	// doctorxyz's experimentations from original GS_MODE_VGA_640_60 vmode. Values were taken, adopted and recalculated
//---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
		{ 16	, "HDTV576p@50Hz          ",	GS_NONINTERLACED,	GS_MODE_DTV_576P,		GS_FRAME,	(u64)make_display_magic_number(  575 , 1312 , 0 ,	1 ,		64,	320), 	0					},	// From patters98's idea, EEUG's answer and dlanor's experimentations
		{ 17	, "NTSC(PS1 PAL game)     ",	GS_NONINTERLACED,	GS_MODE_DTV_480P,		GS_FRAME,	(u64)make_display_magic_number(  255 , 2559 , 0 ,	1 ,		12,	736), 	0x00C78C0001E00006	},	// From dlanor's experimentations and his discussions with DarkCrono666
		{ 18	, "PAL(PS1 NTSC game)     ",	GS_NONINTERLACED,	GS_MODE_DTV_576P,		GS_FRAME,	(u64)make_display_magic_number(  255 , 2559 , 0 ,	1 ,		23,	756), 	0					}	// From dlanor's experimentations and his discussions with DarkCrono666
//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
		{ 19   	, "VGA 640x480p@72Hz      ",	GS_NONINTERLACED,	GS_MODE_VGA_640_72,		GS_FRAME,	(u64)make_display_magic_number(  479 , 1279 , 0 ,   1 ,		26,	316 ,	0					),	// The Interlace, Mode & Field settings were taken from gsKit, the remaing ones were calculated with rule-of-three process, using the closest values as possible from the PS2 Linux Kit / Neoscientists' blue list
		{ 20   	, "VGA 640x480p@85Hz      ",	GS_NONINTERLACED,	GS_MODE_VGA_640_85,		GS_FRAME,	(u64)make_display_magic_number(  479 , 1279 , 0 ,   1 ,		10,	396 ,	0					),	// The Interlace, Mode & Field settings were taken from gsKit, the remaing ones were calculated with rule-of-three process, using the closest values as possible from the PS2 Linux Kit / Neoscientists' blue list
		{ 21   	, "VGA 800x600p@56Hz      ",	GS_NONINTERLACED,	GS_MODE_VGA_800_56,		GS_FRAME,	(u64)make_display_magic_number(  599 , 1599 , 0 ,   1 ,		29,	372 ,	0					),	// The Interlace, Mode & Field settings were taken from gsKit, the remaing ones were calculated with rule-of-three process, using the closest values as possible from the PS2 Linux Kit / Neoscientists' blue list
		{ 22   	, "VGA 800x600p@72Hz      ",	GS_NONINTERLACED,	GS_MODE_VGA_800_72,		GS_FRAME,	(u64)make_display_magic_number(  599 , 1599 , 0 ,   1 ,		20,	516 ,	0					),	// The Interlace, Mode & Field settings were taken from gsKit, the remaing ones were calculated with rule-of-three process, using the closest values as possible from the PS2 Linux Kit / Neoscientists' blue list
		{ 23 	, "VGA 800x600p@85Hz      ",	GS_NONINTERLACED,	GS_MODE_VGA_800_85,		GS_FRAME,	(u64)make_display_magic_number(  599 , 1599 , 0 ,   1 ,		17,	564 ,	0					),	// The Interlace, Mode & Field settings were taken from gsKit, the remaing ones were calculated with rule-of-three process, using the closest values as possible from the PS2 Linux Kit / Neoscientists' blue list
		{ 24 	, "VGA 1024x768p@70Hz     ",	GS_NONINTERLACED,	GS_MODE_VGA_1024_70,	GS_FRAME,	(u64)make_display_magic_number(  767 , 2047 , 0 ,   1 ,		32,	420 ,	0					),	// The Interlace, Mode & Field settings were taken from gsKit, the remaing ones were calculated with rule-of-three process, using the closest values as possible from the PS2 Linux Kit / Neoscientists' blue list. The guessing work made for DW and MAGH can be wrong.
		{ 25 	, "VGA 1024x768p@85Hz     ",	GS_NONINTERLACED,	GS_MODE_VGA_1024_85,	GS_FRAME,	(u64)make_display_magic_number(  767 , 1023 , 0 ,   0 ,		28,	100 ,	0					),	// The Interlace, Mode & Field settings were taken from gsKit, the remaing ones were calculated with rule-of-three process, using the closest values as possible from the PS2 Linux Kit / Neoscientists' blue list. The guessing work made for DW and MAGH can be wrong.
		{ 26	, "DVD NTSC@60Hz          ",	GS_NONINTERLACED,	GS_MODE_DVD_NTSC,		GS_FRAME,	(u64)make_display_magic_number(  479 , 1439 , 0 ,   1 ,		35,	232 ,	0					),	// The Interlace, Mode & Field settings were taken from gsKit, the remaing ones were copied-and-pasted from the GS_MODE_DTV_480P vmode (except for the syncv value, which was zeroed here - by precaution)
		{ 27	, "DVD PAL@50Hz           ",	GS_NONINTERLACED,	GS_MODE_DVD_PAL,		GS_FRAME,	(u64)make_display_magic_number(  575 , 1312 , 0 ,	1 ,		64,	320), 	0					},	// The Interlace, Mode & Field settings were taken from gsKit, the remaing ones were copied-and-pasted from the GS_MODE_DTV_576P vmode
		{ 28	, "DVD 480p@60Hz          ",	GS_NONINTERLACED,	GS_MODE_DVD_480P,		GS_FRAME,	(u64)make_display_magic_number(  479 , 1439 , 0 ,   1 ,		35,	232 ,	0					),	// The Interlace, Mode & Field settings were taken from gsKit, the remaing ones were copied-and-pasted from the GS_MODE_DTV_480P vmode (except for the syncv value, which was zeroed here - by precaution)
//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
	};

well, i know i am quoting a very old post, but the solution to our problem might be lying here with appropriately changing the magh for progressive modes. Which in our case i think should be "3" for 480p mode (line 12) to solve black border problems for 512 x 448 games (combined with 2559" for "dw"). It might be good for ps2 linux , where i assume mostly the internal resolution will be 640 x 480 but unfortunately this is not the case for most of the ps2 games.

Of course i might be missing something (i probably am)

EDIT: I read the original ps2videomodes.txt and have 2 propositions.

1)Implementing a constant value "3" for magh, "2559" for "dw" for 480p progressive modes (i have to calculate for other modes), we might have to recalculate the dx and dy values.
2)Making magh and magv values editable like the other values in gsm 0.23.

I know the second option takes a lot of coding but it is much more versatile. Even first option would solve most of the blackbar problems in wide screen supporting games.

EDIT 2: I can check values for different circumstances (different modes, different games) if someone leads me to a proper way to compile gsm.elf myself. I have both linux and windows environments, unfortunately you should tell me what i have to do step by step

[doctorxyz]

Hi reprep!

Since I consider you an advanced GSM user, like No.47, SkyNet, and some others, let me give you an idea: Why not pickup loki7777 VM or even install Ubuntu and OPL compile scripts I updated two days ago (http://psx-scene.com/forums/f150/ope...tml#post959818 (Open-ps2-loader compile guide discussions/submissions)) and have a good environment to make yourself some tests specifically with MAGV and DW settings (only this values... Never play with SYNCV)?
Even you not being a developer, I believe that you could do this with some effort.
The latest GSM 0.36 I uploaded an year agot into bitbucket repo (hg clone https://bitbucket.org/doctorxyz/gsm), and I change code - in a proposital way - just it could be compiled the same way OPL is.
The only thing you should do is, make the MAGW and DW changes via gedit (a GUI text editor I use in Ubuntu), save, and then compile GSM ("make rebuild).

Just think about it (there isn't any obligation on doing this okay)!

BR,

PS: Send me PMs if you need some help to have your own environment to compile GSM.

[No.47]

That makes things easier to understand. Is there any chance to manually control MAGH and MAGV values?
I know GSM doesn't let us choose them and calculates them on the fly according to DW and DH. But is there a manual override? I mean is there a physical restriction to not being able to use MAGH 4 (it means 5 in fact) and DH 2559 and 480p progressive mode for DISPLAY1/DISPLAY2 six bitfields for perfect match for 512x448 games?

well, i know i am quoting a very old post, but the solution to our problem might be lying here with appropriately changing the magh for progressive modes. Which in our case i think should be "3" for 480p mode (line 12) to solve black border problems for 512 x 448 games (combined with 2559" for "dw"). It might be good for ps2 linux , where i assume mostly the internal resolution will be 640 x 480 but unfortunately this is not the case for most of the ps2 games.

Of course i might be missing something (i probably am)

EDIT: I read the original ps2videomodes.txt and have 2 propositions.

1)Implementing a constant value "3" for magh, "2559" for "dw" for 480p progressive modes (i have to calculate for other modes), we might have to recalculate the dx and dy values.
2)Making magh and magv values editable like the other values in gsm 0.23.

I know the second option takes a lot of coding but it is much more versatile. Even first option would solve most of the blackbar problems in wide screen supporting games.

EDIT 2: I can check values for different circumstances (different modes, different games) if someone leads me to a proper way to compile gsm.elf myself. I have both linux and windows environments, unfortunately you should tell me what i have to do step by step

Setting the scale factors manually wouldn't be of any benefit, since the automatic calculation always provides the optimum (integer) value. By using GSM 0.23x you can increase the DW value until the next bigger MAGH value is chosen, but the only thing you get is an image cropped to the left and the right (instead of black borders to the left and the right).

AFAIK the DW value of 1280 resp. 1279 VCK units is physically predetermined - or else you could simply change that value for seamless scaling. That's why we would need analog control over the 'width of a VCK unit' (not sure if this illustration is correct... doctorxyz? )

[doctorxyz]

No. 47,
It seems you're correct; good point about remember reprep of using GSM 0.23x instead of GSM 0.36 for these tweaks, since this earlier rev allows more control about GS registers than the latter one.
BTW, Great to know you are still following our thread... You knows a lot of the video mode concepts behind GSM, and your memory is better than mine ;-)

reprep,
So coding isn't needed (at least for this purpose).

[reprep]

well i am trying to set ps2dev environment on puppy linux and failing miserably. I guess i have to use ubuntu.

I plan to use gsm 0.23x too, i hope it compiles well with opl environment setup.

@No. 47, yes it crops the picture if you increase the DW, but if my theory is right, this problem will be solved.

In our current setup for 480p mode dx=308 dy=51 MAGH=1 MAGV=0 DW=1279 DH=479

Let's take the Need for Speed Most Wanted (512 x 444) right now it can be duplicated once, meaning it will reach 1024 which is smaller than 1279. After that duplication, it is divided by MAGH+1 which is 2, and again we get 512 horizantal size (squashed)

If you increase DW over 1536. IT will be duplicated twice, meaning it will reach 1536 which is smaller than the DW value. After that duplication, it is again divided by MAGH+1 which is 2. and we get 738 (cropped)

In my theory if you make the MAGH=3. and DW over 2559. It will be duplicated four times meaning 512 x 5 = 2560. After the duplication, it will be divided by MAGH+1 which is 4 and we get 640. That is what we want to achieve. Vertical lenght will be balanced with overscan so i don't worry much over it. Of course this is just a theory and will remain to be so until i get my ps2dev environment.

I think there isn't any case when a larger MAGH is chosen, it is always the same stated in the table if i am right.

EDIT:Here is more info on the subject why MAGH and MAGV is constant. shoot gsm 0.23x, press o and choose NTSC-I full buffer mode. the values are DX=0700 DY=0046 MAGH=03 MAGV=0 DW=2559 DH=0447. If you shoot a 512 x 448 game like this, you will get your nice full screen because of 512 x 5 = 2560 2560/4=640.

Restart your console and again shoot gsm 0.23x and choose NTSC-I full buffer mode. This time change the DW value to 2023. Decrease the DX about 100 (i didn't test it much, but don't worry this is not essential for now). And restart the game. Do you see something suspicous? Might i say, it is letterboxed just like progressive mode? Yes, definitely. Because this time it is 512 x 4 =2024 and 2024 / 4 = 512 (squashed). So we now know, MAGH and MAGV isn't calculated on the fly. They are taken from the table i posted above.

So now we can letterbox interlaced modes (what a gain), hope we will be able to un-letterbox progressive modes too. Also if what i assume is true, we can get rid of black borders in higher resolutions too.

[doctorxyz]

well i am trying to set ps2dev environment on puppy linux and failing miserably. I guess i have to use ubuntu.

ATM I'm finally running Ubuntu 11.10 i386 with 4 desktops areas opened at the same time, that can be easily switched:
1st PCSX2 0.99 and Mozilla Firefox (to access PSX-Scene site)
- Geany IDE with OPL 553 with GSM mockup (made by izdubar an year ago) opened
- Geany IDE with GSM 0.36 (made one year ago by me) opened
- Geany IDE with OPL 635, where I intend to implement DTV480P and X and Y axis relative fix as a option from OPL Display Menu (@all: Please don't push me on this. Let me try this first step, if it succeds we can think about more)

I plan to use gsm 0.23x too, i hope it compiles well with opl environment setup.

Only GSM 0.36 will compile well with OPL environment setup. But for both GSM 0.36 and GSM 0.23x you have the executable (ELF) on the first post of this thread. ;-)

[SkyNet]

Guys I have a question:

We have some games which support Progressive Scan mode whether through the entry in Menu -like Tomb Raider or through pressing of Triangle and Cross at gamescreen sturt up--like PacMan World Rally.

The question is:
If once to turn on Progressive Scan through the menu entry in Tomb Raider, and second time turn on Progressive Scan only through GSM----qualitywise will we see any difference between both ?

Also we have games which natively support Progressive Scan but do not have menu entry for it, in other words it is possible to turn it on only through Triangle and Cross, sometimes triangle and circle at game startup-----http://en.wikipedia.org/wiki/List_of_PlayStation_2_games_with_HD_support

So question is:

Can OPL, GSM, PS2ESDL remember this list of games with Progressive Scan (List of PlayStation 2 games with HD support - Wikipedia, the free encyclopedia) and Press Triangle and Cross by itself, because I do not remember the list of games and can forget to hold Trinagle and Cross at startup?
It just when game from list starts-----PS2ESDL sends signal like it was pressed on gamepad Triangle and Cross and each time game will show dialog menu to turn on Progressive Scan...

Also I think that new version of PS2ESDL with support for 480p in games must have ability to turn on Progressive Scan for each individual game.....

Is it possible to bring the list of Progressive Scan games in GSM, OPL, PS2ESDL?
What do you think about it?

[doctorxyz]

If once to turn on Progressive Scan through the menu entry in Tomb Raider, and second time turn on Progressive Scan only through GSM----qualitywise will we see any difference between both ?

If some game has ingame Progressive Scan built-in feature depending on it renders their even/odd fields at interlaced vmode, when enforcing it to progressive we can achieve better, same, or worst results (this latters implies on half of its vertical resolution - well, at least until some coder skilled in both MIPS assembler and IDA Pro helps me to discover how Xploder HDTV Player works, in order to solve this issue together).

[No.47]

No. 47,
It seems you're correct; good point about remember reprep of using GSM 0.23x instead of GSM 0.36 for these tweaks, since this earlier rev allows more control about GS registers than the latter one.
BTW, Great to know you are still following our thread... You knows a lot of the video mode concepts behind GSM, and your memory is better than mine ;-)

I wish that would be the case, but thanks anyway
BTW, this thread contains so much information by now, if only it wasn't that lengthy to read through!

Let's take the Need for Speed Most Wanted (512 x 444) right now it can be duplicated once, meaning it will reach 1024 which is smaller than 1279. After that duplication, it is divided by MAGH+1 which is 2, and again we get 512 horizantal size (squashed)

If you increase DW over 1536. IT will be duplicated twice, meaning it will reach 1536 which is smaller than the DW value. After that duplication, it is again divided by MAGH+1 which is 2. and we get 738 (cropped)

Maybe I don't understand you correctly, but why are you dividing the DW value in the end of your calculations?
I mean, in the first case it's 512*2=1024 so you theoretically get (1280-1024)/1280=20% black borders. When increasing DW over 1536 VCK units it's 512*3=1536 and theoretically (1536-1280)/1536=16,6% of the image are cut off.

EDIT:Here is more info on the subject why MAGH and MAGV is constant. shoot gsm 0.23x, press o and choose NTSC-I full buffer mode. the values are DX=0700 DY=0046 MAGH=03 MAGV=0 DW=2559 DH=0447. If you shoot a 512 x 448 game like this, you will get your nice full screen because of 512 x 5 = 2560 2560/4=640.

As above, I don't not understand the last step in your calculation. You get a nice full screen because the DW value for NTSC is a perfect multiple of the frame buffer size (512*5=2560).

ATM I'm finally running Ubuntu 11.10 i386 with 4 desktops areas opened at the same time, that can be easily switched:
1st PCSX2 0.99 and Mozilla Firefox (to access PSX-Scene site)
- Geany IDE with OPL 553 with GSM mockup (made by izdubar an year ago) opened
- Geany IDE with GSM 0.36 (made one year ago by me) opened
- Geany IDE with OPL 635, where I intend to implement DTV480P and X and Y axis relative fix as a option from OPL Display Menu (@all: Please don't push me on this. Let me try this first step, if it succeds we can think about more)

Great to hear you're still working on this. If this will happen sometime I'm sure both OPL and GSM will benefit!
But as always: Take your time

If once to turn on Progressive Scan through the menu entry in Tomb Raider, and second time turn on Progressive Scan only through GSM----qualitywise will we see any difference between both ?

Technically, both ways should look the same qualitiy-wise. BUT the thing is, in some cases the built-in 480p option offered by some games doesn't simply switch the vmode, but also seems to change the frame buffer size to maintain the fullscreen image (whereas GSM's 480p mode leaves you with black borders to the left and the right). IIRC TR Legend / TR Anniversary are two of these cases, but with unusual frame buffer sizes for its 480p mode.
Actually, that's something I already had in mind to write about more detailed in the next days

Best regards,
No. 47