I have re-read that post again, but apart from an edited layout the basic info remains the same.
As for the "la" macro, I'm quite clear on that usage, though more accustomed to seeing "li" used the same way. I suppose there is no real difference between them, on the real machine code level, so it is probably just that the "li" macro is intended for immediate data values, while the "la" macro is intended for address pointers. This could actually make a difference in which kind of address calculations will work in the GCC asm expressions used, though that is just a speculation (could help with some forward_ref expressions).
Yeah, that's it, and I've just found the source: "The la (load address) macro instruction provides a similar service for addresses as the li instruction
provides for integer constants:
Code:
la$ 2, 4($3) addiu $2, $3, 4
la $2, addr lui$2, %hi_addr
addiu $2, $2, %lo_addr($2)
la $2, addr($3) lui $2, %hi_addr
addiu $2, $2, %lo_addr($2)
addu $2, $2, $3
EDIT: Good news about Freezing Issue
I've just tested a piece of trash code that does not freezes on GOW2 and Motorstorm Arctic Edge games!!!
So, It's only a matter of time (maybe one day, or a week, or a couple of them, who knows?) to make the proper adjustments, send the code to dlanor to make a peer review on it, then publish it.
Last edited by doctorxyz; 11-05-2009 at 05:49 AM.
Reason: GOOD NEWS!!!
EDIT: Good news about Freezing Issue
I've just tested a piece of trash code that does not freezes on GOW2 and Motorstorm Arctic Edge games!!!
So, It's only a matter of time (maybe one day, or a week, or a couple of them, who knows?) to make the proper adjustments, send the code to dlanor to make a peer review on it, then publish it.
Amazing guys!!!
Do you make some tests with GOW I too?? And another question. Your GOW 2 is a DVD9 ou 5? Since the last has some video compression, I think it may affect the results...
Good to hear this from you and from others. One of motivations are the recognition from the people following our hard work (yes, our and not only mine).
BTW, there are still a lot things to do on GSM.
BR,
This is great news and well done! - I don't have Artic Edge yet but soon...
I have tested some other games in my PS2 collection and there does seem to be an issue on video playback when the game first loads using GSM (v0.23b beta - using a slim PAL PS2 using an RGB Scart on a CRT television running at @60hz - cricle+left)
Medal of Honor Frontline - Plays opening video, stops on CGI intro video for new game.
Prince of Persia - Sands of Time - Plays opening video and short real time game balcony scene, stops on loading new game and new game CGI intro
Grand Theft Auto 3 - stops on loading (Plays CGI first)
Rayman Revolution - stops on loading (Plays CGI first)
Onimusha 1 - stops on loading (Plays CGI first)
Hope this helps...
One piece of trivia you and dlanor may, or may not, be interested in is that your GSM program allows, as far as I'm aware, the only PAL version of Resident Evil: Code Veronica X to run at full 60hz in Europe.
The Original PAL release on the Dreamcast did not support 60hz (rare for a Dreamcast game), nor the original PS2 X version, nor the reissued Gamecube version of X. (I have them all). Your GSM version has made this game fully 60hz for the PS2 and its frankly amazing.
This is great news and well done! - I don't have Artic Edge yet but soon...
I have tested some other games in my PS2 collection and there does seem to be an issue on video playback when the game first loads using GSM (v0.23b beta - using a slim PAL PS2 using an RGB Scart on a CRT television running at @60hz - cricle+left)
Medal of Honor Frontline - Plays opening video, stops on CGI intro video for new game.
Prince of Persia - Sands of Time - Plays opening video and short real time game balcony scene, stops on loading new game and new game CGI intro
Grand Theft Auto 3 - stops on loading (Plays CGI first)
Rayman Revolution - stops on loading (Plays CGI first)
Onimusha 1 - stops on loading (Plays CGI first)
Hope this helps...
One piece of trivia you and dlanor may, or may not, be interested in is that your GSM program allows, as far as I'm aware, the only PAL version of Resident Evil: Code Veronica X to run at full 60hz in Europe.
The Original PAL release on the Dreamcast did not support 60hz (rare for a Dreamcast game), nor the original PS2 X version, nor the reissued Gamecube version of X. (I have them all). Your GSM version has made this game fully 60hz for the PS2 and its frankly amazing.
Well done again!
Me and doctorxyz were planning a easy way to all the testers of GSM put their results and bind all results in to a table for fast consulting. In a few days it will be open!
In Killzone it happens to! The cg playback from the opening is ok, but during the load of the game it crash...
None of the GTAs work through GSM, nor in i or p modes. Maybe this last mod made by doctorxyz fix it! (I hope so )
Last edited by DarkCrono666; 11-05-2009 at 07:38 PM.
Me and doctorxyz were planning a easy way to all the testers of GSM put their results and bind all results in to a table for fast consulting. In a few days it will be open!
Yes, it is true. It just a matter of time.
Since time and skill is scarce, I have to choose what to do first, since I am a turtle to deliver results on a platform I've started eight months ago from scratch.
BTW, during this night I am making a lot of simplifications on code in order to mitigate freezing issue on titles I have.
Many non-stop hours are needed for dozens of analysis/coding/compilation/testing cicles.
Because I have to - among other things - to compare many docs and source fragments I have, in order to find a pattern, start some speculations, make testing and finally take conclusion from empirical results.
I know that it smells like a completely weird logic... But it is the only way I can deliver some results on our thread.
GSModeSelector v0.23d beta released –
11-06-2009,01:08 AM
GSModeSelector v0.23d (2009.11.06) by doctorxyz and dlanor
I hope this release mitigate considerably the freezings on titles!!!
@all,
I successfully tested the following titles on VGA 1280X896 @60Hz vmode (with the rest of settings left with the default values) and happy to inform you that I haven't noticed any freezings, nor on intro movies neither on gameplay:
- Burnout Revenge NTSC
- Flat Out 2
- GT4 NTSC - This title, I always test ;-)
- GOW2 NTSC
- GT4 NTSC - This title, I always test ;-)
- Ice Age 2 NTSC
- Ice Age 3 NTSC
- Motorstorm Arctic Edge PAL
Sorry about releasing here only the .C and .ELF (without compression) file. I have to sleep (I am ehxausted).
@dlanor,
I decided to publish it to people following us to have to opportunity to enjoy this little progress made on next weekend. I hope you don't mind.
Also, I would be grateful if you could check (when possible of course) the changes I've made on source code. All of them have a reason, and a purpose. Sorry about do not have time nor the proper English and/or technical words to justify them in a rational way. Of course, I dunno if every single change I made is really crucial to stop the freezings, but the fact that set of these modifications are working well (at least on my console, on that VGA vmode). I had to prove to myself making several trial and error coding and testing, followed of analysing the empirical results, during these last 5 non-stop hours.
Summing up:
- Some "sync" instructions were commented right after "mtc" and "lq" ones.
- Some "dsrl" instructions were replaced by "srl".
- "Set user mode on" code on "DisplayHandler_Final_Exit" section was commented, since when the processor takes a level exception, the processor switches to the kernel mode, and the control is transferred to the applicable service routine (in our case, DisplayHandler routine). So it seems a good idea the DisplayHandler leave the processor mode unchanged.
- The $k0 and $k1 MIPS regs are being stored/restored now to/from -0x10 and -0x20 relative addresses.
- The "select case" on the beggining of DisplayHandler routine now has the same order of precedence of the four GS registers patched (SMODE2, DISPLAY2, DISPLAY1, SYNCV) on "94" ASM label.
- Every time one DISPLAYx is trapped, both ones (DISPLAY2 and DISPLAY1) are written.
- "lui" instructions related to the KSEG_func_base and KSeg address pointers were replaced by "la". So now this address pointers can accept a wide range of address on kseg, in order to host resident GSM routines and its related data (MIPS Register Context and many flags) on different places. Useful for using with XBRA Protocol or some app / titles that already use the address used by GSM.
- Some cosmetics on coding commands(changing tabs by spaces, those /n/t stuff by /n, etc.)
Well, I hope I remembered the crucial part.
Master, I would grateful again if after checking the changes mades, you package all thing in a proper package, with a the correct English and Technical words, with a compressed ELF, etc. on first post of thread. ASAP, of course.
At last but not at least: Feel free to make more improvements and changings if you want okay!