Jak 3: Another game that doesn't work with HDoader/hdadvance

[ojomvas]

I'm trying to understand the trick, Crazyc, how did you know "cdvd_ee_driver" was the thing responsible for the non working status of the original iso?

[crazyc]

Jak 3 attempts to unload the cdvd_ee_driver aka CDVDFSV. Since HDLoader replaces that driver, and doesn't provide any way to allow it to be unloaded, the game gets stuck in a loop as Viewtiful Joe did, but Joe was stuck on attempts to unload CDVDSTM.

[PERRINO]

for crazyc

hello

Is it the same thing for syberia 2 you think.
if there is, could you explain me how find the offset and how change it

thanks

[crazyc]

>Is it the same thing for syberia 2 you think.
>if there is, could you explain me how find the offset and how change it

Doubt it, I've looked at several games and only those two can be fixed like this.

[dlanor]

Jak 3 attempts to unload the cdvd_ee_driver aka CDVDFSV. Since HDLoader replaces that driver, and doesn't provide any way to allow it to be unloaded, the game gets stuck in a loop as Viewtiful Joe did, but Joe was stuck on attempts to unload CDVDSTM.

Hmmm, doesn't that imply a possible solution...?

It reminds me slightly of the original datestamp problem. That was because games tried to use an alternate time function that was not implemented by HDLoader. Now we have a problem with games that attempt to use an unloading method (or methods) not implemented by HDLoader.

This time the solution can't be to implement the missing stuff, since unloading the CDVD driver would mean that HDLoader loses control, so that no more CDVD accesses would be redirected to the HDD (right?).

But are we really sure that the game truly needs to perform that unloading ? Might it not be the case, that it would work fine with the existing CDVD driver of HDLoader, if only it would give up the attmpts to unload it ? If that is the case, then we could make a patch that implements simulated unloading of the driver, without actually unloading it at all, but telling the calling program that it was done. Such simulation functions could also be added for cases where games attempt to load new drivers that would replace those of HDLoader (a natural followup to unloading, I guess).

The drawback of this method is of course that if a game really does need a proprietary driver, with features not covered by Sony specs, then that game will fail to work when we simulate the loading of that driver and actually keep the HDLoader drivers active.

But on the other hand, that drawback only applies to games that didn't work with HDLoader to begin with, so nothing has really been lost.

I'm still not very sure about the techie details of all this, but it might be worth trying... What do you think ?

Best regards: dlanor

[crazyc]

>This time the solution can't be to implement the missing stuff, since unloading the
>CDVD driver would mean that HDLoader loses control, so that no more CDVD
>accesses would be redirected to the HDD (right?).

Well, not quite, because nothing attempts to unload CDVDMAN, which performs the real work. I do know that using Sony's CDVDSTM with hdloader's CDVDMAN doesn't work at all, and it would probably be the same with CDVDFSV.

>But are we really sure that the game truly needs to perform that unloading?

Jak 3 seems to, because people who have tried to write the modified image to a dvd have found it doen't work. Don't know about Joe.

>Might it not be the case, that it would work fine with the existing CDVD driver of
>HDLoader, if only it would give up the attmpts to unload it?

That's what the patches do, in effect.

>If that is the case, then we could make a patch that implements simulated
>unloading of the driver, without actually unloading it at all, but telling the calling
>program that it was done.

The problem with this method is that the IOP kernel will want to unload any modules that depend on the module being unloaded and will probably attempt to reallocate the memory it was using. Another way could be to return success to the code running in the EE, but that would either require patching MODLOAD in memory or trying to skip over MODLOAD, cleaning up the stack and returning to the RPC message function, both rather difficult.

>we simulate the loading of that driver

Loading appears not to be a problem as the IOP kernel seems to return a handle to the already loaded module if it finds one with the same name there.

[Dany22]

Crazyc,

As i see you have some knowledge about finding and modifying the games elf files with ps2dis and the hex editor so that they will work with HDL/HDA...if u have time and patience to write a small guide about finding the correct offset(s) for other non-working games (like Test Drive, Crash Twinsanity, Neo contra etc.) and changing them with the correct value so they will work also with HDL. Most of the new games have this CDVDSTM.IRX file wich i guess..unloads when the game(s) boot from the HDD..i presume its the same procedure except the offset is different..anyway let me know..if u can help me out with this..so i can patch some of the other games

Bye

Dany22

[PERRINO]

Hello

i try to find the offset for jak 3, but i don't understand all.

i have open the SCES_524.60 of jak3 pal with ps2dis an find the label :
"unload cdvd_ee_driver failed %d\n"
i have



an i press space bar and F3

i have



so i dont understand where find the offset 3BA0

so if some one could help me

thanks

[Skm]

hm, could you maybe create a ppf patch for jak 3 pal version?
would be great!!^^

[eMaNoN]

totally cool if ALL INCOMPATIBLE GAMES WILL have PATCH like this jak3 to make it work on HDLOADER....