Project: Retail DeBugging (RDB) startup card

So someone can write a iop only OPL core .
But I can not do this . I know nothing about reverse engineering .
I think ee side memory maybe the reason non compatibility example
When I checked the code , I found I changed ee_core start address to 0x00086000 but original use 0x00088000

 

IMO, you do not need DECI2 for that. In fact, quite a bit of code is required to interface with the EE DECI2 manager (the IOP DECI2 modules are large, which is perhaps one reason why the TOOL has 8MB of RAM).

If you want to, you can perhaps replace REBOOT to manipulate the IOP reboot process from the IOP side. It will have its own advantages, but it has to fit your requirements. You can perhaps retrieve your modules from EE RAM with sceSifRpcGetOtherData().

But we do not do that because the disadvantages outweigh the advantages (due to the design requirements of OPL).
Advantages:

• Little/No EE memory used. Hence totally compatible with games that try to kill HDLoader with EE-memory tricks.
  
• No hooking onto the EE kernel (will not affect the behaviour of SifSetDma).

Disadvantages:

• Need to get code onto the EE, in order to implement IGR.
• Takes up IOP RAM. There is nearly no space left, when some games run.
• Impossible to save RAM for methods like SMB. Currently, the SMB logon code is only run once (run through a non-resident module).
• Impossible to implement the extra in-game features like GSM, PS2RD, PS2IGS etc.

It may be. But you must understand that if any game has a memory conflict with OPL, it is likely an anti-HDLoader game. The official load address is 0x00100000 and they documented that user space is from 0x00100000 - 0x02000000, so there is no way for any external developer to know about memory from 0x00080000 - 0x000FFFFF.
Hence if they set the load address to 0x000A0000 (for example), then it was likely done on purpose... by Sony.

Of course, we just followed HDLoader. My own research on the Sony runtime patches suggests that it should be also okay to use as low as 0x00084000 (since Sony uses this address for the EELOAD module of the HDD Browser).

Okay, then you need to check the start address of the game. If it starts below 0x00100000, then it is an anti-HDLoader game. If it is below 0x000D0000, then it will not work with OPL v0.9.3 and this will explain why the game does not work.

You need to also check the EE_core.map file. When I made OPL v0.9.3, OPL would fit between 0x00088000 and 0x000D0000.
After I left, people kept adding things to OPL, and OPL got bigger and bigger. At some point, it grew beyond 0x000D0000.

 

This is an idea, I do not think I can ever implement it .
It may need lots of reverse engineering ;）

 

I don't have time to do this myself at the moment, however I have been tempted to see if ps3netsrv could be used for streaming ps2 games (it's the server used for streaming games to a PS3). It's a much simpler protocol than SMB, which may offer some speed and memory advantages. I have a vague feeling there is some requirement to byte swap the data using IOP when it's received and that was one of the things limiting speed, with a custom protocol then the data could be massaged on the server.