Page 1 of 1
HDTV mode RGB or YCbCR
Posted: Tue Jun 07, 2005 9:47 am
by Steve F
I ran into a little problem running in HDTV mode. The colors were all screwed up. Same problem running a commercial game in HD mode. I found a setting in the PS2 console browser setup to switch component video between RGB and YCbCr. My HD monitor requires YCbCr and I had it set to RGB. Once I switched it over it looked great. The problem I'm having is finding a PCRTC reg setting to control the color mode of HDTV output. If it's not described in ps2linux or ps2dev docs, what is a method of finding out a peice of information like this? (google search returned nothing.)
Posted: Tue Jun 07, 2005 10:09 am
by ooPo
I'd like to know, too...
Typically that kind of setting is handled by the SetGsCrt() syscall for you. The secret to where and how could probably be found by disassembling that code.
There's a few registers on the GS that are undocumented. You can find some info on them in the ps2gs.c file, in the ps2linux kernel source. Here's the one that seems most likely to me:
SMODE1 *(volatile u64 *)0x12000010
Its arguments are listed as:
VHP, VCKSEL, SLCK2, NVCK, CLKSEL, PEVS, PEHS, PVS, PHS, GCONT , SPML, PCK2, XPCK, SINT, PRST, EX, CMOD, SLCK, T1248, LC, RC
I'd guess that CMOD may mean colour mode.
I could be entirely wrong, though. I haven't had much luck in trying different settings.
Posted: Thu Jun 09, 2005 10:48 pm
by Steve F
Nailed it!
I found the solution in ps2gs.c .
Code: Select all
#define GS_REG_SMODE1 *(volatile u64 *)0x12000010 // VHP,VCKSEL,SLCK2,NVCK,CLKSEL,PEVS,PEHS,PVS,PHS,GCONT,SPML,PCK2,XPCK,SINT,PRST,EX,CMOD,SLCK,T1248,LC,RC
#define GS_SET_SMODE1(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U) \
(u64)((A) & 0x00000007) << 0 | (u64)((B) & 0x0000007F) << 3 | \
(u64)((C) & 0x00000003) << 10 | (u64)((D) & 0x00000001) << 12 | \
(u64)((E) & 0x00000003) << 13 | (u64)((F) & 0x00000001) << 15 | \
(u64)((G) & 0x00000001) << 16 | (u64)((H) & 0x00000001) << 17 | \
(u64)((I) & 0x00000001) << 18 | (u64)((J) & 0x00000003) << 19 | \
(u64)((K) & 0x0000000F) << 21 | (u64)((L) & 0x00000001) << 25 | \
(u64)((M) & 0x00000001) << 26 | (u64)((N) & 0x00000001) << 27 | \
(u64)((O) & 0x00000001) << 28 | (u64)((P) & 0x00000001) << 29 | \
(u64)((Q) & 0x00000003) << 30 | (u64)((R) & 0x00000001) << 32 | \
(u64)((S) & 0x00000001) << 33 | (u64)((T) & 0x00000003) << 34 | \
(u64)((U) & 0x00000001) << 36
Argument A is RC, B is LC, ..., U is VHP, in the same form as other ps2sdk register macros. GCONT is the field that controls component color mode RGB/YCbCR. A value of 0 sets RGB and 1 sets YCbCr. It is argument L in the macro.
I put the following code after the GS is setup and initilized:
Code: Select all
// L
smode1 = GS_SET_SMODE1(4,32,1, 0,0,0,1,1,0,0,2,1,0,0, 0,0, 1,1,1,1, 1);
GS_REG_SMODE1 = smode1 & ~((u64)1 << 16) & ~((u64)1 << 17);
The arguments in GS_SET_SMODE1 are for mode 480P. I have the full list but I'm not sure if I should publicly post it here. I agree with the other posts regarding SMODE1; messing around with it might fry a monitor. At this point I'll leave it as, 'If you can figure out ps2gs.c, you can get the other settings and probably know enough not to blow things up. Otherwise, leave it alone.
A critical part of getting this to work is bits 16 and 17. These are PRST and SINT. Every time I wrote to SMODE1 register without resetting these fields I caused EE to stop processing. A hard reset was required at that point. I have GS rev.21 which responds to the above code. An older GS rev. seems to require setting bit 16 and then reseting bit 16 and then waiting for 2.5ms. Bit 17 was not referenced.
Posted: Fri Jun 10, 2005 12:24 am
by ooPo
Hey, great work. :)
So the first argument, 'A', is VHP. I know this is backward from ps2sdk macro argument ordering but it matches up to the register illustration and is easier to 'visualize'. It's a shame all the macros in graph_registers.h are lsb to msb. I think it's too late to change the SDK because existing programs are highly dependent on the field order.
This was done to make it easier to visualize if you were looking at the gsuser guide and reading the arguments from the top down, like a list.
Anyway, I'd like to see the rest, if you can post (or send) it to me.
Posted: Fri Jun 10, 2005 12:45 am
by Steve F
You know, now that you mention it, I found the other GS register macros easy to use. I see the horizontal bit map but when it comes to using the information, it was always the vertical list of fields that was most useful. I guess I overlooked that because SMODE1 isn't listed in the GS user guide. I have edited my previous post to reference the arguments in the same order as other register macros.
Posted: Tue Jun 14, 2005 2:56 pm
by Steve F
I looked at the console settings code for insight into how 4:3, Full, and 16:9 screen modes are implemented. It looks like when the user sets their screen mode of choice in the console browser setup screen it is for advisory only. At game init you can read the users setting and manually alter the display settings to what the user has set in the console. I don't know yet how to alter the PCRT settings to get 16:9. I checked a couple commercial games on 16:9 setting but actually, I think they have their code set up wrong. I don't get a 'letter box' formated screen on a regular monitor. On my HDTV widescreen I don't actually get more screen area on the left and right sides like with 16:9 movies. It seems like the only thing that changes is the perspective calculations and a bit of a zoom in effect (both commercial games use the same game engine). I'll experiment with some other games and also check in the SMS thread. I read somebody tested with a video clip and described blue bars at top and bottom during playback. That sounds like just the thing for 16:9.
Posted: Tue Jun 14, 2005 4:02 pm
by wulf
just out of curiosity, are one of the games you checked Timesplitters (1,2 or 3)?
again, just curious..
Posted: Tue Jun 14, 2005 10:34 pm
by Steve F
No, I checked with Naughty Dog engine on Ratchet & Clank UYA and Jak3. This morning I checked with Echo Night Beyond. It has 4:3, 16:9 and 16:9LB. In each setting the amount of scene visable left to right is the same. The only thing that changes is the vertical size. In 4:3 the door is square and looks normal. In 16:9 the vertical is stretched and the top and bottom of the scene are gone. In 16:9LB the vertical top and bottom are clipped and the aspect is correct.
My expectation is that 4:3 is as a non-widescreen TV or monitor. 16:9 should have the same amount of vertical scene and add a few degrees of scene on each side in the same way a widescreen movie is filmed.
Posted: Tue Jun 14, 2005 10:40 pm
by wulf
I see.
Posted: Wed Jun 15, 2005 1:18 am
by ooPo
Screen resolution and aspect ratio are usually independant of each other. Its up to the program itself to squeeze or squish the onscreen graphics to look right, as well as adding black bars to letterbox it on 4:3 screens.
What would be nice, and what it seems you're looking for, is enough information about these GS registers to set a mode with a pixel resolution closer to 16:9 so less/no squishing would is required. You're probably not going to find this information in a commercial game as that would break the TRC long before it hits the store shelves.
Careful trial-and-error may get it for you, though... although it hasn't turned up much for me yet.