PS3 Compatibility List - PS2 on PS3

kozarovv said:
FPU rounding to nearest
Click to expand...
So thats what the netemu 0x0F command does ? ;)
I mean, the description in wiki (i guess added by you) is
More accurate memory range (FPU mul/div/sub/add accuracy related)
Click to expand...
Just incase there was some doubt about it, now is confirmed is related with FPU, and maybe what is doing is exactly a "rounding to nearest" with the values in the range

Btw, there is something from the kuon config (nice and weird game, btw) that surprised me a bit, the values after the 0x0F command are "start address" and "end address", but in the kuon config both values are the same o_O

I know the config works but im trying to imagine what is doing the emulator with it, either:
-is only rounding 1 opcode (4 bytes lenght) ?
-is rounding all the opcodes located before it (or the other way around, all after it) ?
 
I usually set 0x0F from 0x100000 to 0x1FFFFFFF to start and see if it fixes the problem. Since it did, I just narrowed it down to the exact value that was having the problem. I did the same with Silent Hill 2 and 3's camera issues.

And I know the command 0x0F is a range, but for mul/div accuracy it seems like there's no command for a single address (like there is for add/sub accuracy). I think it is starting from that address and ending at that address.
 
nictse said:
Tested.
1st 2nd level ladder issue fixed.
2nd level kill two-saw-big-guys issue fixed.
but frame seems not very stable.and 2nd level around cutsence house flicking issue worse than old configs.
Click to expand...
I'm tested too. Acept that Ladder problem and Freezes fixed but yes flicking issue stiil! Also in moment when u shoot Largest bell (Cutscene start) its very very low and better just skip cutscene. Im bet some more cutscenes have that problems too. But that config better then old, becouse fix freeze problems for us version. And now eur. version looks better im think
 
mrjaredbeta said:
I usually set 0x0F from 0x100000 to 0x1FFFFFFF to start and see if it fixes the problem. Since it did, I just narrowed it down to the exact value that was having the problem. I did the same with Silent Hill 2 and 3's camera issues.

And I know the command 0x0F is a range, but for mul/div accuracy it seems like there's no command for a single address (like there is for add/sub accuracy). I think it is starting from that address and ending at that address.
Click to expand...
Ok, so you found the exact problematic opcode with the test-error method, nice :D

It took you much time ?, i guess this feature (to add or modify the 0x0F command in a config) could be added to managunz PS2 config editor @Zar is just a matter of entering 2 values
We know the valid values for the range, and by default (when 0xx0F is added in the config for first time) the values could cover all the range
 
kozarovv said:
I just realized i had set FPU rounding to nearest as i was playing with Stuntman. Probably that's way to solve it for pcsx2.
Click to expand...
sandungas said:
So thats what the netemu 0x0F command does ? ;)
Click to expand...
Wait, i have a theory... in the PS3 configs we have 2 commands located consecutivelly related with the accuracy of a range (0x0F and 0x10), this means that was implemented at the same time because are very related to each other

Now we know the 0x0F matches with the setting [FPU]>[Round Mode]>[Nearest]
But im looking at the PCSX2 settings and incase i had to select only 2 of them and im wonder which one could be the other (for the description of 0x10 command), i guess command 0x10 could be "round to positive"

Have you tryed to see if the other rounding modes availabels in PCSX2 solves the problem in kuon too ?, or only is solved when using "nearest" ?
EE-IOP.png
 
kozarovv said:
SLUS_207.73 mipmap removing/fix textures
Code: 
3d 00 00 00 11 11 00 00 0a 00 00 00 01 00 00 00
50 8f 18 00 20 00 60 10 20 00 00 10 00 00 00 00
SLUS_215.55 mipmap removing/fix textures
Code: 
3d 00 00 00 11 11 00 00 0a 00 00 00 01 00 00 00
c0 97 12 00 22 00 60 10 22 00 00 10 00 00 00 00
SLUS_212.03 mipmap removing/fix textures
Code: 
3d 00 00 00 11 11 00 00 0a 00 00 00 01 00 00 00
90 73 12 00 22 00 60 10 22 00 00 10 00 00 00 00

Will be nice if someone can test that.
Click to expand...

More ports. @Vika23 please test as you asked me for this.

Lara Croft Tomb Raider - Legend SLES-53908
Code: 
3D 00 00 00 11 11 00 00 0A 00 00 00 01 00 00 00
E8 73 12 00 22 00 60 10 22 00 00 10 00 00 00 00
 
sandungas said:
Now we know the 0x0F matches with the setting [FPU]>[Round Mode]>[Nearest]
Click to expand...
No, no. Is not so easy :D 0x0F is accurate math for some floating points operations. While PCSX2 going different way by rounding floats based on that setting.

Only thing that relate is 0x0F = rounding issue on pcsx2. But that not always gonna be nearest setting. 0x10 is not round to positive ;) I reversed that on PS4, and using config from ps3 on ps4 will give you EXACT name of function. So i know that's Accurate Math is correct name for them. Just difference is COP2 or FPU, and ADD/SUB or MUL/DIV.
Cons of their (pcsx2) solution is that some rare games require negative rounding here, and positive there, and for rest of games chop/zero is fine. For example that Kuon fix on pcsx2 can potentially break other things in game.
On PS3/PS4 we have no issue with that. But.. We need to know correct offsets for those calculations. So is harder to find patch, but it is better patch as it won't brake other stuff. Good example of game having issue like that on pcsx2 is GT4, they need to CLAMP calculation of floats to make game work, but license require different mode where they also clamp operands. That break game, and you need to change it by yourself. While on ps3, or ps4 we just patch correct offsets with accurate math, done.

Also command 0x08 sometimes relate to VU rounding or clamping on pcsx2, good example is Tony Hawk 4+ , and Castlevania COD. But 0x08 is overall VU patch, and fact that sony used it to correct some values is why sometimes it fit for this theory. :D
 
kozarovv said:
Never looked into that. Maybe command 15 with value 4, or 7 with value 8 can help.
Click to expand...

Hey kozarovv,

thanks for your answer! What do you mean by changing the command line? I'm a complete noob with hex editing. ^^

Could you take a quick look into the game because I think the game can be fixed quickly or give any tips on how to change the file?

I have to change the iso file with a Hex Editor and find the right line and change the values right?
 
lex3a said:
Are you really sure that you have a correct version of the game?
Check your game's ISO it should match to Redump one
Also check your game's executable (SLUS_206.85), it's MD5 should be 41a7197582cdf79f01019386797e662f.

I am hundred percent sure about correctness of this CONFIG. The only thing I did was find the correct memory address - 0034CE88. This address was tested in PCSX2 and it works like a charm, there is no more texture flickering (GSDX software mode, unchecked Mipmap emulation). Bytes are flipped In the CONFIG, so address must be 88CE3400, check my post with the CONFIG and you will see the same bytes.


@kozarovv CONFIG should be the most complete. It includes ladder fix, my ported config by Prafull which should fix slowdowns in some places of the game (https://forums.pcsx2.net/Thread-Bug-Report-Ghosthunter-PAL) + patch from GX_EMU
Click to expand...


sorry bro,i tested again,gameplay perfect,but opening cg still flicking.
i tested EU vesion before,opening cg not flick.
did u forget sth?
 
kozarovv said:
No, no. Is not so easy :D 0x0F is accurate math for some floating points operations. While PCSX2 going different way by rounding floats based on that setting.

Only thing that relate is 0x0F = rounding issue on pcsx2. But that not always gonna be nearest setting. 0x10 is not round to positive ;) I reversed that on PS4, and using config from ps3 on ps4 will give you EXACT name of function. So i know that's Accurate Math is correct name for them. Just difference is COP2 or FPU, and ADD/SUB or MUL/DIV.
Click to expand...
Ok, is nice you found the official codenames for it, is just the names for that commands (the ones i colored in orange in the table in wiki talk page) are a bit abstract, like the "improved accuracy range" or "improved accuracy maths"... are not telling exactly how are improving it :D
When you mentioned the rounding setting of pcsx2 it made me brainstorm a bit, because the different rounding types are actually a way to prevent innacuracies in maths calculations... so i was like... "hmmm, maybe ps2_netemu.self is just doing some roundings with the floats in 0x0F and 0x10 commands"

But based in your explaination it seems is more related with the aritmetic operands + - % *
The way i see it now is like if we stick a "post-it" in the values with a text written in it... "this value needs to be managed with high precission in all artimetic calculations", and there are 4 together, im going to make a list with a short description, it looks like this, right ?

0x0E = ??? ADDSUB Accurate range opcode
0x0F = FPU MULDIVADDSUB Accurate range
0x10 = COP2 MULDIV Accurate range
0x11 = VPO ADDSUB Accurate range opcode

kozarovv said:
Cons of their (pcsx2) solution is that some rare games require negative rounding here, and positive there, and for rest of games chop/zero is fine. For example that Kuon fix on pcsx2 can potentially break other things in game.
On PS3/PS4 we have no issue with that. But.. We need to know correct offsets for those calculations. So is harder to find patch, but it is better patch as it won't brake other stuff. Good example of game having issue like that on pcsx2 is GT4, they need to CLAMP calculation of floats to make game work, but license require different mode where they also clamp operands. That break game, and you need to change it by yourself. While on ps3, or ps4 we just patch correct offsets with accurate math, done.

Also command 0x08 sometimes relate to VU rounding or clamping on pcsx2, good example is Tony Hawk 4+ , and Castlevania COD. But 0x08 is overall VU patch, and fact that sony used it to correct some values is why sometimes it fit for this theory. :D
Click to expand...
Yeah, the sony "way of doing it" is better, and i guess there must be some comands in ps2_netemu.self related with the roundings,, just because rounding values is something that could come in handy, they was aware of it

Maybe are the others located next (0x12 and 0x13), is just being only 2 doesnt allows to apply different roundings ("nearest", "up" or "down"), it looks there is no room to indicate the type or rounding... dunno...
 
Last edited:
It's interesting how games that utilize double buffer v-sync, like Burnout 3/Revenge, ESPN NBA/NFL games, Tony Hawk games for example, still run "full speed" by dropping to the 30fps buffer on netemu while they run poorly on pcsx2 and not "full speed" and keep using the 60fps buffer. It seems that pcsx2 is dependent on 1:1 emulation and netemu is saying something more like "I am a real ps2, so run how you want on me".

Any reason for this? I'm not too knowledgeable about how emulators work, but I assume it's because Sony has the complete documentation of the PS2 and can code something to act like that and utilize tricks.
 
Btw, did you try this ?
This is supposed to increase the ADDSUB accuracy of a single value (32 bits lenght) located at 0x104124 (of unkown area)
We dont know if that area is FPU memory... but incase it works it means is FPU :)

Kuon (NTSC-U)
Code: 
3D 00 00 00 57 44 00 00 0E 00 00 00 24 41 10 00
00 00 00 00
 
Last edited:
PS3 functions supported by PS4 emulator with internal names:

0x01 = EE_ADD_HOOK addr=%x func-id=%d
0x09 = EE INSN REPLACE64 0x%x : %s => %s
0x0A = EE INSN REPLACE32 0x%x : %s => %s
0x0B = MECHA_SET_PATCH : sec=%d offset=%d size=%d
0x10 = MULDIV Accurate [%x - %x]
0x26 = FPU Accurate range : %x - %x
0x27 = VU0 macromode accurate range : %x - %x
0x42 = No name given, but error description reveal little bit: Invalid overlay address area, ea=0x%06x count=%d error is thrown when one of args (ea of ee memory i think) is below 0xFF000 or above 0xFFFFF
0x4C = Not really sure that is read, and used, no name given.

Also i will grab some interesting info, but not now. It seems that all unsupported commands have info how long command with parameter should be, so we can double check our current findings.

Also 0x0E, and 0x0F are confirmed to be accurate math flavours, just don't remember it was fpu only, add/sub only etc. Long time since i looked into that.

sandungas said:
Btw, did you try this ?
This is supposed to increase the ADDSUB accuracy of a single value (32 bits lenght) located at 0x104124 (of unkown area)
We dont know if that area is FPU memory... but incase it works it means is FPU :)

Kuon (NTSC-U)
Code: 
3D 00 00 00 57 44 00 00 0E 00 00 00 24 41 10 00
00 00 00 00
Click to expand...
vsubx.w vf7, vf0, vf7x so VU macrocode (COP2) substrat. So is most likely not only FPU related, or... Which we never take in count. It is FPU only related, but produce good result also for COP2. Can be also overal ADD/SUB accuracy, since next command 0x10 is overall MUL/DIV.

I don't remember exactly, but 0x0E was exactly the same ad 0x0F but just without range. Use offset instead.
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top