Working on OPL ,is that still fun ?

Official OPL is mature . Ee_core and iopcore have not changed for a long time .
When compiling source code even not given a warning .
OPL become routine business,boring, complicated.

After discuss with @sp193 , I found there are something to improve .
Talking about them is very fun to me , so I start this thread .
As I sell ps2netbox/ps2usb , do not ask me add there feature to OPL . I will not do this .
I have these point :
1) IOP only ee_core
2) Network performance

No code at ee side , when we need it ,IOP overwrite ee's idle thread by dma .

I finally found this

 

Game compatibility is not 100%. When I stopped work on OPL, it still had some issues that I did not totally understand. They may require game-specific fixes.

There may also be an issue with USBExtreme format support Some people noticed that game compatibility is slightly lower when we use the USBExtreme format, but it is not clear what the flaw is.

There were some reports about how some games like Half-Life will have buggy audio and can crash, but can be avoided if OPL is booted from the browser's menu via FMCB.
So I believe that some of these games may have a bug in their LIBSD module, which makes them dependent on a specific state of SPU2 (which rom0:CLEARSPU nor OPL's SPU-resetting code cannot fix).

There are also some bugs/design issues in OPL's GUI. On the last page of the bug reports thread, there are some new comments about them.

I am not trying to say that this idea is not good (I also considered it before), but have you checked to see if this is necessary for the overall functionality of OPL? IMO, only a handful of games will be affected because most of them are compliant with the Sony documentation.
If very few games are affected, maybe you might want to focus on other areas of enhancement. Since the only way to avoid using EE memory, is by using another sort of memory. But IOP memory is very precious.

I mean, you would usually have no code on the EE. But you still need to copy the code to the EE via DMA, and this code must be stored somewhere first.

You may also already know this, but just in case: when using DMA, beware that the EE has data and instruction caches. So even if you use DMA to overwrite program memory on the EE, the EE may not use the new instructions (without a cache flush/writeback/invalidate).

Thanks for sharing.

 

This is why I chose ee idle thread .
When cpu is busy on other function , idle thread 's code is not in the cache .

 

Oh yes, you can also consider trying to backport the LWIP v2.0.0 TCP core locking function into OPL's TCP/IP stack, which is used in-game.
With it, it becomes possible to avoid message-passing entirely. There was an improvement in performance after upgrading to v2.0.0.

That would be hard to ensure, IMO. But you can try.

Even if the developer does not deliberately set a thread to wait/sleep/suspend, Using things like SIFRPC will likely cause the thread to sleep/wait. Waiting on a semaphore can also cause it to sleep. When no other thread is in READY state, then the idle thread will run. So unless the EE is kept at 100% utilization, it will execute the idle thread.

 

you can go this page if you are interesting become new OPL developer
https://github.com/ifcaro/Open-PS2-Loader/commits/master

 

@sp193 I can not find your post . But there is another (not good) idea.

Tcp only need some information. We can save this information ,
remove all SMB login related code from Ingame IRX , and restore these information on cdvdman's entry point .

 

Some code was already split off into smbinit. So it is possible to move code between the two.

There may also be a need to rewrite the SMB support within the PS2SDK and OPL to use SMB2, as SMB may be phased out. I don't know whether Microsoft plans to maintain support for it, but it is not enabled by default in their new operating systems.

 

Actually SMB2 was designed with performance improvements in mind. Whether the PS2 can take advantage of them in the way we use it is another story:
Request pipelining allows multiple requests to be sent before receiving a response
Larger reads and writes make better use of faster networks, even with high latency
Request compounding, which allows multiple SMB requests to be sent as a single network request
Caching of folder and file properties, where clients keeps local copy of information on folders and files
Durable handles allow a stateful connection to be reestablished in case of network issues
Much smaller opcode set reduces complexity of the protocol implementation and attack surface
Message signing improved (HMAC SHA-256 replaces MD5 as hashing algorithm)
Improved scalability for file sharing (number of users, shares and open files per server greatly increased)

All these lead to significant performance improvements for common scenarios like folder enumerations and file copies.

 

I just wish the network option to copy ISO's to your PS2 HDD worked.

 

@ps2netbox: but please do not get the wrong idea. I am not saying that you should not try. I just want you to know that from my experience, some things may not work so well. Just so you can plan better.
If you have a very clear plan to try out your ideas, please go ahead. There are some things, like network support, that I wasted a lot of time on. Which is why I am very sour about it, even though perhaps there is a way to get the restrictive hardware to work well (just that it will not work with my methods).
I started off as a common n00b who could only request for features in 2008, so I am not actually a professional game developer.

And hence, it would make good sense to upgrade. But to save on code footprint (since adding onto SMBMAN to support both SMB 1.0 and SMB 2.0 is possible), we may want to draw a line to say that operating systems older than Windows XP will not be supported.

As of v0.9.3, I remember it was working. It's a v0.8.6-compatible server, so you must use the correct client for it.
If it is not working as of the current head, are you using something from ps2-home? If so, have you tried a vanilla build?

 

No ,actually , I have no plan with any idea . All of them are very vague.
But I still want you and others talk them with me .
If many users like one of them , I will have a try .

And another :
Action reply : I think this can be implemented by hook sio2man like pademu .

 

In French :
La fonctionnalité "PADEMU" est un vrai plaisir pour mon équipe (testeurs) et moi-même. Nous en faisons le test avec la version officielle (r1027) de OPL à l'heure actuelle. Les résultats sont très convaincants et la DS3 est une merveille de souplesse et de réactivité. La connexion en USB directe (filaire) est excellente car aucune déconnexion de manette à faire lorsque les jeux sont lancés. Par contre, en mode USB/BT, il faut toujours appuyer sur le bouton PS de la manette une fois le logo "PlaySation 2" affiché à l'écran car elle s'éteint complètement.
Voici un lien vers une liste qui devrait vous convaincre du fonctionnement remarquable de cette manette :
==> https://docs.google.com/spreadsheets/d/1MLEw7TIKvn9MCwd5Ptbqh2lkUj3lX6YQ2wPgLEx8Koo/edit#gid=0
Faire un clic sur les onglets "DS3/BT" ou "DS3/USB" pour connaître les rapports (résultats)

Pour autant, @ps2netbox, il me semble que de nombreux problèmes vont surgir avec ton interface car aucune clef USB ni aucun adaptateur n'est activé (ou reconnu) lorsque ton interface est active chez moi. Il va te falloir ruser.

In Engrish (by Google) :
The "PADEMU" feature is a real pleasure for my team (testers) and myself. We are testing it with the official version (r1027) of OPL at the moment. The results are very convincing and the DS3 is a marvel of flexibility and responsiveness. The direct USB connection (wired) is excellent because no disconnection of joystick to do when the games are launched. On the other hand, in USB/BT mode, always press the PS button on the controller once the "PlaySation 2" logo is displayed on the screen because it goes out completely.
Here is a link to a list that should convince you of the remarkable operation of this controller:
==> https://docs.google.com/spreadsheets/d/1MLEw7TIKvn9MCwd5Ptbqh2lkUj3lX6YQ2wPgLEx8Koo/edit#gid=0
Click on the tabs "DS3/BT" or "DS3/USB" for reports (results)

However, @ ps2netbox, it seems to me that many problems will arise with your interface because no USB key or adapter is activated (or recognized) when your interface is active at home. You will have to be cunning.

 

Yes , this is why we need the option "Game Use Usb".
When user need use usb device , they must set this option on , and unplug usb data port and use usb power connector only .
PS2Netbox 's usb port is used not only for power but also for accessing OPL onboard.

 

Whyever my 1st thoguht was, yayyy, a thread about someone working with the Yamaha OPL soundchips. ^^

https://en.wikipedia.org/wiki/Yamaha_YMF262

 

@sp193
I have done with iop only ee_core . But not for load PS2 GAME.
I use it to launch other PS2 APPs .( Then redirect harddisk /mass device to ps2netbox/ps2usb).
Now , SMS (simple media player ) has worked( redirect hdd).
Super Nintendo ported by you has worked ( redirect mass)
uLaunchElf (with some modified code) has worked ( redirect mass)
But lots of app can not be launched.
Can you give me some suggestion on how to continue ?

 

What are these apps that cannot be launched?

Some software must access other files to work, and these will probably be incompatible because they cannot access the required files after boot. However, I do not really know of other homebrew software that will have this requirement, apart from my own software (PS2Ident, HDLGameInstaller, FMCBInstaller, HDDChecker).

If you are sure that the problem is with LaunchELF, can you please show me what modifications that you made (i.e. which file and what)?
For your case, you should probably only need to add the modules and to change LaunchELF's filer.c to support the new device.

 

I use uLaunchElf to debug my IRX.
I just remove loading dev9,ps2hdd, ps2fs,usbd,usbhdfsd2 irx , make it load my irx for ps2netbox.
Everything works ok .
I can use it mount virtual memory card file , so user can import/export game saving.
I will have a test on official version today .

I found a strange problem with Super Nintendo, if I do not zero out unused memory , it can not run .
Last loaded module is libsd. So I think there maybe is bug in libsd's ee side code .
( Some data structure is used without proper initialized.)

eg : fceumm, I think there is a bug around audsrv_irx line.
I launch original elf , source code is just for ref.

Spoiler: code

Code:

int LoadBasicModules(void)
{
    int ret = 0,old = 0;

    smod_mod_info_t    mod_t;

    if(!smod_get_mod_by_name("sio2man", &mod_t)) {
        ret = SifLoadModule("rom0:XSIO2MAN", 0, NULL);
    }
    if(mod_t.version == 257)
        old = 1;
    if (ret < 0) {
        printf("Failed to load module: SIO2MAN");
    }
    if(!smod_get_mod_by_name("mcman", &mod_t)) {
        ret = SifLoadModule("rom0:XMCMAN", 0, NULL);
    }
    if(mod_t.version == 257)
        old = 1;
    if (ret < 0) {
        printf("Failed to load module: MCMAN");
    }
    if(!smod_get_mod_by_name("mcserv", &mod_t)) {
        ret = SifLoadModule("rom0:XMCSERV", 0, NULL);
    }
    if(mod_t.version == 257)
        old = 1;
    else
        mcReset();
    if (ret < 0) {
        printf("Failed to load module: MCSERV");
    }
    if(!smod_get_mod_by_name("padman", &mod_t)) {
        ret = SifLoadModule("rom0:XPADMAN", 0, NULL);
    }
    if(mod_t.version == 276)
        old = 1;
    else
        padReset();
    if (ret < 0) {
        printf("Failed to load module: PADMAN");
    }

    return old;
}
void LoadExtraModules(void)
{
    int i,ret,sometime;

#ifdef SOUND_ON
    ret = SifLoadModule("rom0:LIBSD", 0, NULL);
    if (ret < 0) {
        printf("Failed to load module: LIBSD");
    }
    ret = SifExecModuleBuffer(&audsrv_irx, size_audsrv_irx,0, NULL, &ret);
    if (ret < 0) {
        printf("Failed to load module: AUDSRV.IRX");
    }
#endif

    ret = SifExecModuleBuffer(&usbd_irx, size_usbd_irx,0, NULL, &ret);
    if (ret < 0) {
        printf("Failed to load module: USBD.IRX");
    }
 
    ret = SifExecModuleBuffer(&cdvd_irx, size_cdvd_irx, 0, NULL, &ret);
    if (ret < 0) {
        printf("Failed to load module: CDVD.IRX");
    }

    ret = SifExecModuleBuffer(&usbhdfsd_irx, size_usbhdfsd_irx,0, NULL, &ret);
    for (i  = 0; i < 3; i++) { //taken from ulaunchelf
        sometime = 0x01000000;
        while(sometime--) asm("nop\nnop\nnop\nnop");
    }

    if (ret < 0) {
        printf("Failed to load module: USBHDFSD.IRX");
    }
}

I use these :
2008/03/02 19:22 1,074,660 FCEU.ELF
2018/02/03 16:03 1,432,936 SMS.elf
2018/02/02 17:02 605,152 FC.ELF
2018/02/02 17:02 758,156 SNES-Station+v0.2.4+USB(SFC).elf
2018/02/02 17:02 3,018,624 PGEN151(MD).ELF
2018/02/02 17:02 613,752 INFOGB(GB).ELF
2010/10/05 20:30 552,840 PS2InfoGB_2.elf
2016/09/07 02:20 842,373 Super Nintendo.ELF

 

All the best to you with it.

If you mean my mod of SnesStation, there was a problem with the PS2SDK's freepad. This does not apply to other versions of SnesStation because only my mod uses freepad (for compatibililty with all PlayStation 2 models).

Under certain conditions, the IOP will hang due to an incorrect status check on the SIO2 interface. I noted that wiping memory (within LaunchELF) seemed to cause the problem to go away, but it does not make sense because replacing the memory wipe with a delay also makes the problem go away.

I once managed to reproduce this bug in one of my other software too. I noticed that changing the order in which the SIO2 modules are loaded also affected it. Not initializing the pads also made it go away. And so it had to be a problem with freepad.

The bug was fixed in the PS2SDK, but SnesStation has not been updated.

If you wish to fix it, please compile a new version, with the latest PS2SDK revision.

The source code looks like LaunchELF's... whereby it does not do an IOP reset by default and tries to reuse modules that were already loaded.
I see no check for modules like USBHDFSD, so perhaps it tries to load USBHDFSD over your fake module (if you are using one).

You can try adding this to the very start of the main() of fceumm, just to see if wiping the IOP of all modules helped:

Code:

int main(int argc, char *argv[]) {
    SifInitRpc(0);
    SifIopReset("", 0);
    while(!SifIopSync()){};
    SifInitRpc(0);
    ...
}

If it is not possible to compile a new version of fceumm, you can add this code fragment to the end of LaunchELF's EE loader (before ExecPS2) instead:

Code:

    ...

    SifInitRpc(0);
    SifIopReset("", 0);
    while(!SifIopSync()){};
    SifInitRpc(0);
    SifExitRpc();

    ExecPS2(...)

However, this cannot be a permanent solution because it will break compatibility with some software the expect access to the device that they were loaded from, to be provided by the loader (i.e. Quake).

 

I test this uLE . It is ok !

Code:

 SifInitCmd();
   SifIopReset("", 0);
   while(!SifIopSync()){};
   SifInitCmd();
   SifExitCmd();

I add these to my elf loader , it do not work.

Yes , it is yours , I do not know why other version can not work .

I use these ,most of them are used to make SMS happy .

Code:

static char *lmb_modulefake_list[]={
    "AllowDVDV",
    "atad",
    "usbhdfsd",
    "usbd",
    "dev9_driver",
    "atad_driver",
    "USB_driver",  
    "hdd_driver",
    "pfs_driver",
//    "Poweroff_Handler",
    NULL
};

SNES-Station+v0.2.4+USB(SFC).elf use a very old usb mass driver.
maybe this.
I get this log :
usb_mass_bindRpc(): SifBindRpc failed: -1 !!!!

 

Okay, then have you managed to determine where the program gets stuck at? (Other than SnesStation, which is bugged).

No other? This would be challenging to answer because ffgriever's work is generally closed-source. The packer used to pack his work seems to be unusual too.
Maybe it is best to ignore SnesStation for now.

Sorry, but I do not understand what this array is for. It looks like it is part of OPL, but what has OPL got to do with LaunchELF?

Yes, a long time ago, the USB Mass Storage device driver was usb_mass.irx and it also had its own RPC library.[/QUOTE]