Feature request for ps2link protocol

[Steve F]

I would like to request a command to change the video mode that ps2link is using to display its output. The command will take as its argument the requested video mode number or symbolic name as used in SetGSCrt.

ps2link uses debug/init_scr and currently auto configures to NTSC or PAL depending on the console. I will soon submit for consideration the changes to debug allowing init_scr to accept a mode argument and set up the GS and PCRT for PAL, NTSC, VESA, and HDTV modes.

Then, ps2client and XLink can have a command/option list which will allow remote selection of video mode. As an enhancement I think it would be good to have an option in IPCONFIG.DAT for initial video mode. If ps2link is able to write the IPCONFIG.DAT file, it would be handy if it updated the latest video mode selection stored in IPCONFIG.DAT.

[ooPo]

I like the idea. Just a simple 'setmode <mode>' whould suffice?

Writing the config file may be tricky... sometimes you're running ps2link from a read-only device. Still, a 'saveconfig' command could be useful. Putting it in extra.cnf may be a better place, though.

[Steve F]

Yep. Maybe setvmode in case there is another 'mode' not video that is better represented by setmode. Or how about 'gsmode <mode>'? That actually seems to fit the 'theme' of the other commands.

Saveconfig would be better I think than having the video mode change logic also save its latest state each time it is changed.

[Guest]

Yeah may as well shuffle this one offf too...

[ooPo]

Steve F:

If you want to make the changes to ps2link and send me a diff, I'll make the changes in ps2client. Then with some testing behind us we can put it into cvs.

[rinco]

Then, ps2client and XLink can have a command/option list which will allow remote selection of video mode. As an enhancement I think it would be good to have an option in IPCONFIG.DAT for initial video mode. If ps2link is able to write the IPCONFIG.DAT file, it would be handy if it updated the latest video mode selection stored in IPCONFIG.DAT.

I don't think messing with IPCONFIG.DAT is logical or practical. I'm
currently using GSCONFIG.DAT for my video selection (using graph.h
defs). My question is... are those defs now stable, Oopo?

[dlanor]

I don't think messing with IPCONFIG.DAT is logical or practical.

I second that.
IPCONFIG.DAT should remain defined as it is, partly because its name states its purpose, but mainly because other programs than ps2link and ps2client also use it. Changing its usage now would only cause problems.

Best regards: dlanor

[ooPo]

The graph stuff should be fairly stable unless something weird comes up. I'll make sure to let people know if it is going to change and offer to fix whatever it breaks.

[Steve F]

It never occurred to me to use a seperate config file graphic settings. I think that is a much better idea. I was having a bit of tunnel vision thinking that IPCONFIG.DAT was 'owned' by ps2link. Now that you mention it, any network enabled program would look at IPCONFIG.DAT for network settings and shouldn't need to filter out graphic settings. In addition, any graphic enabled program should read GSCONFIG.DAT . rinco, how is your GSCONFIG.DAT file formed?

[rinco]

I'm using:
VGA_640 or PAL

But I suggest the formal definition be something like:
MODE [PSM] [NONINTERLACED|INTERLACED] [FIELD]

Where the values correspond to the definition symbol, minus the obvious
prefix.

[Steve F]

I was planning on using the following defines for the mode numbers:

GS_TV_AUTO 0x01
GS_TV_NTSC 0x02
GS_TV_PAL 0x03
GS_TV_VGA_640_60 0x1A
GS_TV_VGA_640_72 0x1B
GS_TV_VGA_640_75 0x1C
GS_TV_VGA_640_85 0x1D
GS_TV_VGA_800_56 0x2A
GS_TV_VGA_800_60 0x2B
GS_TV_VGA_800_72 0x2C
GS_TV_VGA_800_75 0x2D
GS_TV_VGA_800_85 0x2E
GS_TV_VGA_1024_60 0x3B
GS_TV_VGA_1024_70 0x3C
GS_TV_VGA_1024_75 0x3D
GS_TV_VGA_1024_85 0x3E
GS_TV_VGA_1280_60 0x4A
GS_TV_VGA_1280_75 0x4B
GS_TV_HDTV_480P 0x50
GS_TV_HDTV_1080I 0x51
GS_TV_HDTV_720P 0x52
GS_TV_DVDNTSC 0x72
GS_TV_DVDPAL 0x73
GS_TV_DVD480P 0x74

Mode 0x01, GS_TV_AUTO will be trapped and converted with the following expression inside init_scr(). I had to do it this way because the expression has to run on the ps2 side. So for GS_TV_AUTO we will send the value 0x01.

(((*((char*)0x1FC7FF52))=='E')+2)

I already have a version of [debug]init_scr() that can be called with no arguments or a mode argument. If called with no arguments it gets defaulted to GS_TV_AUTO to remain compatible with programs that use scr_printf() and call init_scr(void). init_scr can also be called with one of the mode arguments above. I'm still working on setting up all the mode settings and testing them. While I was at it I added a call to init_scr() inside scr_printf (actually it's inside _putchar) if it hasn't been called yet. That way if you #include debug.h, you can stuff a scr_printf() into a section of code being debugged without having to worry about calling init_scr() first. It might not be the best idea but then I've only been around here a few weeks and I don't know all the history of when these were originally written.

[rinco]

I'd like to stick to using the graph.h defines if possible.

But you do raise a shortcoming in graph.c, as it only caters to 1 refresh
rate per mode.

Perhaps there needs to be graph_set_refreshrate() that can be called
before graph_set_mode()?

[ooPo]

Well, more modes can easily be defined and dropped into the graph_mode[] array... there's no need for a separate function to specify a refresh rate. That's already defined by the mode itself you supply to SetGsCrt().

[ooPo]

Code: Select all

typedef struct { int width, height, mode, interlace, size; u64 display; } GRAPH_MODE;

 GRAPH_MODE graph_mode[9] = {
  {  640,  448, 0x02, 1,  286720, GS_SET_DISPLAY(632, 50, 3, 0, 2559,  447) },
  {  640,  512, 0x03, 1,  327680, GS_SET_DISPLAY(652, 72, 3, 0, 2559,  511) },
  {  720,  480, 0x50, 0,  368640, GS_SET_DISPLAY(232, 35, 1, 0, 1439,  479) },
  { 1280,  720, 0x51, 0,  983040, GS_SET_DISPLAY(302, 24, 0, 0, 1279,  719) },
  { 1920, 1080, 0x52, 1, 2088960, GS_SET_DISPLAY(238, 40, 0, 0, 1919, 1079) },
  {  640,  480, 0x1A, 0,  327680, GS_SET_DISPLAY(276, 34, 1, 0, 1279,  479) },
  {  800,  600, 0x2B, 0,  512000, GS_SET_DISPLAY(420, 26, 1, 0, 1599,  599) },
  { 1024,  768, 0x3B, 0,  786432, GS_SET_DISPLAY(580, 34, 1, 0, 2047,  767) },
  { 1280, 1024, 0x4A, 0, 1310720, GS_SET_DISPLAY(348, 40, 0, 0, 1279, 1023) },
 };

The values are fairly self-evident, except for size. It is width times height, but rounded off to the nearest vram page - basically aligned size. Useful for knowing exactly how much vram space a single frame will take up. Adding more modes... easy as seaweed pie.

[rinco]

I agree that it is easy to hack... I already use 72hz.

Adding more modes (for refresh rates) would make the current VGA
modes redundant. But as it stands, graph.h does not have these modes.
So GSCONFIG.DAT would be best off having refresh rate as an optional parameter.

[ooPo]

Well, what it comes down to is... are you going to link with libgraph, or just use graph.h for the mode numbers?

Either way, I can add the modes myself to graph.h and graph.c. There's no real need to specify a refresh rate as you don't really get to set one on the GS - it is a part of the mode definition itself.

[ooPo]

Code: Select all

 #define GRAPH_MODE_NTSC                0       //  640 x  448
 #define GRAPH_MODE_PAL                 1       //  640 x  512
 #define GRAPH_MODE_HDTV_480P           2       //  640 x  480
 #define GRAPH_MODE_HDTV_720P           3       // 1280 x  720
 #define GRAPH_MODE_HDTV_1080I          4       // 1920 x 1080
 #define GRAPH_MODE_VGA_640_60          5       //  640 x  480 @ 60hz
 #define GRAPH_MODE_VGA_640_72          6       //  640 x  480 @ 72hz
 #define GRAPH_MODE_VGA_640_75          7       //  640 x  480 @ 75hz
 #define GRAPH_MODE_VGA_640_85          8       //  640 x  480 @ 85hz
 #define GRAPH_MODE_VGA_800_56          9       //  800 x  600 @ 56hz
 #define GRAPH_MODE_VGA_800_60          10      //  800 x  600 @ 60hz
 #define GRAPH_MODE_VGA_800_72          11      //  800 x  600 @ 72hz
 #define GRAPH_MODE_VGA_800_75          12      //  800 x  600 @ 75hz
 #define GRAPH_MODE_VGA_800_85          13      //  800 x  600 @ 85hz
 #define GRAPH_MODE_VGA_1024_60         14      // 1024 x  768 @ 60hz
 #define GRAPH_MODE_VGA_1024_70         15      // 1024 x  768 @ 70hz
 #define GRAPH_MODE_VGA_1024_75         16      // 1024 x  768 @ 75hz
 #define GRAPH_MODE_VGA_1024_85         17      // 1024 x  768 @ 85hz
 #define GRAPH_MODE_VGA_1280_60         18      // 1280 x 1024 @ 60hz
 #define GRAPH_MODE_VGA_1280_75         19      // 1280 x 1024 @ 75hz
 #define GRAPH_MODE_AUTO                99      // Automatic NTSC or PAL mode setting.

Sound good?

[Steve F]

One of the questions that came to mind working with debug/init_scr is why does it have it's own mode setup. I thought about using graph.c but figured maybe debug needs to be able to stand alone. I don't know why though. So I took advantage of the learning benifit of breaking it down so I could understand it and then started to add the other modes. I only have a few set up so I could go either way.

[ooPo]

Code: Select all

 GRAPH_MODE graph_mode[9] = {
  {  640,  448, 0x02, 1,  286720, GS_SET_DISPLAY(632, 50, 3, 0, 2559,  447) },
  {  640,  512, 0x03, 1,  327680, GS_SET_DISPLAY(652, 72, 3, 0, 2559,  511) },
  {  720,  480, 0x50, 0,  368640, GS_SET_DISPLAY(232, 35, 1, 0, 1439,  479) },
  { 1280,  720, 0x51, 0,  983040, GS_SET_DISPLAY(302, 24, 0, 0, 1279,  719) },
  { 1920, 1080, 0x52, 1, 2088960, GS_SET_DISPLAY(238, 40, 0, 0, 1919, 1079) },
  {  640,  480, 0x1A, 0,  327680, GS_SET_DISPLAY(276, 34, 1, 0, 1279,  479) },
  {  640,  480, 0x1B, 0,  327680, GS_SET_DISPLAY(276, 34, 1, 0, 1279,  479) },
  {  640,  480, 0x1C, 0,  327680, GS_SET_DISPLAY(276, 34, 1, 0, 1279,  479) },
  {  640,  480, 0x1D, 0,  327680, GS_SET_DISPLAY(276, 34, 1, 0, 1279,  479) },
  {  800,  600, 0x2A, 0,  512000, GS_SET_DISPLAY(420, 26, 1, 0, 1599,  599) },
  {  800,  600, 0x2B, 0,  512000, GS_SET_DISPLAY(420, 26, 1, 0, 1599,  599) },
  {  800,  600, 0x2C, 0,  512000, GS_SET_DISPLAY(420, 26, 1, 0, 1599,  599) },
  {  800,  600, 0x2D, 0,  512000, GS_SET_DISPLAY(420, 26, 1, 0, 1599,  599) },
  {  800,  600, 0x2E, 0,  512000, GS_SET_DISPLAY(420, 26, 1, 0, 1599,  599) },
  { 1024,  768, 0x3B, 0,  786432, GS_SET_DISPLAY(580, 34, 1, 0, 2047,  767) },
  { 1024,  768, 0x3C, 0,  786432, GS_SET_DISPLAY(580, 34, 1, 0, 2047,  767) },
  { 1024,  768, 0x3D, 0,  786432, GS_SET_DISPLAY(580, 34, 1, 0, 2047,  767) },
  { 1024,  768, 0x3E, 0,  786432, GS_SET_DISPLAY(580, 34, 1, 0, 2047,  767) },
  { 1280, 1024, 0x4A, 0, 1310720, GS_SET_DISPLAY(348, 40, 0, 0, 1279, 1023) },
  { 1280, 1024, 0x4B, 0, 1310720, GS_SET_DISPLAY(348, 40, 0, 0, 1279, 1023) },
 };

Modes added. I'll update cvs in a moment.

[ooPo]

Steve F:

Originally there wasn't any graphic stuff when debug was made, so it had its own. Its also done that way to avoid 'bloat'. I'd be interested in seeing it use libgraph myself, but I don't know if other people would be as interested as me.

Its old code. Watch out for the old guard... they resist change! :)

[rinco]

Now it looks convoluted like every other ps2 graphics lib.

How about graph.c stays the same and GSCONFIG.DAT just contains 6
values delimited by whitespace, corresponding to the graph.h struct, ie:

int width, height, mode, interlace, size; u64 display;

[Steve F]

Don't forget to change the index in the declaration to 20

[ooPo]

rinco:

Convoluted? Oi.

You'd rather reimplement graph_set_mode() than have a few modes added to the library itself?

Just what is your definition of convoluted?

[rinco]

Well I guess the convolution is required if the fastest code for graphics
initialisation is required. But having a dozen VGA modes to choose from
is what other gfx libs do, yet everything* uses AUTO (NTSC/PAL).

I've already tweaked various libs/apps to use libgraph, just so I can
easily switch between PAL and VGA.

In the perfect world the options would be NTSC/PAL/VGA and AUTO
supports VGA. If it was this simple, then I'm sure much more software
would output to VGA displays.

* yes ps2quake has vga, but where's pal huh?

[ooPo]

Well, there's already an auto detection of NTSC/PAL, but I'd really like to hear of any suggestions on how a VGA/HDTV mode can be autodetected. I don't think there's really a way to test for that on the PS2.

Btw, I've been an advocate of supporting all modes and screen ratios for a long, long time... we're on the same side here. :) If ps2quake doesn't have PAL, I'd say whoever made it lives in NTSC-land and never thought about it. Have you tried asking?

But, I still don't see how adding complication to config files and reimplementing already existing functions is a way to reach that goal of ease of use.

[ooPo]

Code: Select all

 #define GRAPH_MODE_VGA_640             5       //  640 x  480 @ 60hz
 #define GRAPH_MODE_VGA_800             10      //  800 x  600 @ 60hz
 #define GRAPH_MODE_VGA_1024            14      // 1024 x  768 @ 60hz
 #define GRAPH_MODE_VGA_1280            18      // 1280 x 1024 @ 60hz

Since you mentioned using VGA modes already, I just added these defines in addition to the refresh rate ones to not break your code. They point to the same modes that the refresh rate modes do, its just another way of specifying.

[rinco]

Ok lots of vga modes, good, let's move on.

The only known way to 'detect' hdtv/vga is with a configuration file.

My alternate suggestion is to just list the 6 values of the graph mode in
the GSCONFIG.DAT. Would you accept a patch for graph_set_mode such
that AUTO will attempt to open the file and use the values found?

[ooPo]

<rinco> i want more vga software and less effort to get it
<rinco> oopo: i'm also thinking when you auto detect video mode, you get given details on what mode you're in (width/height/psm etc)
<rinco> maybe auto needs to be its own func
<ooPo> there's functions for getting the width/height/psm of the current mode
<ooPo> already in graph.h
<ooPo> ahh, you want to have a standard function that parses a config file, eh?
<ooPo> that's an idea I can get behind :)
<rinco> i didnt think that
<rinco> but thats an even better idea
<ooPo> you kinda did
<rinco> well i want libgraph to be the standard
<ooPo> you want the actual graph_mode values to be specified?
<rinco> yeah i think that pleases everyone
<ooPo> I suppose that would give full control over the mode.
<rinco> makes it very fast, ultra flexible and not bound to any .h
<ooPo> Especially since the centering would be in the display variable.
<rinco> then you just need to be smarterest to make the .DAT
<ooPo> hmm
<ooPo> graph_config_read(), graph_config_write()?
<rinco> even better
<ooPo> give it a filename, or if none is given it'll use a default
<ooPo> I'm just trying to figure out a nice way of setting custom modes without wrecking the code too much.
<ooPo> I guess instead of current_*, I'll just use a current_mode structure and populate it whether the config or a mode was specified.

So, we'll have:

Code: Select all

graph_config_read(char *filename);
graph_config_write(char *filename);

If no filename is specified, it will attempt to read a default file. (where should this file be?). The format will be as follows, all on one line:

Code: Select all

640 448 0x02 1 286720 0x1984324254634365

These values correspond to the GRAPH_MODE structure type in graph.h:

Code: Select all

typedef struct { int width, height, mode, interlace, size; u64 display; } GRAPH_MODE;

Sound good?

[rinco]

is good

[Steve F]

Okay, I'm trying to get my head around all this.

The first thing I'm trying to solve is that ps2link reset messages output in PAL or NTSC and use PAL dimensions. When I am testing in VGA or HDTV modes I don't get to 'see' ps2link output. So I want to have ps2link use whatever mode I specify.

Now correct me if I'm wrong. The settings for the different modes as default configurations are static. NTSC, PAL, and HDTV are INTERLACE, VGA is not. I'm not sure what effect FIELD/FRAME actually causes but from what I can tell if you select INTERLACE, you always select FIELD, and NONINTERLACE always implies FRAME. I have seen field referred to as frame; I consider a frame to be two fields. Fields are odd or even. One field takes 1/60 of a second. Also, the width and height for the different modes never change in default config. I can see that setting up a custom framebuffer for special effects is possible but is beyond the scope of this work. I didn't think about PSM. I don't think it can be considered to assume a default setting. At this time I don't see that PSM would need to be specified for ps2link. What hasn't been mentioned is x and y screen offset. These could be different for each user. Also, color mode RGB/YCbCr and aspect may need to be addressed. Although these last two are already set in the console browser and easily readable, it's time consuming to reboot into the browser to change them.

So, for ps2client/ps2link I only need the SetGsCrt mode number either sent from ps2client or read from GSCONFIG.DAT. From that I can set everything else, including default xy screen offsets. If GSCONFIG.DAT was set up with mode [x offset] [y offset] I would use it as follows:

When ps2link starts up it looks for GSCONFIG.DAT. If it finds it it uses the first line as the users default. If x and y offset exist they are used. If a mode request is sent by ps2client, ps2link looks in GSCONFIG.DAT to see if the mode is listed and has x and y offsets specified. If not it will use defaults. If mode is not indicated in any form it will internally default to GS_TV_AUTO. If not already written into ps2link, I will add printf back to ps2client to report the mode being used.

I want to always refer to the mode using the SetGsCrt mode number. For the GRAPH_MODE structure array I will use a for loop to find the matching mode number and then use the array index of the match to set up the modes. This is different than graph.h and .c where the define names point to the array location. I'm not to keen on this level of indirection. I want to be able to pass or lookup the actual mode number or the define name to ps2link. The define name needs to preparse to the SetGsCrt mode number. That way there is no confusion what mode is being asked for. graph.c can resolve the mode number to the array location of the mode settings. And the array contents can be reordered with less chance of breaking things. Ya, I like that better (please). oopo, I'm pretty sure this won't break existing code unless someone coded the array index value into their call to graph.c-graph_set_mode(). Of course no one would acutally do something like that in this day and age.

Second, I don't know how to address the use of GSCONFIG.DAT the way rinco is using it. That is only because I haven't been here long enough to imagine all the ways it would need to be used. During development we want to be able to specify the different modes we are testing against. If I need a custom setting I would write it into the program and not use GSCONFIG.DAT . Would it work if GSCONFIG.DAT also configured per application? Then it would be something like:

default GS_TV_NTSC
ps2link GS_TV_VGA_60 20000 20000
ps2link GS_TV_NTSC 27648 29184
ps2quake GS_TV_PAL
launchelf GS_TV_NTSC

I've given this as an example. The first in the list for each app is that app's default. It would need a way to skip missing options if we add color mode and aspect. I think it would be okay for GSCONFIG.DAT to contain all the settings we can think of. We could use, i.e., APP=ps2quake MODE=GS_TV_PAL PSM=PSMCT32 ... . That way if the user wants to override any default setting, etc.. For the apps that use GSCONFIG.DAT they can parse and pickup the needed information. If the app isn't listed then fall back to defaults. Of course apps that are self contained don't need any of this. That would be like commercial games that allow the user to set the screen x and y position and store the settings in their own save file. But during development this should allow us to more easily exercise the hardware against our software development.