Hacking Emulation POPS on PSP/Vita - Config Research

  • Thread starter Thread starter The_Ho
  • Start date Start date
  • Views Views 298,939
  • Replies Replies 1,385
  • Likes Likes 43
Hi chief, how are you? Sorry to change the subject. Do you remember which ID to use when creating the PSP eboot for Racing Lagoon (to avoid slowdowns)? I need to convert the PSX ISO patched with the recent Italian translation. Regards.

You can convert it using pop-fe; there's already a fix for that game there 😃
 
  • Like
Reactions: Nikokaro
Hello my friends, I need help finishing a configuration for Terracon.
Hi, man. How you doing? It's been quite some time, huh.

But the game has bugs with enemies freezing and moving strangely, which can be fixed by changing the ID to a Japanese initial, for example:

Original Terracon ID: SCES-02836

Change to:
SCPS-02836
SLPM-02836
SLPS-02836

This fixes the problem. I tried integrating the ID with other CMDs and Val... in an attempt to fix it, but so far only this change works, along with the Panekit configuration for performance improvement.

Does anyone have any ideas to avoid using SCPS, etc.?
Ok, this is a first. Strangely, the bios within the POPS emulator is the issue; to corroborate, I dumped the bios from my Vita and used it on duckstation, where the strange enemy movement presented itself too.

Here, you can read this text excerpt:
"POPS apply heavy 90400 bytes patch to bios if 3rd character of TITLE ID is "P" (Mostly JPN region games, but also PBPX demos...). Patch is applied to raw offset 0x18000, for now is unknown what it does." I got no idea what that patch may do, but it helps with this game.
If what you wish to do is integrate the fix properly in pop-fe, it'd be best to make a ppf patch to replace SCES with SCPS in the boot section. I have attached one for testing purposes.
The gamedb.py from pop-fe will have to be edited to give the game the custom ID.

Alternative method: I tried using the plugin POPS realboot (a more stable popbios alternative). The game had nothing unusual with enemies now. The bios used was SCPH-101 v4.5, an NTSC-U bios. PAL bioses seemed to make everything considerably faster.
Nonetheless, I recommend using the plugin just on Terracon, just in case an external bios may arise issues in other games. If using Ark-4 or 5, put "SCES02836, pops-realboot/pops_realboot.prx, on" in the plugins.txt within the seplugins folder; POPS realboot will now be use only with Terracon.
 

Attachments

Last edited by Webardo,
  • Like
Reactions: The_Ho
Hi, man. How you doing? It's been quite some time, huh.

Yeah, it’s been a while.
Work takes up so much of my time, so I’m trying to dedicate my spare moments to my family. However, I missed our testing sessions, and after a request from a pop-fe user, I decided to take a look.
I'm stuck using a mobile phone for everything right now, haha.

I’m doing well; I hope you are too.

Ok, this is a first. Strangely, the bios within the POPS emulator is the issue; to corroborate, I dumped the bios from my Vita and used it on duckstation, where the strange enemy movement presented itself too.

Here, you can read this text excerpt:
"POPS apply heavy 90400 bytes patch to bios if 3rd character of TITLE ID is "P" (Mostly JPN region games, but also PBPX demos...). Patch is applied to raw offset 0x18000, for now is unknown what it does." I got no idea what that patch may do, but it helps with this game.
If what you wish to do is integrate the fix properly in pop-fe, it'd be best to make a ppf patch to replace SCES with SCPS in the boot section. I have attached one for testing purposes.
The gamedb.py from pop-fe will have to be edited to give the game the custom ID.

Alternative method: I tried using the plugin POPS realboot (a more stable popbios alternative). The game had nothing unusual with enemies now. The bios used was SCPH-101 v4.5, an NTSC-U bios. PAL bioses seemed to make everything considerably faster.
Nonetheless, I recommend using the plugin just on Terracon, just in case an external bios may arise issues in other games. If using Ark-4 or 5, put "SCES02836, pops-realboot/pops_realboot.prx, on" in the plugins.txt within the seplugins folder; POPS realboot will now be use only with Terracon.

That’s what I thought. I appreciate your in-depth testing and the recommendation for the new BIOS plugin.

Thanks for the .ppf file.

I had already sent @ronniesahlberg a pull request with that modification, the configuration, and the .ppf; I ran a test using your .ppf as well.

But there’s a problem: the .ppf is applied to PPF00.bin, changing the ID to SCPS, but when the conversion process to EBOOT starts, pop-fe reverts to the original ID across all sectors.

The only way I found to automatically change the ID in pop-fe was by modifying the db.py and gamedb.py files.

That’s because pop-fe identifies the game ID for conversion in two ways: by looking up the MD5, and—if that fails—by using an "if not" check to find the ID in SYSTEM.CNF. It seems to prioritize that ID during the EBOOT conversion, even if a modification was applied beforehand.

The issue is that changing it this way alters the game's identification globally, affecting PS3 usage and so on...

I haven't tested it with an xdelta file yet...


=======================================================================
@Nikokaro Se preferir usar GAMEID, encontrei aqui algo sobre SLPS01222 e SLPS02180
 
  • Like
Reactions: ronniesahlberg
Yeah, it’s been a while.
Work takes up so much of my time, so I’m trying to dedicate my spare moments to my family. However, I missed our testing sessions, and after a request from a pop-fe user, I decided to take a look.
I'm stuck using a mobile phone for everything right now, haha.

I’m doing well; I hope you are too.



That’s what I thought. I appreciate your in-depth testing and the recommendation for the new BIOS plugin.

Thanks for the .ppf file.

I had already sent @ronniesahlberg a pull request with that modification, the configuration, and the .ppf; I ran a test using your .ppf as well.

But there’s a problem: the .ppf is applied to PPF00.bin, changing the ID to SCPS, but when the conversion process to EBOOT starts, pop-fe reverts to the original ID across all sectors.

The only way I found to automatically change the ID in pop-fe was by modifying the db.py and gamedb.py files.

That’s because pop-fe identifies the game ID for conversion in two ways: by looking up the MD5, and—if that fails—by using an "if not" check to find the ID in SYSTEM.CNF. It seems to prioritize that ID during the EBOOT conversion, even if a modification was applied beforehand.

The issue is that changing it this way alters the game's identification globally, affecting PS3 usage and so on...

I haven't tested it with an xdelta file yet...


=======================================================================
@Nikokaro Se preferir usar GAMEID, encontrei aqui algo sobre SLPS01222 e SLPS02180
Since this is probably only going to be something we need to do to a very small number of games, maybe this is the only game we need to do so, we could add a special case to the detection code in pop-fe like
"if converting for PSP and if this is terracon, then change the game-id to something different"
 
  • Like
Reactions: The_Ho
Since this is probably only going to be something we need to do to a very small number of games, maybe this is the only game we need to do so, we could add a special case to the detection code in pop-fe like
"if converting for PSP and if this is terracon, then change the game-id to something different"
Hi @ronniesahlberg , if you could do this programmatically by changing it to SCPS02836 (I believe this ID doesn't exist for any other game), and keep the Custom Config applied for performance improvement.

That would be excellent. I tried, but I think this case can't be completely fixed with just one configuration.
 
  • Like
Reactions: ronniesahlberg
Hi @ronniesahlberg , if you could do this programmatically by changing it to SCPS02836 (I believe this ID doesn't exist for any other game), and keep the Custom Config applied for performance improvement.

That would be excellent. I tried, but I think this case can't be completely fixed with just one configuration.
I pushed a change to master that tries to do this.
When it triggers it will log:
Rename TERRACON to SCPS02836 for PSP

Please try it, build is in the usual place.
https://github.com/sahlberg/pop-fe/actions/runs/30789448547
 
Last edited by ronniesahlberg,

Site & Scene News

Popular threads in this forum