Unfortunalety, we still can't launch OSDSYS to manage virtual memory card contents. But there is a non-homebrew utility that allows to manage memory cards (format card/unformat card/view folders/delete saves and so on). That is QATool v1.2 - a SCE's software for QA teams (afaik). QATool is not a public software though it's not too hard to find it in usual places (p2p networks, etc). I managed to launch it with
and it works for me.Code:
ps2client -h ps2 execee host:mcs2emul.elf -maxfiles=2 "-ioprp=cdrom0:\IOP\IOPRP224.IMG;1" "cdrom0:\SLUS_666.66;1"
@romz: I tested with and without last argv = NULL ( argv = startup_file, argc = 8, argv = NULL ) and that make no difference here.
So, i attach an elf with last argv = NULL, can you tell me if that solve the problem with your Tekken 5 game.
Edit: This elf have a broken mc emulation. :D But you can test the game loading anyway. :)
Btw, here is PS2Link log for mcs2emul.elf:
loadelf: fname host:mcs2emul.elf secname all
Input ELF format filename = host:mcs2emul.elf
0 01200000 00028bb4 ...
start address 0x1200008
gp address 00000000
loadelf: fname cdrom0:\SLUS_210.59;1 secname all
Input ELF format filename = cdrom0:\SLUS_210.59;1
1 00100000 00030dd8 ....
2 00130e00 000242ac ...
3 00d05700 00051100 ......
start address 0x100008
gp address 00000000
Get Reboot Request From EE
ps2ip_ShutDown: Shutting down ps2ip-module
Anyone got a ps2link that will work as boot.elf in the independence exploit.
And if not exactly that way, I'm still sure we can find some other way to cram that final loader into the proper address space expected by the Sony code. We just have to persist until we make it work right.Quote:
I don't know if that's the way you saw it but i think i can work that way.
And did you ?Quote:
I'll try it today. :)
In my scan of recent posts (even after the one I'm replying to now) I couldn't see any reference to such a test.
Then we need to get its real purpose confirmed by him. Time for another visit to ps2dev.org I guess...Quote:
I don't think it's a typo mistake, maybe Neovenglist modify this for good reason, but that cause some trouble in our gui. :(
I assume he has had some problems where a misjudgement was made as to which characters share the 'most recent texture page', and indeed which page is the correct to use for a given character. That could explain all the problems we've seen.Quote:
So, to expain a bit gsKit fontM handeling:
FontM is devided in pages wich comport 2*32 chars. Those pages are 52*832 IDTEX4 textures. gsKit find which page/texture he have to use to print a chars via index, and send this texture with send_inline fonction. Just after sending it, gsKit print the char with a prim_sprite call which select only the part of texture comporting the char to print, and that for all chars, exepted if uploaded is set to 1 which mean the last char use same page/texture.
He would then force the 'uploaded' variable to zero so as to force each printed character to have the texture associated with it transferred each time, but due to some inconsistency/bug in how this is calculated we still end up with the wrong character graphics for some cases.
The forced sending of new texture data even when it should be redundant (same as most recently used I mean) will of course require more transfer time, thus increasing the need for us to 'wait' for the operations to complete before trying any new stuff. Just resending the same stuff again like you tried is not a proper solution. Instead you need to use a proper delay similar to the one we used for drawScr().Quote:
That's why i though of a delay problem and tryed to delay the texture send.
That's not the point. Making a second call at all is an unnecessary interruption of the ongoing process. Just making a delay to let the operation complete is much more appropriate. But even better would be to add a proper semaphore system to gsKit, so that it could make such delays internally, as and when needed.Quote:
I think the second call to send_inline is still too fast,
The great improvement of such a change would be that the delays would *ONLY* occur when gsKit itself knows that it has unfinished ongoing data processing, which is something that an external program like the GUI (or uLE) has no way of testing.
Adding a test function for that could also be a very good idea. This way it could be up to the main program, like our GUI or uLE, to choose whether to use the internal delays of gsKit, or to make the delay in local loops of its own so that other useful work can be performed, while periodically calling the new test function to see if gsKit has finished its pending operations yet.
I'm still not sure if that will solve all possible error cases, as these changes seem to depend in part on what 'texture pages' the text to be printed needs. In any case, ordering the same display twice when only one display instance is intended is absurd. I vote for adding a properly timed delay instead, unless you want to go the full distance and add a truly proper way of testing the completion of gsKit operations.Quote:
and the bottom of sended texture is still loose, but texture send with first call is arrived, and that solve our problem. ;)
Best regards: dlanor
Except for cases like those we discussed a while back, where some mistake in assignment of game product codes led to three different games being released with identical product codes, which was apparently the reason why FFX International was given a second release without any real changes in the code, just to give it a unique ID. But the version I have is still the non-unique one...
Another similar case is where unauthorized developers have simply 'nicked' a valid code from some unrelated program and used it for their own releases. ('Crazy Taxi' anyone...?)
Whatever, for most practical purposes the game IDs can be considered unique, but I still disagree most violently with the idea of using huge gigabyte MC images instead of a system of properly exchangeable smaller images. And I have a large number of reasons for that disagreement.
For one thing, we do want to make it possible to manage the virtual memory cards in a useful manner, with the ability to copy saves back and forth between virtual and physical MCs. That will in practice not be possible if a huge virtual MC contains thousands of gamesaves, since the MC storage methods do not allow any ordered structure of subfolders. It will just be one long list of single-level folders, which it will be pure hell to search through for the stuff you need.
Another factor to consider is that for many directory related operations there is a square-law involved in the relationship between the number of directory entries and the number of individual entry accesses needed for the overall directory handling involved in processing each of the entries in turn. So if you magnify the amount of entries by a factor of one hundred (for example) then you magnify the amount of time taken for that type of work by a factor of ten thousand... :(
Regardless of how huge vMCs we *can* make I still think there is a practical limit to the sizes we *should* use. And this means that we'll always need to have replaceable vMCs, not just a single huge one. There are other maintenance reasons too, that I won't bother to go into here. I'm sure you can think of some yourself as well.
Best regards: dlanor
However, that doesn't meant that Sony can't have their own implementation of this for the PS2, requiring some kind of terminating entry, but I have no such information.
Personally I don't think it matters, but it should never do any harm.Quote:
but I believe it's better to do so.
And that could be a much more serious problem, which I think can only be made to go away by using the standard area of a loader, as intended by Sony. Then the loader itself, and any parameters used in launching the game, setting up threads etc, should be protected in the same way as for the normal game launches made by the standard BIOS.Quote:
Besides, I don't know where to store argv array to make sure the games won't clean up those memory before they will use argc/argv parameters.
However, for the cases of launching mcemuloader/mcsioemu that parameter problem need not even apply, as those will be started and will use the argc/argv parameters before the game is started. The game may be loaded before mcsioemu, but it will not yet be started until after mcsioemu has been. So if mcsioemu uses the passed arguments only at initialization, copying them to local storage at that time, then it should be completely unaffected even if the game does trash the memory where those argc/argv parameters were originally passed.
Edit: Just to clarify:
Of course it won't help at all just to copy the argv array into local storage, as that is just a set of string pointers into the area we expect to be trashed. It is the strings themselves that must be copied to local storage, and their addresses used to build a new 'local_argv' array, while argc is simply copied into a 'local_argc' integer.
However, such methods are only important where we really need to use those arguments after the launching of the game, which should not be the case for "mcemuloader.elf", since it should go into hibernation directly after the game launch. The only vital question here is how the arguments are passed to mcsioemu, since that is the component which will need its arguments during the game in progress.
I'm not sure how the IRX launching really works when it comes to parameter passing.
Best regards: dlanor