Printable View
Be welcome, I hope this became useful either for you and dlanor, and all the users of GSM!Quote:
Originally Posted by doctorxyz
If there a green square the game is ok for that video mode, or minimal issues.
If is red, there are a major issue and the issue is explained in the end of the line.
White squares are for non tested modes, if you feel confortable, you can test this and report your results!
Thanks guys! Whenever I can I'll update the lists.
Master dlanor,
Yes, the absence of official and detailed documentation about some GS Registers that makes progress hard here.Quote:
Originally Posted by dlanor
So, it depends on the existence of enthusiastic and explorer electronic engineers professionals / students, equiped with proper tools to conduct patiently a lot of testing with osciloscope on those undocummented fields from those undocummented GS registers, in order to take conclusion about their functions.
I understand how you feel, since there is no apparent benefit... But, in fact, there are.Quote:
Originally Posted by dlanor
The freezing issue disappeared for some titles (as reported later by our psx-sceners colleagues).
After several night hours trying to solve the freezing issue (with my limited skill, time and equipment) I had to decide to stop or continue. So, I decided to continue a little bit. For that choice, I reserved for myself one strategy in order to make the tests in faster way before finally going to sleep: I make many changings together. When I got, I stopped and shared on that post.
So, I really dunno wheter "sync" instructions is enough to freezings disappear, and/or it was necessary to be mixed with the other changes to get our commn goal.
It is a possibility that only one of my many changes really make the difference... It is just a matter of make selective tests to discover it okay!
I got your point... As I stated before, it is just a question of test the code with "dsrl" again. No problem about that.Quote:
Originally Posted by dlanor
I decided to remove the following code...Quote:
Originally Posted by dlanor
... after reading the following excerptCode:"mfc0 $k0, $12\n\t" // Set user mode, interrupts on
"ori $k0, $k0, 0x11\n\t"
"mtc0 $k0, $12\n\t"
"sync\n\t"
"Interrupt Management with DI / EI
(...)information about whether interrupts are disabled or not is not included in the thread context. Thus,
problems can occur if threads are switched when interrupts are disabled or when nested DIs/EIs are used.
Frequent use of DI/EI in applications should be avoided and should only be used when atomically
accessing register groups mapped in memory. Semaphores should be used for providing exclusivity in
software-based resources such as shared buffers, etc."
(It is a recommendation I found on page 25 from a EE Kernel Lib Overview doc I have)
No. I just thought that would be better to optimise the use of memory. When I dunno where is the problem, any try is valid. One more thing to make further selective testing.Quote:
Originally Posted by dlanor
What should completely wrong here is my English :-D ...Quote:
Originally Posted by dlanor
Let me try to explain you again... The "select case" (maybe I was unhappy on calling that excerpt of code on this way) that is located on the beggining of DisplayHandler routine is the following:
And the Label "94" is the following:Code:"addi $v1,$v0,-GS_rel_SMODE2\n"
"beqzl $v1,have_SMODE2_write\n" //if dest == GS_reg_SMODE2
"nop\n"
"addi $v1,$v0,-GS_rel_DISPLAY2\n"
"beqzl $v1,have_DISPLAYx_write\n" //if dest == GS_reg_DISPLAY2
"nop\n"
"addi $v1,$v0,-GS_rel_DISPLAY1\n"
"beqzl $v1,have_DISPLAYx_write\n" //if dest == GS_reg_DISPLAY1
"nop\n"
"addi $v1,$v0,-GS_rel_SYNCV\n"
"beqzl $v1,have_SYNCV_write\n" //if dest == GS_reg_SYNCV
"nop\n"
Code:"94:\n"
"lui $a0,(GS_BASE >> 16)\n" //a0 -> GS_BASE
"lb $t0,rel_Adapt_SMode2($a2)\n" //t0 = adapted SMODE2 value
"sd $t0,GS_rel_SMODE2($a0)\n" //store it in GS_reg_SMODE2
// "sd $v0,0($a3)\n" //Store modified GS_reg_DISPLAYx
"sd $v0,GS_rel_DISPLAY2($a0)\n" //Store modified GS_reg_DISPLAY2
"sd $v0,GS_rel_DISPLAY1($a0)\n" //Store modified GS_reg_DISPLAY2
"ld $t0,rel_Target_SyncV($a2)\n" //t0 = Target_SyncV
"bnel $t0,$zero,96f\n" //if Target_SyncV is non-zero
"sd $t0,GS_rel_SYNCV($a0)\n" // store it in GS_reg_SYNCV
You have the reason. We could restore the previous code ASAP and see the results after publish a new release.Quote:
Originally Posted by dlanor
BR,
Thanks for your reports junebug!!!!
Guys he has added a lot of games to our list, just take a look!
A little question, do you have forgot to change some versions of GSM to 0.23d or do you really make some tests in a older version. If you made a mistake, I can assume that this is my mistake too. I'll change the order to the first option be the lastest version, so this will speedup the report process!
And thanks again!
Hi DarkCrono666,
They have indeed been tested with the 0.23b version - I have been testing for a quite a bit. If I have tested with 0.23b, but not 0.23d/e (as it was not available at the time) then I have used the 0.23b result. If I have subsequently used 0.23d/e then I have used that version for the result.
Hope this helps!
FYI: I've just added the GSModeSelector v0.23d beta release on 1st. post.
For sure, Now the list is updated.Quote:
Originally Posted by junebug
I'll try to test the games that have shown error to you, but in a NTSC disc, if I found them! ;)
Hi DarkCrono666,
Just some thoughts on PS2 games which should be targeted for testing as I think we have covered already some important ones.
When the PS2 was released a number of NTSC games were poorly converted to PAL - such as Onimusha, FFX, Resident Evil Code Veronica - but these now all happily work under 0.23d/e(!) @ 60hz
The original Devil May Cry was also poorly converted and I will test when I can dig it out from storage but are there any other early PS2 games which were poorly converted to PAL - apart from those mentioned? We should target those for testing I think.
Regarding other PAL games - a number of them support 60hz as an option (Resident Evil 4 for example), as well as support Progressive Scan. As my set up is strictly on a CRT TV I won't be testing those, as I know the 60hz option is available. For other users who may be interested in games supporting 60hz, an outdated list is kept here: http://www.gamefaqs.com/console/ps2/file/915821/29981
Regarding optimised PAL games - this is a tricky one. I know some games are optimised for PAL - dlanor suggested FFXII for example, but do we know of other games where GSM will not benefit/not work as the game is already optimised for PAL??
Thanks again!
minor problem of display for Old NTSC USA CRT TV
in picture GSM_20.jpg
GSM 0.20 Menu looks made for PAL TV
in picture GSM_21.jpg
GSM 0.21 and higher (0.23e) the menu half size and flickers like mad.
in picture ULE_before.jpg
ULE is perfect center (before GSM active)
in picture ULE_After.jpg
ULE is now off center (GSM active)
NB: This reply of mine is also directed to "urbigbro" who requested PAL60 as being 512i...
The instructions you gave here will illustrate the basic problem well, which is that it is NOT POSSIBLE to display 512 horizontal lines on a normal TV using either NTSC or PAL60 timing.Quote:
Originally Posted by doctorxyz
Such a TV will have its vertical sweep rate optimized to fill the entire screen with those horizontal lines that are normally used for video information. For normal 50Hz PAL this means appx 512 visible lines, and for normal 60Hz NTSC it means appx 448 visible lines.
Using PAL modulation with NTSC line timing (which is what PAL60 means) will cause a normal TV that supports such timing to switch the vertical sweep into NTSC mode, so that we still only have appx 448 visible lines, even though this is a kind of PAL mode (as far as colour modulation goes).
So selecting a 60Hz mode with normal Horizontal periods of near 64 microseconds (exact for PAL, 63,5 for NTSC), and then adding more lines to the DH parameter of GSM, will only add lines outside of the visible portion of the screen, which is useless.
Summary:
PAL60 has the same limitation on vertical resolution as NTSC has, which is effectively 448i.
Best regards: dlanor
This can be useful in some cases, but in ALL cases where the scaling does produce such black bars at present, eliminating those bars will also move some of the pixels near the screen edges outside of the displayed rectangle.Quote:
Originally Posted by urbigbro
That is how the current scaling works, choosing the largest possible scale factor that still leaves the entire rectangle area specified by the game/homebrew for its native vmode inside the rectangle visible in the enforced vmode.
One obvious exception to this rule is when the original vmode has a higher resolution than the enforced vmode (like in PAL to NTSC switching) in which case the scale factor is set to 1, and the offset value adjusted to align the center of the original vmode with the center of the enforced vmode (if at all possible, which it may not always be, since offsets are unsigned).
However, for some cases it is indeed useful to modify the DH value so as to enforce a different vertical scale factor, even if this means losing some game pixels outside the physical screen borders. This is especially useful with 'sloppily' converted PAL versions of games, since they frequently still use an effective game display of only 224 or 448 lines, instead of the corresponding PAL values 256 and 512, since the game company was too 'cheap' to invest in real graphics conversion. (This applies to nearly all games, especially high quality stuff like FFXII etc, as a real conversion would cost a lot of money.) For such games most of the pixels lost by an unrealistic DH value will only be black border pixels, which we are happier losing than keeping...
And normally this needs to be combined by some adjustment of the DY value as well, so as to ensure best centering of the visible screen.
Custom adaption of vmode settings for non-standard screen sizes will always be left as an exercise for those who have such monitors. Since I do not have them it is not something I can experiment with myself.Quote:
Another one I can think of that would be useful is what adjustments would be necessary to make a 16:9 game fill more screen on a 16:10 computer monitor. I have two such monitors:chinscrat
If those monitors currently display large borders at top and bottom using the standard predefined vmodes, then you can surely tweak DH to effectively use a larger number of pixel lines. As for the best scale factor of the horizontal axis, this can be varied more freely from 1 to 16 (4-bit MAGH), but for normal games that is little help, as they still demand precise multiples of either 320 or 640 pixels for the line width.
I have considered adding more predefined alternatives, or possibly an alternate user_mode array, supplied with some predefined values for such purposes, and which the user can activate and then store in the normal user_mode array with additional tweaks added. But it is very hard to come up with good ways for doing this that will not be too complex for the average user.Quote:
I realize that not all games will work with the same setting, but at least it give us some place to start from that can be further tweaked if possible.
The present user_mode array of 16 vmode cells should suffice for most experiments anyway.
Best regards: dlanor