I know what you mean, but it isn't that. The music playback definitely breaks up and stutters, it seems to be when the game slows down. But it is much better than before, when the sound constantly stuttered.
I'm not sure, I believe we've been working with the vanilla settings from sony for each POPS.Do we have a reverse engineer of the simple/complex module?
It might be a good idea to have full control over it to be able to do more custom patches.
It should be possible with lots of patches, it will however be worse than PSP pops, you won't have any audio since SPU emulation is handled by the native Vita ARM cores.I wonder however, would a reverse PopsLoader be doable? I mean, to use Vita's POPS on PSP. Just wanted to know wether something like that could be possible or not, perhaps it's too much of a unnecessary hassle. I give you my thanks beforehand!
I did very minimal RE of simple/complex to make the ARK-X loader (the eboot contains a specially crafted PRX instead of simple/complex), it contains bootstrap code for pops but also some configuration stuff.I'm not sure, I believe we've been working with the vanilla settings from sony for each POPS.
You'd be better off asking @mrjaredbeta, who's a lot more knowledgeable on this than me.
Well, almost all of the config commands have been reversed and documented by kozarovv here: https://www.psdevwiki.com/psp/POPSThe reason we should reverse it is because it would allow us to cook any type of custom patches directly into the eboot. We can patch the game's binary or the pops emulator itself.
I see, makes sense seeing as the PSP used (I think?) the ME for sound on POPS, which the Vita lacks.It should be possible with lots of patches, it will however be worse than PSP pops, you won't have any audio since SPU emulation is handled by the native Vita ARM cores.
Say, could you then change POPS' settings from the console only? Just by having the configs in a specified folder you could load them up maybe. This way it wouldn't matter what converter was used for the eboots.I did very minimal RE of simple/complex to make the ARK-X loader (the eboot contains a specially crafted PRX instead of simple/complex), it contains bootstrap code for pops but also some configuration stuff.
The reason we should reverse it is because it would allow us to cook any type of custom patches directly into the eboot. We can patch the game's binary or the pops emulator itself.
Indeed, on PSP pops uses ME to emulate sound. When the Vita was released and Team PRO hacked it (and ported over PROCFW in what is now known as ARK), they were able to patch PSP pops to make it work on Vita, and they ported the PEOPS SPU Plugin over to have some sound working. It wasn't perfect but it was the FIRST ever PS1 player on Vita, way before official support was added by Sony (who simply took Team PRO's idea and made their own patched POPS with their own SPU plugin running on Vita side).I see, makes sense seeing as the PSP used (I think?) the ME for sound on POPS, which the Vita lacks.
It should be possible yes, but then you'll be depending on the CFW to implement such feature. The only CFW that is actively developed right now is ARK, even Adrenaline seems to have stopped development. I wouldn't mind implementing this, but I'm not sure if it's the best way to go.Say, could you then change POPS' settings from the console only? Just by having the configs in a specified folder you could load them up maybe. This way it wouldn't matter what converter was used for the eboots.
Totally understandable, way too much hassle for minute differences.Indeed, on PSP pops uses ME to emulate sound. When the Vita was released and Team PRO hacked it (and ported over PROCFW in what is now known as ARK), they were able to patch PSP pops to make it work on Vita, and they ported the PEOPS SPU Plugin over to have some sound working. It wasn't perfect but it was the FIRST ever PS1 player on Vita, way before official support was added by Sony (who simply took Team PRO's idea and made their own patched POPS with their own SPU plugin running on Vita side).
It should be possible to do the inverse and load Vita POPS on PSP, but like I said, you'll have sound issues (unless you figure out a way to inject PSP's ME SPU emulator into Vita POPS). Too much work, not enough payback.
Of course, there will still be other methods to have your config injected, be it with pop-fe or manually editing an already made eboot with a hex editor. It'd just be another way to have it more accessible for those that are actively using ARK.It should be possible yes, but then you'll be depending on the CFW to implement such feature. The only CFW that is actively developed right now is ARK, even Adrenaline seems to have stopped development. I wouldn't mind implementing this, but I'm not sure if it's the best way to go.
Do we know the pops function responsible for loading the config? I can hijack it if a custom config file is found and read the config from it.Of course, there will still be other methods to have your config injected, be it with pop-fe or manually editing an already made eboot with a hex editor. It'd just be another way to have it more accessible for those that are actively using ARK.
I do not know, try to contact kozarovv (https://www.psdevwiki.com/psp/User:Kozarovv), or once again, try asking @mrjaredbeta.Do we know the pops function responsible for loading the config? I can hijack it if a custom config file is found and read the config from it.
Nice going there! If you do get it to work there should be no more need for PopsLoader.I've been checking the destruction derby 2 crash. From what I can see using psplink it seems that it converts a pointer to what seems to be a float yet the pointer is unaligned to 4 bytes. Currently trying to find a fix.
They both use the same Vita POPS emulator but with different patches, so the end user experience is a bit different, though compatibility should be the same.Does it work exactly like Adrenaline? Could Arc X be compatible with Popsloader?
No they don't conflict at all and can actually be combined into one.Do you know if there is any conflict for having adrenaline and the latest ecfw Arc on PS Vita at the same time?
Not too sure.Do we know the pops function responsible for loading the config? I can hijack it if a custom config file is found and read the config from it.
By the way, PCSX2 has the same exact issue with this game. Maybe that can help the debugging process. We were never able to find a fix for this one. Looking back at my history, this is what I have:I've been checking the destruction derby 2 crash. From what I can see using psplink it seems that it converts a pointer to what seems to be a float yet the pointer is unaligned to 4 bytes. Currently trying to find a fix.
BFC4D988 - function that writes to 0x0000a8c4, value is address used later to overwrite useful data.
the instruction at 0xbfc4d988 stores incorrect address to 0x0000a8c4, which is then loaded later as address to write graphics data to, but is overwriting other stuff at this point
My experience with pops was to exploit it back in the day (I was the first person to ever find a vulnerability in a ps1 game) and what I could tell is that a bug in PS1 code gets translated into a bug in PSP code (+emulator bugs, but pops have very few).By the way, PCSX2 has the same exact issue with this game. Maybe that can help the debugging process. We were never able to find a fix for this one. Looking back at my history, this is what I have:
This is all speculation based on debugging from PCSX2. I usually have no idea what I am talking about, but maybe these address will point to something useful.
That is odd. What happens on real hardware if you try to read/write a 32 bit register to a 16bit aligned address?My experience with pops was to exploit it back in the day (I was the first person to ever find a vulnerability in a ps1 game) and what I could tell is that a bug in PS1 code gets translated into a bug in PSP code (+emulator bugs, but pops have very few).
Since PCSX2 also has the bug, then it's probably an emulator issue, but since it only affects this game then it's also possible that the game does something that's "undefined behaviour" or some dirty half-bugged code.
I did some further analysis of the crashes and this is more or less what's happening:
- there's a pointer aligned to 2 bytes
- the pointer is accessed as a 32 bit value
- a float is attempted to be stored in this pointer
There are two types of crashes I can get:
- trying to read a 32 bit word from the unaligned pointer
- trying to store a 32 bit float into the unaligned pointer
Now what's most interesting is the first crash, since it happens in pre-generated/patched code, meaning that the instruction to "store a 32 bit word on a 16 bit aligned pointer" should be 100% what the original ps1 code is doing, it's trying to store a value into a 2-byte aligned pointer.
However the second crash shows that the data that's supposed to be in the pointer is a float.
On PS1 the main CPU doesn't have an FPU, so instead of floats there's only fixed point. I believe the issue is that the emulator is failing to translate a fixed number into a float (and/or viceversa).
A crash (exception) of course. I don't think the game is trying to store a 32 bit value to the pointer, it's probably storing a 16 bit value but the emulator incorrectly identifies the data type. It all smells like some issue with float vs fixed point.That is odd. What happens on real hardware if you try to read/write a 32 bit register to a 16bit aligned address?
I am pretty sure that is just how the game is.Hello, I would like to report another game that although it works perfectly on adrenaline has the problem that the initial loading is very slow, it is Racingroovy VS, an japanese arcade driving game similar to the first Ridge Racer developed by Sammy, on this occasion I consider that it is a good game, hopefully a config can be found that fixes it.
Thank you.
Do we know where in the eboot.pbp the config is injected? I'm guessing it's in the "simple" module ("complex" in psx2psp), the prx embedded in the eboot.Not too sure.