GS Mode Selector: Development & Feedback

[dlanor]

SyncV VGA 480p60 is the only progressive mode that works. It looks beautiful on my 24" widescreen CRT monitor!!

I agree that it is a useful resolution for a VGA monitor, since it combines a fairly high horizontal rez with an also high vertical rez. But that is possible at 60Hz only because this resolution is NOT progressive. It is in fact interlaced. Otherwise it would be quite impossible to have those 896 raster lines.

Best regards: dlanor

[dlanor]

Like the title says I have just released v0.22 of GSModeselector, and the release package is available in the first post of this thread. The changes for this version are as follows:

GSModeSelector v0.22 (2009.10.03) by doctorxyz and dlanor
-Modified access trap methods to allow for more registers
-Implemented separate access trap handling for SMODE2 and SYNCV registers
-Implemented opcode recognition table for trap cause analysis
-Added 'Source' variables for SMODE2 and SYNCV trapped register values
-Modified asm methods again to further simplify maintenance and updates
-Added makefile dependencies for macro and asm header files
-Eliminated all redundant use of quadwords for doubleword variables
-Added CNF file loading and saving (GSM.CNF loads automatically at launch)
-Added proper PAL/NTSC init using rom0:ROMVER (works for slim models too)
-Added 2 separate fixes for games & OSDSYS using interlace plus FFMD=1
(one for interlaced forced vmodes and another for non-interlaced)
Due to these fixes the OSDSYS/FMCB menu now works in all forced video modes
-Implemented an array of eight user-definable vmodes, savable to CNF file
-Added GUI menu commands to manipulate user-definable vmodes
-Added GUI menu command to save CNF file


The above means that it is finally possible to save some of your favourite vmode settings to a CNF file on memory card, so you don't have to repeat the same tweaking at every launch, just to get that perfect centering of your games etc.

The first time you launch this new version it will look for a "BOOT" folder on an MC, and store a file named "GSM.CNF" there, if there isn't one there already.

The program first looks for GSM.CNF on mc0, and if that fails it looks on mc1. If both lack such a CNF file the program tries to create one, first on mc0 and if that fails on mc1. Whenever the program has succeeded either in finding a CNF file or creating one, it memorizes which MC that was, and for the rest of the session all save attempts will use that MC (unless you remove it )

If for some reason you want the CNF on mc1 only (like I do), make sure mc0 is removed when you first launch this version. This way it will keep using the CNF on mc1 even when mc0 is present later. But if you make some mistake in this, or change your mind later, you can always move the file to the MC you want it on by using uLE, as the CNF content is not specific to either slot.


The user-defined vmodes are in fact the same modes that you already can set with the 'preset' commands. But now you have additional commands to store and load that preset setup into an indexed array with 8 slots. And when you use the menu command to save the CNF file (in same place as before), the entire vmode array is saved with it.

Do not confuse that array with the set of predefined constant vmodes you can normally choose from, as those also remain and are unaffected by any edits you make to the user-defined vmode array.

This means that when you have filled that array with tweaked vmode settings of your own, you still also have access to the 10 (currently) predefined vmodes in the main menu. So this gives you access to a total of 18 different vmode setups.

Access to the user-defined vmode array is admittedly a bit awkward, as you must use the R2+Left and R2+Right combos to step the array index to the position you want, and there you can then press R2+Up to store the current preset to the array (think of it as an 'Up'-load) or press R2+Down to load the current preset from the array (consider that a 'Down'-load).

Note that loading array content this way only sets the preset variables accordingly, so you must still press 'Down' button (alone) to activate that preset as a physical vmode.

Another thing to remember is that there is no 'autosave' feature, so if you exit GSM without having remembered to save the CNF, then all the array changes you made since the last save are lost. To save the array contents at any time in the GSM GUI, simply press L2+R2. There will then be a slight delay for the file saving, and then there will be a visual glitch just as when you edit a value, so you know that the write operation is complete. (Safe to turn console off etc.)


As for the graphical improvements in this version, I believe that the bug which squashed true screen data upwards with garbage beneath it is now completely fixed. One of the programs which suffered from that problem is the OSDSYS/FMCB menu, which now displays perfectly in all supported resolutions (interlaced, progressive, HDTV, VGA, in any mix), and this also applies to some games I've tested that used to have the same problem.

There should be some other improvements as well, though I have not myself had time to verify these with many games. The extreme glitches for FF10 in 720p are completely gone though, and I have not yet seen any game that just gave me a black screen, though there are a few that have other problems and even can crash.

For example, my PAL version of FF12 will run only in PAL or 576p vmodes, but crashes in all others. and even when it runs it does some weird scaling of its own, causing the effective screen area to shrink... This could be due to an insanely high DW value in its DISPLAYx pokes, in which case we may be able to work around it with some game-specific scaling patches in future. But as yet we have not designed any system for game-specific patch modules, so that will have to wait quite a while (if ever...)

Best regards: dlanor

[katananja]

- Feedback for GSM vx.xx
v0.22

- Console region and version
SCPH-90006

- GS id/rev
Revision Number: 30 - ID: 85

- TV/Monitor/cable/connection settings
Video component

- ELF Launch method
FMCB/uLE

- Game/app title tested
MotoGP.

- Source title resolution settings (use your TV/Monitor features to help you)
480i

- Target title resolution modes choosen by you (in detail whenever it be useful and possible)
480p

- Results obtained, comments, critics and suggestions
Black screen after "NAMCO".

I did test other modes that end up with the same results, I think that if we could make the 480p work right first we might get a chance to make others resolution work (or not).

First thing I've noticed is that when selected 480p in GS the "NAMCO" logo has some interlaced artifacts:

This is GS 480i/p with my chip OFF, both pregressive and interlaced options show the same low res. image or interlace artifacts and screen is off center:


Now this is the same image with chip OFF and not using GS, so is a standard 480i mode:


I've take some other photos that show different register information when my chip is ON with 480p and the other is when chip is OFF, the picture that say "DISPLAY something are trapped!" is when my chip is ON at 480p mode.

Suggestion for a next release, if possible to add a function to start the game from GS menu.

[urbigbro]

I agree that it is a useful resolution for a VGA monitor, since it combines a fairly high horizontal rez with an also high vertical rez. But that is possible at 60Hz only because this resolution is NOT progressive. It is in fact interlaced. Otherwise it would be quite impossible to have those 896 raster lines.
Best regards: dlanor

How is it that my CRT monitors that only accept progressive signals are fooled into thinking it is? Perhaps they do accept interlaced, but only at this higher rez? I've never had any other device that could output an interlaced signal with a higher rez and RGB color space till now.

I don't see the SyncV VGA 480p60 in the v 0.22 release. Is there a different way to activate it or has it now been made redundant?

Game Update:
Downhill Domination now displays correctly in interlaced modes!

[Vegeta]

I'm also getting the same low-res image output as katananja with 480p selected with GSM 0.22. Its as if the images are displayed with half of their vertical resolution.

Even games with a verified (H)640x(V)448 framebuffer like Tekken Tag Tournament look like this.

[dlanor]

- Game/app title tested
MotoGP.

- Source title resolution settings (use your TV/Monitor features to help you)
480i

- Target title resolution modes choosen by you (in detail whenever it be useful and possible)
480p

- Results obtained, comments, critics and suggestions
Black screen after "NAMCO".

Hmm. So just a black screen and nothing else.
Well, it's useful to know that it happens, but not very much to go on...
I'll see if I can get hold of that game to test it myself.

I did test other modes that end up with the same results, I think that if we could make the 480p work right first we might get a chance to make others resolution work (or not).

First thing I've noticed is that when selected 480p in GS the "NAMCO" logo has some interlaced artifacts:

This is GS 480i/p with my chip OFF, both pregressive and interlaced options show the same low res. image or interlace artifacts and

Unfortunately some ways of rendering an interlaced image are impossible to emulate perfectly with our current methods, as there is no way for us to tell the GS chip to read data alternately from two different buffers, as required with games that use INT+FFMD mode. instead we have to settle for using just one of those two buffers, at double height instead. That is the best fix found so far, for physical modes without interlace.

But you should be able to get much better results when using a physically interlaced mode, such as when using GSM to switch between PAL/NTSC, or when using 1080i. The latter is excellent for PAL games particularly, as the height factor is near perfect doubling (or 4x for uninterlaced games), while the width is a precise triple of normal screen width. This is ideal for the kind of magnification the GS hardware can do. But 1080i is not so good for NTSC games, as there will be large borders at top and bottom then.

Like I mentioned in the release notes, there are two different fixes for the INT+FFMD rendering methods. The one for progressive physical vmodes only has access to one buffer, giving that ugly pixel magnification, but the one for interlaced physical vmodes uses the original INT+FFMD method, to give the same visual appearance as the 'original'.

screen is off center:

We can not possibly center the default settings perfectly for everyone, so tweaking the centering is your own responsibility. With the new GSM version you can also save tweaked settings, which should make it easier for everyone.

Having said that I must also add that I am open to suggestions and even voting on the best default screen positioning values, as I too am less than happy with some of those choices. However, different equipment has different needs. Settings ideal for my old CRT TV will give horrible centering on my HDTV, and vice versa.

As I see it we should optimize the NTSC/PAL vmodes for normal TV sets, and the HDTV vmodes for HDTV sets, and of course the VGA vmodes for VGA monitors (though I never test them so myself, using only the VGA input of my HDTV instead).

But for ideal centering, each of you will have to tweak the settings yourself, since there are no settings that will please everyone.

Now this is the same image with chip OFF and not using GS, so is a standard 480i mode:

Like I said above. The only method we have to make a decent display of that rendering method for a progressive physical vmode does unfortunately lose half of the graphic detail. For now this is something you just have to live with, or try to use an interlaced resolution instead, since that does allow us access to both of the two buffers.

I've take some other photos that show different register information when my chip is ON with 480p and the other is when chip is OFF, the picture that say "DISPLAY something are trapped!" is when my chip is ON at 480p mode.

That info doesn't really tell me much, but i hope you realize that the methods of the chip for affecting vmodes may interact with our methods, so with chip on all bets are off...

Suggestion for a next release, if possible to add a function to start the game from GS menu.

Why ? I see no possible reason to do so, and even consider the present support of directly launching HDL to be overkill. But with the number of different game launch methods around today there is no way I will even consider adding them all to the GSM GUI. That would be absurd. (Let's see now, 3 or 4 different USB launchers, plus various HDLoader versions, plus ESR, plus disc-swapping tools and I almost forgot the normal disc launching too (the least important method to us )...)

No. A simple exit to OSDSYS or to uLE will have to do for most of these. Anyone with a halfway decent homebrew setup should be able to take it from there. But since we now have a CNF file I will consider the possibility of adding a configurable elf path to the CNF though, replacing the fixed elf path of HDLoader for the exit command [Start]+[RIGHT].

Thus you can then replace it by whatever elf you prefer, simply by text editing the CNF file.

Best regards: dlanor

[dlanor]

How is it that my CRT monitors that only accept progressive signals are fooled into thinking it is? Perhaps they do accept interlaced, but only at this higher rez?

I suspect the latter is true.

However, in the latest version of his GSM which doctorxyz sent me he had removed that vmode, and I did not reinsert it at this time in merging my own changes, so the current release does not have it at all.

I've never had any other device that could output an interlaced signal with a higher rez and RGB color space till now.

All older VGA CRT monitors have basically the same circuitry as an old CRT TV, minus some of the stuff specific to broadcast reception, and tweaked for different HSync and VSync intervals. But as long as incoming syncs match the needed frequency range there was never anything to stop them from synchronizing to an interlaced signal in much the same way as a TV does it. It is a bit different with newer monitors that have more software internally to control the monitor behaviour. That might actually prevent some vmodes from working even if the monitor would be physically able to display them.

I don't see the SyncV VGA 480p60 in the v 0.22 release. Is there a different way to activate it or has it now been made redundant?

It is not present in the current release, but we may add it back in later on.

Game Update:
Downhill Domination now displays correctly in interlaced modes!

I'm glad to hear it.

Best regards: dlanor

[katananja]

I don't know if this can help the project or not, my chip can switch GS up to 1080i with PS1 or PS2 games, there is a way to do a program to call GS registers information and display on the screen so the project/developers can use the information?

Something very simple, I switch the chip resolution from 480i to 1080i and for each resolution the program display whatever is important for developers to know about GS.

Maybe this can speed up things on the developers side.

About the function to start the game direct from GSM is to speed up the test process, but if it is a bad idea, no problem.

[dlanor]

I'm also getting the same low-res image output as katananja with 480p selected with GSM 0.22. Its as if the images are displayed with half of their vertical resolution.

That is a valid observation, as the GS chip is indeed restricted to accessing only half of the raster lines intended for use, for these specific cases.

Even games with a verified (H)640x(V)448 framebuffer like Tekken Tag Tournament look like this.

That is not quite true. In fact they have two buffers of half that height.

Let me explain the difference:

There are two different ways of rendering a normal NTSC picture using a true resolution of 640x448 pixels. (The same applies to PAL too, only some numbers differ). For each of those methods the GS renders one half-frame per VSync period, containing half of the graphical information, either the odd-numbered raster lines or the even-numbered ones. But the method in accessing those lines is different, and related to how the game software builds the graphic frame buffers.


One game method uses a single buffer of 448 raster lines of 640 pixels. The SMODE2 setting for this method has INT=1 and FFMD=0, which means that in rendering each half-frame the GS chip will skip every other raster line. And for each VSync it will alternate between starting with the first and the second line of that buffer, thus ensuring that it will all be displayed.

There is never any problem with emulating this method in a progressive mode, since all the information is available in one sequential buffer. We just set the mode properly and the buffer will be read WITHOUT any alternation, which works fine.


The other game method uses a pair of buffers each holding 224 raster lines of 640 pixels. Effectively this means that one buffer holds all the odd lines, while the other buffer holds all the even lines, so each represents the output of one half-frame. Both buffers contain the general appearance of the main picture, but with differing details. The SMODE2 setting for this method is INT=1 and FFMD=1, which means that in rendering each half-frame the GS chip will read each one of the lines of the current buffer, but will instead alternate between the two buffers for each VSync period.

This method gives us serious problems with progressive modes, since there is no built-in support for the kind of access we'd need here, alternating between the two buffers for each raster line to be rendered. Doing so is not possible for us. So instead we are stuck with the method of simply doubling the height of the pixels, so that they at least fill up the correct space on screen and prevent the rendering from including uninitialized garbage RAM content, as seen in testing these games with previous GSM versions (when they could be displayed at all that is).

I know that this method isn't really satisfactory, but it is the best we have, and far better than what we had before.


One method that migh improve this a little would be to alternate between the two buffers for each VSync, while still magnifying them as now. This would effectively cause all the graphic information to be present again, though with odd-numbered (original) raster lines timesharing the space of the even numbered ones, with some risk of flicker.

Some of the original picture clarity would still be lost, but I think it might still improve the overall impression, and for a higher VSync frequency the flicker would be less noticeable.

But to try this we need to find a way for the GS chip to handle most of it automatically, since many games won't suffer much intterupt-driven interference before crashing. So for the moment this is what we're stuck with.

But remember also that this problem only applies to enforcing a progressive mode.
So it has no bad effects for PAL/NTSC switching nor when enforcing 1080i.
(Unlike old GSM versions, which had such problems for those vmodes too)

Best regards: dlanor

[Vegeta]

One method that migh improve this a little would be to alternate between the two buffers for each VSync, while still magnifying them as now. This would effectively cause all the graphic information to be present again, though with odd-numbered (original) raster lines timesharing the space of the even numbered ones, with some risk of flicker.

Some of the original picture clarity would still be lost, but I think it might still improve the overall impression, and for a higher VSync frequency the flicker would be less noticeable.

Thanks for the in-depth explanation dlanor. I understand now.

I noticed Tekken Tag Tournament (NTSC/J) produced flicker in 480p with Xploder HDTV Player and now I know why.