PS3 Cobra improvement for PSX/PS2 emulation

for my opinion best one is the trimmed iso 1:1 iso is a waste of space. offcourse best compatibility and sound multitrack support is the best choice. for ps3 we need a format better compatible with the hd (it is ext3?) after for external backup we have ntfs support (+4gb). fat32 32k? idk what is the best combo for reading speed, save space ecc
no need to argue, for ps3 games you have to use uncompressed decrypted iso generated from a backup manager such as multiman, or managunz. other formats are junk from the past of the scene. same for ps2 dvds and dual layer dvds, you have to use iso.
 
no need to argue, for ps3 games you have to use uncompressed decrypted iso generated from a backup manager such as multiman, or managunz. other formats are junk from the past of the scene. same for ps2 dvds and dual layer dvds, you have to use iso.
What's wrong with an ISO file?
 
Reanalyzing your statements, it seems like you were talking exclusively about CD games and not DVD games.

In that case, the BIN/CUE/LSD implementation that Aldo and Agrippa are working on seems to be working fine as of now for Libcrypt. CDDA games have always worked as BIN/CUE.
 
lsd stay for? (i know isnt lisergic acid...for this kind of stuff i prefer LSA... whats the story morning glory or hawaian woodrose)
 
Cobra-PS3/storage_ext.c at master · Evilnat/Cobra-PS3 · GitHub
It looks like the Cobra does set the controllers settings only. The rest is garbage filled.

I am not sure if I am right, but if this file does prevent the HDD whitelisted games to be booted properly, we could disable the generation of this file in the payload, boot the game through PS2 Classics package (to create the file by the GameOS itself) and boot the Cobra loaded backup. The game should boot successfully, using the valid settings generated by the OS.
 
Cobra-PS3/storage_ext.c at master · Evilnat/Cobra-PS3 · GitHub
It looks like the Cobra does set the controllers settings only. The rest is garbage filled.

I am not sure if I am right, but if this file does prevent the HDD whitelisted games to be booted properly, we could disable the generation of this file in the payload, boot the game through PS2 Classics package (to create the file by the GameOS itself) and boot the Cobra loaded backup. The game should boot successfully, using the valid settings generated by the OS.
That file is used to pass the commands from GameOS to the ps2 emulator. The file includes information about what file to boot, controllers, if must boot a physical disc, etc.

The games are limited to HDD by the ps2 emulator, not by that file.

The parameters are processed in this module:
https://github.com/Evilnat/Cobra-PS...AL/CEX/SRC/ps2emu_stage2/common/common.c#L341
 
The games are not limited by the PS2 emulator certainly, because they are working without problems when booted via PS2 Classics package.

You linked a different file I was talking about. I was talking about the dev_hdd0/tmp/game/ps2bootparam.dat. As you can see this file has got boot type flags which may be related to the crashing.
 
Ok, so to test the behaviour we could:

1. NOP the build_netemu_params function in payload.
2. Run the HDD whitelisted game as a 2P package to generate a valid ps2bootparam.dat file.
3. Run the HDD whitelisted game mounted by the payload. ps2_netemu should use an earlier, properly generated file from the PS2 Classic package.
4. Game should run without problems (without patching the executable file name by webMAN MOD, it needs to be turned off aswell).

Is my logic correct or not?
 
What's wrong with an ISO file?
iso is not a proper format for cd based games, sectors have size of 2048 bytes and you can not handle a multitrack disc (data+audio+audio+...). you have to use a 2352 bytes per sector format. however you have to give an external subchannel data to play the game correctly. This subchannel data, if not present is automatically rebuild from the software, but is altered in libcrypt protected games and if you lose this alteration game cannot be played. the complete format for cd based games is a 2448 bytes per sector format that supports mutitrack info (ccd/img/sub or mds/mdf for example). cue/bin/sbi or cue/bin/lsd could produce the same result but is in this case a 2352 format with some infos added by sbi/lsd, then the software rebuilds subchannels with these info.

last time i tried mounting multitrack cue/bin in managunz the audio tracks were not working, maybe i'll try again the next week. i remember that a multitrack and libcrypt cdr burned using sbitools+clonecd worked correctly on cfw.
 
iso is not a proper format for cd based games, sectors have size of 2048 bytes and you can not handle a multitrack disc (data+audio+audio+...). you have to use a 2352 bytes per sector format. however you have to give an external subchannel data to play the game correctly. This subchannel data, if not present is automatically rebuild from the software, but is altered in libcrypt protected games and if you lose this alteration game cannot be played. the complete format for cd based games is a 2448 bytes per sector format that supports mutitrack info (ccd/img/sub or mds/mdf for example). cue/bin/sbi or cue/bin/lsd could produce the same result but is in this case a 2352 format with some infos added by sbi/lsd, then the software rebuilds subchannels with these info.

last time i tried mounting multitrack cue/bin in managunz the audio tracks were not working, maybe i'll try again the next week. i remember that a multitrack and libcrypt cdr burned using sbitools+clonecd worked correctly on cfw.

Although the files are named ".iso", in the case of the CD they are raw images with sectors of 2352 bytes.
Indeed I updated Cobra payload to handle CDs with other non-standard sector sizes like 2352, 2048, 2336, 2448, 2328, 2340 or 2368.
However, only 2048 bytes of data is processed. The rest is ignored by the payload.

Cobra generates the subchannel information automatically from the track information, calculating the crc-16bit.
No external information file is needed. For LibCrypt protected files, I recently added support to read the custom subchannel info from a LSD file for the 32 sectors between minutes 3 and 9. All the other sectors use the calculated subchannel information.
 
Last edited:
Ok, so to test the behaviour we could:

1. NOP the build_netemu_params function in payload.
2. Run the HDD whitelisted game as a 2P package to generate a valid ps2bootparam.dat file.
3. Run the HDD whitelisted game mounted by the payload. ps2_netemu should use an earlier, properly generated file from the PS2 Classic package.
4. Game should run without problems (without patching the executable file name by webMAN MOD, it needs to be turned off aswell).

Is my logic correct or not?

Honestly I'm not sure what you're trying to fix. So I don't know if your logic is correct or not.
Here are the requested files in the points 1 (mamba_no_build_netemu_params.bin) and 3.(webftp_server_full_no_patch_ps2demo.sprx).

You will need to replace the file names in /dev_hdd0/boot_plugins_nocobra.txt and /dev_hdd0/boot_plugins_kernel_nocobra.txt
Or replace the existing files renaming the attached ones. Cobra must be disabled.

If you're trying to whitelist the PS2 demos, they are blacklisted in game_ext_plugin.sprx
upload_2022-6-5_7-25-56.png
 

Attachments

Last edited:
However, only 2048 bytes of data is processed. The rest is ignored by the payload.
I don't know exactly which percentage of sectors is dedicated to user data and redundant data in 2352 ps game. Maybe reduce usable data to 2048 byte per sector couldn't be a wise operation if we don't know what we're doing. What about audio tracks?
 
I don't know exactly which percentage of sectors is dedicated to user data and redundant data in 2352 ps game. Maybe reduce usable data to 2048 byte per sector couldn't be a wise operation if we don't know what we're doing. What about audio tracks?

Sorry, my mistake. I was reading process_read_cd_iso2048_cmd() which only processes the data part (2048 bytes).

The function process_read_cd_iso2352_cmd() processes all the data in the read sectors (readsize * cd_sector_size)
upload_2022-6-5_7-35-2.png
 
Honestly I'm not sure what you're trying to fix. So I don't know if your logic is correct or not.
(..)
If you're trying to whitelist the PS2 demos, they are blacklisted in game_ext_plugin.sprx

Thank you for the files. They are not technically blacklisted, they are whitelisted. I mean, if the games with that specific serial number are loaded, the GameOS will ask to create a PS2 HDD reserved space. But regardless if you agree to this or not, the emulator will crash after loading. If you load the game as a PS2 Classic, the game boots with no problems, but there is no PS2 HDD prompt obviously. The point is to locate the cause that makes the emulator to crash. As the ps2bootparam.dat is the only known thing that pass the settings from the GameOS to the emulator, it is just my assumption this file could be related to it.
 
Thank you for the files. They are not technically blacklisted, they are whitelisted. I mean, if the games with that specific serial number are loaded, the GameOS will ask to create a PS2 HDD reserved space. But regardless if you agree to this or not, the emulator will crash after loading. If you load the game as a PS2 Classic, the game boots with no problems, but there is no PS2 HDD prompt obviously. The point is to locate the cause that makes the emulator to crash. As the ps2bootparam.dat is the only known thing that pass the settings from the GameOS to the emulator, it is just my assumption this file could be related to it.

Have you tried to remove them from the "whitelist" in game_ext_plugin.sprx ?

Maybe the emulator is assuming that these games are PS2 Classics and the emulator tries to decrypt them.
 
Now I know this is somewhat throwing off this topic and I understand if this can't be done but is there a way to get the virtual ps2 hdd working without needing the very few games that use the hdd so we can use opl to load the games with cheat devices like codebreaker without needing to modify each iso to include it and utilize the compressed iso format, faster hdd load times etc.

I did try this a few years ago with just modifying the hdloader elf name within the hdloader iso with the socom slus whatever number it was with the previously created vhdd partition for socom with the ps2 system data pkg installed but hd loader didn't detect the hdd. I do have the CECHA01 ps3 and I didn't do anything else as it's outside of the scope of what I can do.

Also if it could be done, could we possibly make a 500gb or 1tb vhdd partition (i do have a 1.75tb internal hdd).
 
@Rallye89 I know the difference. I thought you were talking about DVD based games, not CD.

Mount your BIN/CUE through WebMAN MOD, not ManaGunZ. Your CDDA tracks will work. Your Libcrypt games will also work through BIN/CUE/LSD with the new Mamba payload. I think you missed some important posts before this page.
 
@Rallye89 I know the difference. I thought you were talking about DVD based games, not CD.

Mount your BIN/CUE through WebMAN MOD, not ManaGunZ. Your CDDA tracks will work. Your Libcrypt games will also work through BIN/CUE/LSD with the new Mamba payload. I think you missed some important posts before this page.

BTW I updated my previous post with a new "v6" that works with net/NTFS/exFAT/FAT32/HDD reading the LSD from a centralized folder:

https://github.com/aldostools/Resources/releases/download/Addons/boot_mamba.pkg
https://github.com/aldostools/Resou...d/Addons/install_libcrypt_subchannel_data.pkg
SRC: https://github.com/aldostools/MAMBA

I added these changes and many others to PS3HEN (it is untested, so it may not work).
 

Attachments

Similar threads

Back
Top