GS Mode Selector: Development & Feedback

Quote:

Originally Posted by SP193

This is what I've found out so far:

Code:

Definitions: SYNCH1: HS - Horizontal Synchronization pulse interval (?) HSVS - Horizontal/Vertical Sync (Period of VS) HSEQ - (Period of VFPE) HBP - Horizontal Back Porch (lines) HFP - Horizontal Front Porch (lines) SYNCH2: HB - ? HF - ? (These two values belong to "HalfH", whatever that is...) SYNCHV: VS - Vertical Synchronization pulse interval VDP - Vertical Display Pixels (Lines) VBPE - ? (Comes before VBP) VBP - Vertical Back Porch (lines) VFPE - ? (Comes after VFB) VFP - Vertical Front Porch (lines) NTSC 525 lines (480 visible): | VFP | VFPE | VBP | VBPE | VDP | VS | ------------------------------------------------- | 1 | 6 | 26 | 6 | 480 | 6 | Vertical lines=1+6+26+6+480+6=525 | HFP | HBP | HS | ------------------------- | 64 | 222 | 254 | Horizontal lines=64+222+254=540 Horizontal frequency: (pixel frequency) / (Total number of horizontal lines) Vertical frequency: (horizontal frequency) / (Total number of vertical lines) References: http://infocenter.arm.com/help/topic...1d/DDI0121.pdf http://datasheets.maxim-ic.com/en/ds/MAX7456.pdf ãƒ”ã‚¯ã‚»ãƒ«ã‚¯ãƒ*ãƒƒã‚¯ä¿¡å·ç”Ÿæˆè£…ç½®ãŠã‚ˆã³åŒæœŸä¿¡å·ç”Ÿæˆè£…ç½®ï½œè©³ç´° - astamuse(ã‚¢ã‚¹ã‚¿ãƒŸãƒ¥ãƒ¼ã‚¼) (Look at diagrams 6 and 7 about HBLANK, VBLANK and CSYNC) http://web.mit.edu/6.111/www/f2008/handouts/L12.pdf DisplayConfigX

By altering some of these values, the Horizontal and Vertical refresh rates might get changed (Hence explaining why there is no change in the RC and LC values between the VESA 0x1B and 0x1C modes).

The change won't be by a lot though. (It makes sense here, since the gap between the 72Hz and 75Hz VESA modes is not great )

Now we need someone to explain how to encode the RC and LC values, and how they affect the pixel clock....

I am searching for the codes of LC and RC for a long time, but i couldn't succeed to find a logical calculation. HDMI specification EDID Detailed Timing Descriptor has this pixel clock value as 2 byte (16 bit) from 0.01 to 655.35 MhZ. Of course this doesn't help us.

Unfortunately i couldn't confirm HSEQ and HSVS. We have to confirm first to be sure. That confirmation has been done for HS HFP HBP VFP VBP VS and most probably VDP.

Ragnarok2040 thinks RC and LC refer to low-pass filter and ripple filter. I don't know why he thinks so.

I gave up on RC and LC because

1) HF + HB gives us active horizontal lines in VCK units (If you use the values in paranthesis in ps2videomodes.txt)
2) By help of active horizontal pixels we can calculate total horizontal lines (HF+HB+HS+HBP+HFP)

Horizontal frequency: (pixel frequency) / (Total number of horizontal lines)

from that equation we need to know either pixel frequency (or pixel-clock rate) or Horizontal frequency as we already know the total number of horizontal lines.

But if we assume RC, LC defines clock rate, HF + HB give us active horizontal lines and HSVS gives us horizontal frequency our logic is flawed. Because we have to define 2 of these variables and the 3rd should be calculated.

Also the first thing came to my mind for HSVS was of course Horizontal Frequency / Vertical Frequency but from this formula: Vertical frequency: (horizontal frequency) / (Total number of vertical lines) it should be equal to total number of vertical lines which isn't.

I did a few calculations for VESA-2b and other modes and confirmed HS HFP HBP VFP VBP VS and most probably VDP unfortunately i still lack the needed calculations for HSEQ and HSVS

also you can't just add HFP + HBP + HS. You have horizontal sync, horizontal front porch and horizontal back porch but you are missing the active pixels which i think equals to HF + HB, also all horizontal resolutions are in VCK units not pixels. If you look at other tables for these resolutions you will see that HFP HBP and HS values are too big to fit on a normal screen if they were in pixels. We would just lose 540 pixels (these are not viewable)

Here is my post which i am referring to:
http://psx-scene.com/forums/f19/gs-m...tml#post963539

of course i can be corrected.

Also i agree that small vertical frequency changes can be done without changing pixel clock, just by changing front and back porchs so my logic was flawed to totally abandon RC and LC just for this.

But again the problem i described above persists. We have to declare only 2 of this 3 in registers.

a)Pixel clock rate
b)Total number of horizontal lines
c)Horizontal frequency

so to get 1080p @ 60 hz * or another totally new VGA mode which will let us define custom resolutions and bury the black-border problems, we have to have control over horizontal/vertical frequency or pixel clock rate.

*i doubt if this is achievable because we don't know for sure if PS2 is able to go at such high pixel-clock rates, it requires 148.5 mhz and the max ps2 uses in a video mode is 135 mhz for 1280 x 1024 75 mhz vertical frequency mode. But the good news is ps2 can support 1080p @ 50 hz since its pixel clock rate is 123.75 which is below 135 mhz.

EDIT:I wrote 130 instead of 135.

Quote:

Originally Posted by SP193

@No.47: The weird resolution you noticed for the 576P mode might be an error at my end. I wasn't sure of the resolution for 576P mode, so I entered 1440x576 (It's 1280x576, isn't it?).

The 576p mode itself seems to be fine, it's only when I switch directly from 720p or 1080i or 720p to 576p that this strange error occurs every single time. Switching from NTSC, PAL, 480p or even 1080p to 576p works fine, at least most of the time (sometimes these 'random freezes' occur, but they seem to be kind of unpredictable).

I guess that it's 1280x576 or effectively even less, but that's hardly the reason. AFAIK changing the DW and DH values only changes the screen position (if not corrected by changing the DX and DY accordingly).

Quote:

Originally Posted by SP193

Or it could be because of some other registers set by the other progressive-scanning modes that I didn't reset.

That's probably the case. And maybe also the reason for the 'random freezes' when switching between vmodes multiple times.

Quote:

Originally Posted by SP193

@All who never got the 1080P mode working: Do your TVs support 1080P @ 30Hz? The problem here is that this 1080P mode isn't running at 60Hz.... so the only thing left is to attempt to double the vertical frequency.

Since the 1080p mode works for you and E_P (whose V4 PS2 is even older than mine) I suppose my TV set simply doesn't support 1080p at 30Hz but only at refresh rates like 60Hz, 50Hz, 25Hz, 24Hz. I mean, your program doesn't freeze as I can switch back to other vmodes, it simply doesn't show any signal.

----------------.-------.-------.-------.-------.-------.-------.-------.-------.
Mode | RC | LC | T1248 | SLCK | CMOD | EX | PRST | SINT |
----------------+-------+-------+-------+-------+-------+-------+-------+-------|
0: NTSC-NI | 4 | 32 | 1 | 0 | 2 | 0 | 1 | 1 |
1: NTSC-I | 4 | 32 | 1 | 0 | 2 | 0 | 1 | 1 |
2: PAL-NI | 4 | 32 | 1 | 0 | 3 | 0 | 1 | 1 |
3: PAL-I | 4 | 32 | 1 | 0 | 3 | 0 | 1 | 1 |
4: VESA-1A | 2 | 15 | 1 | 0 | 0 | 0 | 0 | 1 |
5: VESA-1C | 3 | 28 | 1 | 0 | 0 | 0 | 0 | 1 |
6: VESA-2B | 6 | 71 | 1 | 0 | 0 | 0 | 0 | 1 |
7: VESA-2D | 3 | 44 | 1 | 0 | 0 | 0 | 0 | 1 |
8: VESA-3B | 6 | 58 | 0 | 0 | 0 | 0 | 0 | 1 |
9: VESA-3D | 3 | 35 | 1 | 0 | 0 | 0 | 0 | 1 |
10: VESA-4A | 1 | 8 | 0 | 0 | 0 | 0 | 0 | 1 |
11: VESA-4B | 1 | 10 | 0 | 0 | 0 | 0 | 0 | 1 |
12: DTV-480P | 4 | 32 | 1 | 0 | 0 | 0 | 1 | 1 |
13: DTV-1080I | 2 | 22 | 1 | 0 | 0 | 0 | 0 | 1 |
14: DTV-720P | 2 | 22 | 1 | 0 | 0 | 0 | 0 | 1 |
----------------^-------^-------^-------^-------^-------^-------^-------^-------'

Pixel clock rate of modes: (found by me from various sources on internet)
0 27 Mhz
1 27 Mhz
2 27 Mhz
3 27 Mhz
4 25,175 Mhz
5 31,5 Mhz
6 40 Mhz
7 49,5 Mhz
8 65 Mhz
9 78,8 Mhz
10 108 Mhz
11 135 Mhz
12 27 Mhz
13 74,250 Mhz
14 74,250 Mhz

These pixel clock rate numbers might have an association with RC and LC bit values of SMODE1 register. RC is 3 bit and LC is 7 bit.

Hope anyone helps us.

We have to be able to code 148.50 Mhz for pixel clock rate for 1080p @ 60 hz

Quote:

Originally Posted by reprep

I am searching for the codes of LC and RC for a long time, but i couldn't succeed to find a logical calculation. HDMI specification EDID Detailed Timing Descriptor has this pixel clock value as 2 byte (16 bit) from 0.01 to 655.35 MhZ. Of course this doesn't help us.

It's probably because the GS is a Sony Proprietary chip. :X

Quote:

Originally Posted by reprep

Unfortunately i couldn't confirm HSEQ and HSVS. We have to confirm first to be sure. That confirmation has been done for HS HFP HBP VFP VBP VS and most probably VDP.

If you looked at the diagrams I looked at (Under the references I mentioned), you'll realize that they are the periods of various parts of the CSYNC signal. I believe that they are used in the different phases of the HBLANK...

These are the diagrams that I took an interest in:
http://image.astamuse.com/image/JP/0.../B2/000006.png
http://image.astamuse.com/image/JP/0.../B2/000007.png

I think that HSEQ is the period of one HSYNC interval during the front/back porch phases. HSVS seems to be the period of one HSYNC interval during the drawing of the visible pixels.

Quote:

Originally Posted by reprep

also you can't just add HFP + HBP + HS. You have horizontal sync, horizontal front porch and horizontal back porch but you are missing the active pixels which i think equals to HF + HB, also all horizontal resolutions are in VCK units not pixels. If you look at other tables for these resolutions you will see that HFP HBP and HS values are too big to fit on a normal screen if they were in pixels. We would just lose 540 pixels (these are not viewable)

All right. You've spotted a weakness in my research.

HS is not the horizontal sync frequency. It seems to be the region of visible display units within each line.

If you look at diagram 7 (The lower link), you'll notice that within a VBLANK interval, the lines under the VFP, VFPE, VS, VBFE and VBFE and VBP regions will be drawn.

In diagram 6 (The upper link), you'll notice that within a HBLANK interval, the HFP, HS and HBP pixels get drawn. Since HFP, HS and HBP are along the same graph, they are measured in the same unit (Visible horizontal units).

HFP and HBP are pixels that are not visible on-screen, and they surround a region of visible pixels. Since HS is in-between HFP and HBP, it's likely the visible region. Don't you think so too?

HF and HB are shown as well, but you can see that they don't get run for as long as the HBLANK... so they cannot make up one full length on the screen.

VS and HS seem to refer to similar regions, but one horizontally and vertically.

So yea, the formulas I mentioned are correct - you are expected to add the values together.... but not to find the actual resolution!

In summary:

Dots drawn within one HBLANK = HFP + HS + HBP
Lines drawn within one VBLANK = VFP + VFPE + VS + HBFE + VBP

If you added HFP + HS + HBP together, it adds up for the NTSC and PAL video modes. However, adding HFP + HS + HBP together for most of the other non-TV modes doesn't add up.... so maybe they are dots in non-pixel units (VCKs?).

I believe that HFP + HS + HBP isn't used to define the actual resolution - I think that it might be a reference for the CRT contoller to know how to draw things.

Since you mentioned that the HB and HF values are the number of visible horizontal units.... we should try to find out what HB and HF stands for. That will at least make it clearer what the purposes of HB and HF are.

Quote:

Originally Posted by reprep

Ragnarok2040 thinks RC and LC refer to low-pass filter and ripple filter. I don't know why he thinks so.

Probably because there isn't really anything else that I can think of that RC and LC could stand for either. :/

They seem to be the only values that can affect the pixel clock, but what could they possibly stand for? It cannot stand for "high clock" and "low clock" bits.

Quote:

Originally Posted by reprep

I gave up on RC and LC because

1) HF + HB gives us active horizontal lines in VCK units (If you use the values in paranthesis in ps2videomodes.txt)
2) By help of active horizontal pixels we can calculate total horizontal lines (HF+HB+HS+HBP+HFP)

Horizontal frequency: (pixel frequency) / (Total number of horizontal lines)

from that equation we need to know either pixel frequency (or pixel-clock rate) or Horizontal frequency as we already know the total number of horizontal lines.

But if we assume RC, LC defines clock rate, HF + HB give us active horizontal lines and HSVS gives us horizontal frequency our logic is flawed. Because we have to define 2 of these variables and the 3rd should be calculated.

That is true. But to get the horizontal frequency, we need to know the pixel clock rate before we can divide it by the number of horizontal pixels.

Quote:

Originally Posted by reprep

Also the first thing came to my mind for HSVS was of course Horizontal Frequency / Vertical Frequency but from this formula: Vertical frequency: (horizontal frequency) / (Total number of vertical lines) it should be equal to total number of vertical lines which isn't.

It's because HSVS doesn't seem to be frequency - but appears to be a period (Or maybe, it's the number of Horizontal syncs interval per vertical syncs :lol:).
(I don't know what HSVS is for sure, but I know that it's got something to do with the relationship between one VBLANK and the HSYNCs that occur within it)

What will you derive by dividing the horizontal frequency by the vertical frequency? When you divide values by another value, it must make sense too. :X
(Which means that there is no point in randomly dividing values by other values - it's probably better for everyone if we found out for sure what HSVS is first)

In fact, it seems like the SYNCH and SYNCV registers are used to control the periods of the differrent drawing regions on an analog TV screen (E.g. Horizontal and vertical front porch, horizontal and vertical back porch and the number of active pixels horizontally and vertically).

True tunning of the refresh rate probably involves tweaking the pixel clock. :(

Quote:

Originally Posted by reprep

I did a few calculations for VESA-2b and other modes and confirmed HS HFP HBP VFP VBP VS and most probably VDP unfortunately i still lack the needed calculations for HSEQ and HSVS

We need to do more reseach. When we understand HSEQ and HSVS properly, we should draw a proper graph to show the relationships between all these signal phases.

Quote:

Originally Posted by reprep

Also i agree that small vertical frequency changes can be done without changing pixel clock, just by changing front and back porchs so my logic was flawed to totally abandon RC and LC just for this.

But again the problem i described above persists. We have to declare only 2 of this 3 in registers.

a)Pixel clock rate
b)Total number of horizontal lines
c)Horizontal frequency

I think that the PS2 requires us to define the clock rate and number of horizontal pixels... since it makes more sense that way (You have to define the pixel clock frequency and the number of horizontal pixels, so the horizontal sync frequency is likely to be derived).

Quote:

Originally Posted by reprep

so to get 1080p @ 60 hz * or another totally new VGA mode which will let us define custom resolutions and bury the black-border problems, we have to have control over horizontal/vertical frequency or pixel clock rate.

Let's face this: To get full control of the GS, we need to more or less understand most of the bit definitions for SMODE1 and the HSYNCH + VSYNCH registers.

Quote:

Originally Posted by reprep

*i doubt if this is achievable because we don't know for sure if PS2 is able to go at such high pixel-clock rates, it requires 148.5 mhz and the max ps2 uses in a video mode is 130 mhz for 1280 x 1024 75 mhz vertical frequency mode. But the good news is ps2 can support 1080p @ 50 hz since its pixel clock rate is 123.75 which is below 130 mhz.

The PS2 was designed to be highly reprogrammable and scalable. I doubt that the maximum rate is only 130MHz.... although it will truly suck if the limit is really 130MHz.

Great work by the way! :)

EDIT:

Just an idea:

What if RC is a clock selector? It could stand for "Reference Clock" then.
Look here for an example: http://www.onsemi.com/pub_link/Colla...CS1P2192-D.PDF

It makes more that sense that way...

New VModeTest program (Build 120412)!

The 1080P mode has been upgraded to 1080P @60Hz mode. :)

Yea, I noticed how the RC value of SMODE1 seemed like a clock selector - and LC went up from 8 to 10 from the VESA 0x4A to 0x4B modes.

So I derived that pixel clock 1 is a 13.5Hz clock. I set the clock multiplier to 11 at first, but that strangely gave me 1080P at 30Hz. So I simply doubled the value from 11 to 22 to get 60Hz. :)

Although, it will be nice if someone could explain in detail why a multiplier of 11 doesn't give 60Hz. Maybe it's because of the other values set (E.g. VFP, VBP, HFP, HBP, HS and VS).

EDIT: I just noticed that the clock rates actually seem to decrease by about 50% as the multiplier increases - which maybe then explains why I needed to double the multiplier (So it's probably now exactly 1080P at 60Hz).

Known bugs/issues:

I heard that the program crashes with a black image and the pink GS background showing.
I think that it happens if you switch between video modes too quickly, so give the PS2 about 5 seconds before switching to another video mode.

Please test and give feedback.

Downloads/Links
VModeTest (Test build 120412): [120412]VModeTest_bin.7z
VModeTest source code + SetGsCrt Pseudo code: [120412]VModeTest.7z

Here is a few more info about RC and LC, there is a little bit more left. The multiplier in the following calculations is always LC. RC is the divisor but sometimes it divides 4 times more than it has to divide. Possibly T1248 and another bitfield is playing a role too. Also you will see there are a few mistakes in the modes i put asterix. Don't forget i took these mhz values from net, and PS2 has its own standards. Sometimes they are a bit different, but the difference is minimum, you will see if you calculate.

Well i found the culprit. It is srfsh. If you put T1248 and srfrsh into calculations, you will see why RC divides sometimes up to 4 times more. So the needed registers for controlling pixel clock rate are: RC,LC, srfrsh, T1248. I will post the formula when i get home.

0 13.5 Mhz 13,5 : 32 x 32
1 13.5 Mhz 13,5 : 32 x 32
2 13.5 Mhz 13,5 : 32 x 32
3 13.5 Mhz 13,5 : 32 x 32
4 25,175 Mhz 13,5 : 8 x 15 *
5 31,5 Mhz 13,5 :12 x 28
6 40 Mhz 13,5 : 24 x 71*
7 49,5 Mhz 13,5 : 12 x 44
8 65 Mhz 13,5 : 12 x 58*
9 78,8 Mhz 13,5 : 6 x 35
10 108 Mhz 13,5 : 1 x 8
11 135 Mhz 13,5 :1 x 10
12 27 Mhz 13,5 : 16 x 32
13 74,250 Mhz 13,5 : 4 x 22
14 74,250 Mhz 13,5 : 4 x 22

Quote:

Originally Posted by SP193

What will you derive by dividing the horizontal frequency by the vertical frequency? When you divide values by another value, it must make sense too. :X
(Which means that there is no point in randomly dividing values by other values - it's probably better for everyone if we found out for sure what HSVS is first)

if you divide horizontal frequency by vertical frequency, you will get total vertical lines, as all horizontal lines should be displayed before a vertical refresh. That was the reason i divided these values. (though it failed) I got number of total vertical lines this way in my previous calculations i quoted.

EDIT: on my V9 all resolutions work fine including 1080p @ 60 hz. I tried RC=3 and LC=55 and succeeded in 1080p @ 50 hz too, though the colors were wrong, i don't know why. I will do some more experiments.

Formula for calculating pixel clock rate= (LC * 13,5*a) / (b *RC)

b=srfsh (you can find this value for everymode in my ps2videomodeslog2.50.txt i posted before

a=1 if T1248 is set and a=2 if T1248 is cleared.

I might be wrong but this formula worked for everything i calculated.

EDIT2: First 4 modes have pixel clock rate 13,5 if you apply the formula and this formula is most probably true. I wasn't sure if it was 13,5 or 27 at first then i did more research on net and convinced it was 27 mhz, it looks i was wrong. At least i could get 1080p @ 50 Hz using above formula even though the colors were wrong.

EDIT3: So we can totally control refresh rate now. 1080p @ 25 hz, 480p @ 50 hz, any kind of refresh rate with an already available resolution is possible now. After all values of HSYNC1 and HSYNC2 have been understood, any kind of resolutions and any kind of vertical refresh rates will be possible, only your TV/monitor will be your limit. Well we can make a monitor/tv resolution test program too.

EDIT4: New formula with the help of SP193:

pixel clock rate= (LC*13,5) / (a*b*RC)

b=SPML

a=1 if T1248 is 0 and a=2 if T1248 is 1.

First up, congratulations! :D

You are probably quite close to the solution, if you are not already there.

Quote:

Originally Posted by reprep

EDIT3: So we can totally control refresh rate now. 1080p @ 25 hz, 480p @ 50 hz, any kind of refresh rate with an already available resolution is possible now. After all values of HSYNC1 and HSYNC2 have been understood, any kind of resolutions and any kind of vertical refresh rates will be possible, only your TV/monitor will be your limit. Well we can make a monitor/tv resolution test program too.

But earlier on, I got 1080P @60Hz with using RC = 1 and LC =22, with T1248 =1 and SRFRSH=4 (Basically, it's the 1080I mode settings but with 60Hz, non-interlaced).

So if I used your formula, the rate should be: (22*13.5*1) / (4 *1) =293Hz.
(That doesn't quite explain why it cannot be 148.5Hz)

One way to find out whether the T1248 field really affects the pixel clock would be to toggle those values on and off... but I cannot do that tonight.

From your formula, it seems like T1248 can double the pixel clock rate, doesn't it? Then it should cause 1080P @30Hz to become 1080P @ 60Hz once it's cleared.

The SRFSH register is labeled in "gs_privileged.h" as the "DRAM Refresh Settings". Somehow, it sounds unlikely to be connected to the pixel clock... although yes, in the Intel PC architecture, the RAM speed affects the system bus. So it really depends on how Sony designed the GS.....

(The problem with toying with that register is that if it really affects DRAM timmings, it might screw up the display if set incorrectly :()

pixel clock rate= (LC*13,5) / [(T1248+1)*SPML*RC] "By the help of SP193 for recommending me to use SPML"

I guess that works fine for all situations.

EDIT: Simplified formula

Test result for VModeTest v1.01 (test build 120412)
(hardware: PAL V7, launch method: uLaunchELF v4.42a)

the updated 1080p mode (now at 60Hz) does work flawlessly on my TV set!

A PS2 outputting 1080p60, this is just incredible.
reprep & SP193, it's amazing how far you two have come within this relatively short time. I take my hat off to you! :)

That's pretty impressive, indeed. I thought 1080i was the limit for PS2...

To reprep:
There was a version of the Xploder HDTV Player that came with a VGA connector. I think this one was compatible with all monitors because it did convert the SOG signal into a standard VGA one. That may be hard to get though nowadays.
If there is any VGA testing I can perform (since my monitor supports SOG) I'd gladly help. Unless there's a significant risk of blowing it up, that is... ;)

Regards!