I couldn't get it to work neither on my PSP nor my Vita, using ARK-4 on the PSP and ARK-X on the Vita. I did download and install the build you linked.
What is the test case you're using? I kinda need to set it up to be able to work on this D:
I was using "Bugs Bunny - Lost in TIme" (SLUS-00838). It's easy enough to test, you just have to select a language and either get a black screen if no config is injected, or go to the title screen otherwise.
A game like Dragon Valor/Rollcage Stage II may be faster to test though, because with no config those just stay at the Playstation boot indefinitely.
Wether the eboot was made with PSX2PSP or pop-fe didn't make a difference either.
Can you share the config for those?
Also try this one pls:
https://github.com/PSP-Archive/ARK-4/releases/tag/v1722011545
Sure.
Bugs Bunny - LiT: SLUS-00838
Dragon Valor: SLUS-01092/SLUS-01164
Rollcage Stage II: SLUS-00867
Gimme a moment and I'll try it, most likely in about an hour if there's not much hurry.
I'm sorry I don't know what to do with this configuration, are you supposed to change the title id? cause this patch doesn't do that, it replaces the data right after that.
There's no hurry, I've already delayed this a lot myself lol.
Oh no, I just attached the configs to the post. You can download them from the zip file, I gave their ID to avoid confusion and know which is which.
Post automatically merged:
Doesn't work either
. Did I set the files wrong?
Last edited by Webardo,
Nice, but I think you need to do some small additional changes.
I think the current code only works for single-disk games from the PSN store and not for multi-disc games or games converted by pop-fe.
See : https://www.psdevwiki.com/psp/PSISOIMG0000
In the code you take the offset as :
config_offset = header.psar_offset + 0x420;
But this only works for single-disk games from the PSN store because it assumes that the PSAR section starts with a PSISOIMG block.
That is not always the case and sometimes the PSAR section starts with a 0x400 byte large section called PSTITLEIMG before the PSISOIMG section(s).
There are three cases for what PSAR contains:
1, just a single PSISOIMG section. These are single disk games from the PSN store
2, a PSTITLEIMG section followed by a single PSISOIMG section. This is how pop-fe generates single disk eboots
3, a PSTITLEIMG section followed by 2 or more PSISOIMG sections. This is how all multi-disc games are encoded.
So you will need to check the start of the PSAR buffer and check if it starts with a 'PSISOIMG' tag or if it starts with a
'PSTITLEIMG' tag.
In the latter case the offset for the first config will not be 0x420 but instead be 0x820. (because the size of PSTITLEIMG is 0x400 bytes)
In the case of PSTITLEIMG you should also check the PSTITLEIMG offsets 0x200 for the offsets where the individual ISOs start,
the first ISO always start at offset 0x400 into PSAR, i.e. immediately after the PSTITLEIMG section itself, but there could be additonal disks.
You will need to loop, starting from PSTITLEIMG section offset 0x200 and read all the offsets to where the ISOs start.
A value of 0x00000000 means no more disks.
This will complicate the code slightly because it will no longer be just a single config_offset but it could be up to 5 different config_offsets (max number of disks in a relased game is 5) so you need to keep track of up to 5 different config_offsets.
The good thing though is that you do not need to keep track of up to 5 different CONFIG.BIN. As far as I know all multidisk games that have a config has an identical config for all the disks so you should be able to just read CONFIG.BIN and just inject the same data for each disk in the multidisc eboot.
Last edited by ronniesahlberg,
ok this makes a lot of sense. I'll have to prepare a few proper test cases as this is going to be a bit more complex (though not by that much).
Sadly that patch fixes different issues, this is from the compatibility list of the PS2's POPS emulator: "When you start playing, the scenery is severely displaced towards the lower end of the screen. Freezes after the first few voiced dialogues. There also is a crash when entering the pause menu, making it impossible to save."
And there's the fact that it is written in assembly specifically for that iteration of POPS...
I could ask the dev of the patches for more information though, maybe something is missing from that description.
Also, if do this kind of patching,, why not also automatically patch in the 'magic word' to handle all the libcrypt dists?
If you look at https://www.psdevwiki.com/psp/PSISOIMG0000 you can find the diskid at offset 0x400 into PSISOIMG. Read this and remove the two underscores.
I have attached a file that consists of a list of all libcrypt disc-id and their respective magic-word (in decimal in the attached file).
If your disk-id is in this list then you take the magic word, xor it with 0x72D0EE59 and then write it as a 4 byte integer to offset
0x12b0 in the PSISOIMG section.
This will tell the emulator to generate corrupted subchannels for the correct sectors and make the libcrypt tests succeed.
That is all it takes to "fix" libcrypt. Write 4 bytes at a special offset into the eboot. That is all it takes :-)
Last edited by ronniesahlberg,
Do we know exactly how POPS issues reading commands to the PSISOUMG file? I'm tempted to think it reads sector by sector (1K at a time) but it could also be issuing arbitrary reads.
If we can properly detect what pops is reading then we can inject just about anything really.
No, we don't know how it reads it. :-(
But it should read the PSISOIMG and access all its embedded fields the same way for any game. So if we know how it reads it for one game we should know how it does it for all of them.
The only way to find out how it does it is probably if you can add logging so that for reads from the EBOOT it llogs the offset and length to a file.
Can you try add logging like that and launch a PS1 game?
I can help take a look at the log if this is possible.
(Also, just mentioning that these things we are talking about, pop-fe does this automatically when generating an EBOOT
but having this in the CFW would still be very useful for people that have other EBOOTS, like from the PSN store
or ones created with, say, PSX2PSP)
Yeah that's what I'm gonna do. Initially I assumed that it read the config structure directly, but it might read the entire sector it's located in. Anyways, I'm almost done setting up test cases, will report back soon.
-
The Real Jdbye
*is birb*
