Working on OPL ,is that still fun ?

Deus Ex: The Conspiracy still doesn't work properly, as it locks up when loading a level (the border stays yellow). This happens after every five or six level loads. To see the crash, the quickest way is to either start a new game, go forward, talk to Paul (you can't avoid this, he comes to you), just rush through the conversation (just keep pressing X), then when you're finished go through the doorway into the ticket booth (which means you exit the dock), then exit the ticket booth through the other door, turn right, go forward and turn left when you have to. You'll now reach a load point, so go through that load point (the next level will load correctly), then go back through the load point you just went through, which will load the previous level again. Go through the load point again, and so on, and after five or six loads, the game will lock up with a yellow border.

I'm using a fat PS2, with a network card, and a 250GB IDE hard drive. I've tried this with lots of versions of Open PS2, starting with probably v0.6 (maybe earlier, but I know I tried v0.6, right up to a v0.94 beta that I downloaded two or three months back from:

http://www.ps2-home.com/forum/viewtopic.php?f=13&t=3

(I've tried a few of those betas), and I've tried the PAL and NTSC versions of Deus Ex: The Conspiracy, but even though the other games I've tried (all of my PS2 games, maybe a hundred in total) all work, Deus Ex, always crashes, always with the same cause and symptom a (yellow border). I've tried all of the compatibility modes in Open PS2 Loader, but none fix the problem.

The game also didn't work with HDLoader - it got to the main menu, but when you tried to start a game it would mostly just loop around to the main menu again without starting the game.

 

Sorry, but I made a mistake. Please call SifInitRpc(0) instead of SifInitCmd().
I have updated all my previous messages to reflect this.

Usually, I do SifInitRpc(0) instead and it worked ever since I started programming the PS2. I somehow remember reading somewhere that SifInitCmd() is okay in 2011, but forgot why it did not work.
Since we were on the topic of rebooting the IOP correctly, I wrote it that way... but it really doesn't work.

I checked the Sony documentation again, and it uses SifInitRpc(0).

 

Some user report Fatal Frame was broken with my OPL .
When I check this , I found this game is compatible with an older version of OPL for PS2netbox , but failed on newer version .
And this is a known problem .

Then I use pcsx2 to find out what happened .

Fatal Frame use memory between 0x92000-0x96000. These memory is used by ee_core also .
Fatal Frame use only few bytes .
So I make ee_core do not use the memory by :

Code:

// ee_core linkscript
    /* Uninitialized data.  */
    .sbss ALIGN(0x80) : {
      _fbss = . ;
     // I added this line
     // to skip using memory 0x92000-0x96000
       . = 0x6000 ;
        *(.sbss)
        *(.sbss.*)
        *(.gnu.linkonce.sb*)
        *(.scommon)
    }

I also checked ee_core.map to conform this ( and change module storage start address from 0x97000 0x9e000 ).
But Fatal Frame still can not work properly .

 

Yes, this game has some problem with OPL, but I refuse to debug it because it is a horror game (lol).

If you have no TOOL console, you can try using the DECI2 functionality that I put into OPL, a long time ago... if it still works.
It is enabled by entering "make deci2_debug" at compile-time. It will work like RDB, but will always be available (no matter how often the IOP is reboot).
I remember that I made it to also work, even if SMB is used.

Compatibility will not be 100% because the DECI2 modules will take up IOP RAM. Unlike the TOOL, we only have 2MB for CEX consoles.
But despite this limitation, you should be able to debug some games with a CEX.

With DECI2, you can try to identify the low-memory regions that the game accesses, with the EE Hardware Breakpoint function (HBP).
However, due to the SifSetDma hook, there is a need to differentiate between access by the OPL code and the game's. It will be tedious, but that's the only way that I know of.

Although I use a TOOL, the functionality here is similar - except that the CEX has less memory and the CEX EE kernel does not have the EE thread extension (cannot use the dt and ds commands, for example).

EDIT - of course, if the EE encounters an exception, you will get to see what it was.

May the force be with you. I never found debugging retail games an easy thing, but perhaps it will be different for you because you seem to have better skills.

 

I am a newbie on reverse engineering, I always think how to design a system .
So I will not debug it .

----------------------------------------------------------------------------------------
I found this

I suggest you switch to SifDMA .
SifDMA take at least two advantage on SIFCMD :
1) SifDMA do not pause DMA channel , but SIFCMD do .
2) SIFDMA do not need other side's cooperation, but SIFCMD do .
If other side is busy , can not process SIF interrupt and call SifSetDChain (reenable sif dma).
Total system performance will be decreased.
We can use a very large tcp receive window size ( eg: 1MB) and use large buffer on EE side .

To receive data from ethernet -> IOP -> EE , we can just use sifdma to transfer data from IOP to ee side ,
and use sifdma to update flags in ee memory . EE can poll these flags from uncached segment .

 

I have done with IOP only game loader .
But Fatal Frame still can not run .

Now , I am very sure it is not a memory problem ( using memory below 1M) .
When I enable printf in cdvdman and others , Fatal Frame can run normally .

 

I am not sure I found problem with Fatal Frame. But after this change , the game really run well .

ref first

second

Code:

from ESDL/system.c
inline void LaunchGame(const unsigned char *disc_img_fname, const char *filename)
{
  ...
    sbv_patch_user_mem_clear((void*)0x000D0000);    /* Patch initilizeUserMemory() to wipe user memory starting from 0x000D0000 instead. */
    patchLoadExecPS2((void *)eh->entry);    /* Patch LoadExecPS2() to not load rom0:EELOAD, but use a specified ELF loader. */
 ...
    LoadExecPS2(filename, 0, NULL);        /* Otherwise, invoke LoadExecPS2() to launch the game directly. */
}

After I change to this LaunchGame method ( with my IOP side core) , Fatal Frame gets ok .
So mabye someone can try this idea in official OPL .

 

changes to replace LoadExecPS2 with ExecPS2.

Code:

OPL/src/system.c
void sysLaunchLoaderElf(char *filename, char *mode_str, int size_cdvdman_irx, void **cdvdman_irx, MCEMU int EnablePS2Logo, unsigned int compatflags)
{
    ....
    // Let's go.
    fileXioExit();
    SifExitRpc();
#define USE_LOADEXECPS2
#ifdef USE_LOADEXECPS2
   
        /* Patch initilizeUserMemory() do not wipe memory  */       
        sbv_patch_user_mem_clear((void*)GetMemorySize());   
          /* Patch LoadExecPS2() to not load rom0:EELOAD, but use a specified ELF loader. */
        patchLoadExecPS2((void *)eh->entry);   
#endif

  

    FlushCache(0);
    FlushCache(2);

#ifdef USE_LOADEXECPS2   
    LoadExecPS2(filename,i,argv);
#else
    ExecPS2((void *)eh->entry, 0, i, argv);
#endif
  
}

Code:

ee_core/src/main.c
int main(int argc, char **argv)
{
    i=0;
    if (!_strncmp(argv[i], "EELOAD", 6)){
      // skip eeload parameters
        i=2;
    }
}

 

But you never found out what's wrong. Since this game has been working (and not working again) with some revisions of OPL, there is nothing that can be used to prove that your changes certainly help - the freeze can happen again with the next change.

Putting printf() and/or DelayThread() on the IOP can mean there is a timing problem, waiting to happen.

PS2ESDL does not replace LoadExecPS2 because there was no EE kernel patch in 2010, so we could not use ExecPS2() on the SCPH-10000/SCPH-15000.
Later on, this design stayed with PS2ESDL because I wished to save code, and it worked well because PS2ESDL has no IGR system - so there is no need to unpatch LoadExecPS2 (otherwise, nothing else can use it).

For all newer EE kernels (including the patched kernels), ExecPS2() does the same things as LoadExecPS2, except that no memory wipe is done.

Well, it is your choice. But if you have a proper way to debug your software, I think it can help with your work.

It does use SIFDMA. SIFCMD is just used to signal the other side of incoming frames (since it triggers an interrupt).
There are some tests being done to find the best design with as little overhead as possible, but the last one was not so successful. Unfortunately, my DTL-T10000 is not the same as the DTL-T15000, so I cannot tell where the performance bottleneck really is.

Today, I remembered that the SBUS allows for interrupt assertions (as well as providing status registers) between the main (EE) and sub-CPU (IOP), so I may be able to eliminate the use of SIFCMD. Some tests have to be done, but all these are very time-consuming projects.

Thank you for the suggestion. Other than SIFCMD causing the SIF to be paused, the command packet is copied with the CPU as well.

The maximum is 65536 for LWIP. I remember that it usually doesn't become full, but that was a long time ago (in 2012).

 

Yes . I do not find what's wrong .
If LoadExecPs2 does the same things as ExecPS2 , this looks very strange .
As you have seen , I call sbv_patch_user_mem_clear((void*)GetMemorySize()) to prevent memory clear .

There are two other options : LWIP_WND_SCALE,TCP_RCV_SCALE.

I download source code from your site.
It is too complex to understand in a few days .

 

Yes, LoadExecPS2 does a memory wipe, as I wrote above.

But we still need the memory wipe. Otherwise games that load ELFs may not work correctly.
PS2ESDL does use this patch to change the start location of the memory wipe, so it will not erase itself. But the memory wipe is still used.

I see, thanks for sharing.

Yes, I understand. This was my 2nd PlayStation 2 project, written in 2011. The code was bad and is still bad.
But a lot of work will be required to refurbish it, and it would be as good as rewriting the project.

Unless you want to customize it for some project, you might want to just write your own program.

 

EE_core does memory wipe , so I disable memory wipe in LoadExecPS2 to save time and prevent orerwriting ee_core .

We have talked about network performance a long time . So I just want have a try.

I hope you recompile and do a test ,after change LWIP_WND_SCALE and TCP_RCV_SCALE options.
If these two options can not improve speed , you can use wireshark to capture network traffic.

I found this also.