Game Exit button combo #543
-
|
When playing a game in OPL I often use the L1/L2/R1/R2/start/select button combo to exit the game. Is it possible to exit the game and return back to the OPL menu instead of the memory card menu screen? It's kind of a pain to have to exit the memory card menu, return to FreeMcBoot, and wait for OPL to launch again to change your game. I'm about to update to 1.10. Thank you to all you smarter than I people who dedicate your time to this project. I'm really enjoying playing my PS2 with OPL. :) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
Yes, but it's also a pain the ass and sometimes doesn't work ... What I used to do is take a copy of the OPNPS2LD.ELF file and rename it to "IGR.ELF". From there, I'd made a folder on MC0 named "IGR" and paste the IGR.ELF into it. Next, I'd launch OPL and configure the "IRG Path" in the options to point to that IGR.ELF. That way, every time you invoked the L1/L2/R1/R2/START/SELECT macro, OPL would then chainload back into itself instead of doing a soft reset back into FMCB/FDHB ... Works about 95% of the time, but that 5% of the time you'll get a RED screen, BLUE screen, or a BSOD ... which requires getting off the ol' duff, walking over the PS2, and power cycling the unit anyway. I stopped doing it because I'm a fat lazy bish ... once I sit my happy ass on my couch, I'm like Rosa Parks -- I am NOT movin' ... :P LOL Oh, and forgot to mention: IGR Paths in OPL can NOT point to paths on MASS or HDD0. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any way the OPL app can be written to support this feature reliably? |
Beta Was this translation helpful? Give feedback.
-
|
We tried our best, especially SP193, who described the way our IGR code works as "violently wrenching control of the hardware" to execute the process, and games that already use and tax the PS2's resources (or does stupid shit that Sony explicitly told developers never to do) are coincidently the games that react to the intrusion by freezing or locking the system up at some point during the IGR process. Much of this could be just bugs, leakage, or instability within OPL itself where compatibility becomes an on again/off again nature. For example, when I used to chainload back to OPL through an IGR.ELF in my path, I'd often forget to update that IGR.ELF whenever I recompiled the latest revision of OPL, and that mismatch would cause BSODs after an IGR ... |
Beta Was this translation helpful? Give feedback.
-
|
You can launch igr from usb, you just need to place correct drivers in mc0:SYS-CONF/USBD.IRX and mc0:SYS-CONF/USHDFSD.IRX |
Beta Was this translation helpful? Give feedback.
Yes, but it's also a pain the ass and sometimes doesn't work ...
What I used to do is take a copy of the OPNPS2LD.ELF file and rename it to "IGR.ELF". From there, I'd made a folder on MC0 named "IGR" and paste the IGR.ELF into it. Next, I'd launch OPL and configure the "IRG Path" in the options to point to that IGR.ELF. That way, every time you invoked the L1/L2/R1/R2/START/SELECT macro, OPL would then chainload back into itself instead of doing a soft reset back into FMCB/FDHB ...
Works about 95% of the time, but that 5% of the time you'll get a RED screen, BLUE screen, or a BSOD ...…