PS3 Compatibility List - PS2 on PS3

Last edited:
Zar said:
@sandungas Did you make a table of CONFIG file extracted from gxemu ? I can't see them in the wiki
Click to expand...
Hmm, you mean if i did a section in the wiki page specific for the config files extracted successfully from gxemu ?
If thats the question then no, there was a list of custom config time ago in the page, initially was hand made (using the ps2 classics to learn), most/all of them was made by mysis kozarovv and others, but at the time we started extracting config from gxemu some successfull ones was added with them
Some days ago i reordered the page and moved them under a "unofficial" section (there is other for officials taken from ps2 classics)
http://www.psdevwiki.com/ps3/PS2_Emulation#Unofficial

But after that point all we have been rushing a bit, im not keeping a record of the good ones, some has not been added to wiki, neither updated the other page for the compatibility list
There have been some messages in this thread where was posted 20 or more configs together (because was used by several games), and things like that, so we have a good mess

Im guessing you was thinking in getting copies for managunz, so sorry... i think chicco33 was collecting them... and i thought at some point someone will make an extractor/converter to extract the 788 configs from gxemu with a click of a mouse
There are some commands that are not going to be posible to extract/convert automatically, but are just a few
 
sandungas said:
I thought at some point someone will make an extractor/converter to extract the 788 configs from gxemu with a click of a mouse
There are some commands that are not going to be posible to extract/convert automatically, but are just a few
Click to expand...

challenge accepted.

I wanted to help by extracting some of them but not if it was already done (even if it's not working yet like TimeSplitter 2).

But I agree, it's better to make exe to do that ^^'
 
lex3a said:
Here is another CONFIG:

Metal Gear Solid 3: Subsistence Disc 1 (SLUS-21359 4cb14de1a5) Fixes crash after intro sequence.
Code: 
00000000 3D 00 00 00 57 3D 00 00 12 00 00 00 07 00 00 00 =...W=..........
00000010 00 00 00 00 00 00 00 00 01 00 04 00 10 00 D7 0D ................
00000020 49 00 5F 0D 08 00 E7 0D 59 00 EB 0D 15 00 00 00 I._.....Y.......
00000030 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Click to expand...

Works for both mgs3 and mgs3s, thank you. Onimusha config works too, but the game can be played without any config.


Btw, today, 13 years ago mgs3 was released in US, funny coincidence :)
 
Last edited:
lex3a said:
Although, it is strange. Textures look very pixelated, but atleast I can see them now
Click to expand...
Keep in mind that in some VERY RARE situations command can make game work different, but not 100% correctly. If you feel there is some noticeable difference comparing to ps2, maybe is worth to try untested yet sub commands. I just try to said that can sub-command in config can be still bad, but good enough to make some change.
nifengyuexia said:
Thank you for your reply, my version is NTSC-J, can I help test the NTSC-J game?
Click to expand...
Sure. But only SLPM-74232 version:
Code: 
3D 00 00 00 57 3D 00 00  01 00 00 00 94 08 3C 00
2C 00 00 00 00 00 00 00
Zar said:
challenge accepted.
Click to expand...
! :D

@sandungas 4.41 4.21 .4.75 - 4.81 offsets for 0x00 command seems to be the same, but I need to extract them and make byte to byte compare.
 
I think there is mistale in the devwiki for the command 0x9 of Dark cloud, I check in the iso.

0x09 change at
EE offset 0x138EB0
ELF offset 0x38FB0​
Original 1 : 20 00 BF 7F
Original 2 : B0 FF BD 27
Original data = B0 FF BD 27 20 00 BF 7F (It's the value I found in the iso. So, it's already in BIG endian, no need to swap)​
Patched 1 : 00 00 00 00
Patched 2 : 08 00 E0 03
Original data = 08 00 E0 03 00 00 00 00 ​
​
 
If value is in ISO then is little endian ;)

For example in this case:

B0 FF BD 27 is

addiu $sp, -0x50

not

sdl $ra, -0x42D9($a3)

like it will be if this is Big endian
 
Last edited:
Meh i'm confused, i don't understand the 'raw language'. Anyway, I mean the u32 stored in CONFIG and in the ISO are the same. in the psdevwiki it's swapped :

Code: 
0x09 => 1,
 0x138EB0 ,
   0x7FBF0020 (sq    ra,0x20(sp)),
   0x27BDFFB0 (addiu    sp,-0x50),
   0x00000000 (nop),
   0x03E00008 (jr ra)


By the way, the command 0x15 of gxemu is the command 0x17 of netemu (it's used in Bully). So, the command Gx 0x14 must be 0x16.
 
Zar said:
Meh i'm confused, i don't understand the 'raw language'. Anyway, I mean the u32 stored in CONFIG and in the ISO are the same. in the psdevwiki it's swapped :

Code: 
0x09 => 1,
 0x138EB0 ,
   0x7FBF0020 (sq    ra,0x20(sp)),
   0x27BDFFB0 (addiu    sp,-0x50),
   0x00000000 (nop),
   0x03E00008 (jr ra)
Click to expand...

Is because PS2 procesor is little endian. If you want write 01234567 then you need to write 67452301 because ee readit byte reversed, but if you want to read it as human. Correct value will be 01234567. So in raw config you use 67452301, but if you want to read it and interpret manually by yourself it will be 01234567. And that's what is wrote on devwiki in most right tab of config table, human readable form.

Here is small converter that can help understand it: https://www.eg.bucknell.edu/~csci320/mips_web/
It can't resolve endianess so you need byte reverse manually. You can see there if you doing it good.
PS. Is not dedicated to Emotion Engine, so some instructions can differ, but not so much to not see is correct endianess.


Zar said:
By the way, the command 0x15 of gxemu is the command 0x17 of netemu (it's used in Bully). So, the command Gx 0x14 must be 0x16.
Click to expand...
99% yes, but is better to confirm it in some game.
 
Now when I read my previous post I'm not sure is so "noob friendly" as I though :D

First you need to realize that functions in iso are also in little endian, so if iso have aa bb cc dd it will be dd cc bb aa for real. Emotion engine will read it backward. Right tab in config descriptions is just reversed to state how ps2 will see it after read, and conversion.

Edit: If you look at other config there are all the same. You also can be confused due to ps3 gx emu where this 'human readable' form is used instead of little endian.
 
Last edited:
Zar said:
challenge accepted.
Click to expand...
Zar said:
My first results = https://github.com/Zarh/Get_CONFIG/blob/master/log.txt

the ouput is in txt and in big endian to debug it faster, it will be easier to add the output in CONFIG files once it's finished.

Also, it didn't write the code to manage every command ID with 'expanded data' exepted the command ID 0x9 ( Net = 0xB ).

Do not hesitated to tell me if you see some weird stuff :p
Click to expand...
Great, if you do some important change, please generate another log.txt i think im going to be lurking it a lot in the next days to compare data, if i find some weird thing i will advise

My first suggestion is to output the info in the same order than inside gxemu, is very useful when looking at hexeditor because usually when you are looking at an specific area you can see the area that is inmediatlly after (for other game), this is useful becaue sometimes there are several games consecutivelly that stores data at the same offsets (so are sharing config), other times you are looking at a command and there is a different command after it for other game that you find interesting (but lookig at that position of hexeditor you dont know which game is the next one)... just because we know the command IDs is posible to read different commands from different games consecutivelly, as an overview rushing a bit, i dont expect much people to do this because is easy to lost the track but i been doing it sometimes, one of the list posted by mysis was ordered well (the one that starts with SLUS-21268), and the other list is not

Another suggestion is to add a option to extract data as "raw" (no endianesss swap). And to add to the output the preceding zeroes of all the fields (to know how long was the "slot" to store that value), both suggestions are for verification purposes only, i guess this will not be needed later when the whole structure will be mapped, but by now could be handy

I was taking some notes of the gxemu structure, but using the concept of "data storage" containers... in code this should be structs, and the commands could share that structs
I noticed for the second level of gxemu structure there are around 10 different "data storage" containers only, i guess you got the ones i got and more thought but when looking at your code it seems you did in a different way

I like it a lot anyway, good initiative :)

Zar said:
I think there is mistale in the devwiki for the command 0x9 of Dark cloud, I check in the iso.

0x09 change at
EE offset 0x138EB0
ELF offset 0x38FB0​
Original 1 : 20 00 BF 7F
Original 2 : B0 FF BD 27
Original data = B0 FF BD 27 20 00 BF 7F (It's the value I found in the iso. So, it's already in BIG endian, no need to swap)​
Patched 1 : 00 00 00 00
Patched 2 : 08 00 E0 03
Patched data = 08 00 E0 03 00 00 00 00 ​
​
Click to expand...
Took me some time because im not used to netemu command 0x9 but i got it, you mean the explain at right of the config is wrong
Well... this is something whoever that posted that in wiki should take a look, but my guess is you are right because you are comparing the data at the ISO and what is posted in wiki at right of the config is intended to be in big endian always, most closer to human readable (just incase you want to copypaste it to go to that offset in IDA/hexeditor, or to do some calculations with the calculator), but is not

In this case the data in the config is the value of an area that is going to be patched, and the patch that is going to be applyed to it, both uses the same endianess, and there is no need to change endianess to make it more "human readable" because is just a chunk of data, so i guess you are right, not sure if im confusing myself with all this endianess swaps back and forth

Btw, in gxemu as far i know... everything is stored as big endian... i have no idea if this command is an expection but i dont think... my guess is what happens with the game configs hardcoded inside gxemu is are readed by the CELL processor at some point this is why everything is in big endian... and in netemu the config files are readed by the virtualized EE processor this is why the values needs to be swapped
The only expection to this rule seems to be the values stored by netemu command 0x0 (where it tells the SCUS-12345)... this should be for CELL too (so that value is loaded before the virtualized EE)

Dunno, im just mentioning it because by comparing the endianess used to store the values gxemu VS netemu it can give some hints
 
Last edited:
vaan said:
Btw, today, 13 years ago mgs3 was released in US, funny coincidence :)
Click to expand...
The other day happened the same with the .hack game configs that was posted in this thread the same day that was released the "remastered" edition for PS4, funny :D
 
sandungas said:
Btw, in gxemu as far i know... everything is stored as big endian... i have no idea if this command is an expection but i dont think... my guess is what happens with the game configs hardcoded inside gxemu is are readed by the CELL processor at some point this is why everything is in big endian... and in netemu the config files are readed by the virtualized EE processor this is why the values needs to be swapped
The only expection to this rule seems to be the values stored by netemu command 0x0 (where it tells the SCUS-12345)... this should be for CELL too (so that value is loaded before the virtualized EE)
Click to expand...
I think the same here. Looks like config is applied on other emulation stages in ps2_netemu, and other emus.
Also I just want to mention that config posted for Dark cloud came from PS2 classic PKG. In ps2_gxemu its byte reversed like in right tab on devwiki, which is how to correctly read it.
 
this is instead the problem of silent hill 2 I mentioned earlier,
this ghost leg problem comes also from a retrocompatible PS3 60gb (PAL)


[minute (4.03),(5,23),(5,56),(6,02)]


I hope someone can fix it one day :smug:
As I said Silent Hill HD Collection is brought from a beta code of 2 and 3, full of bugs and horrible changes
I do not recommend playing this HD Collection from anyone
 
@Maxout65 the videos posted in this thread are very handy for other people that doesnt have the game to get an accurate example of the problem, but i guess with this one is going to be hard because seems to happen too much randomly, and well, only affects a leg of the character, lol, thats weird

Edit: hmmm, im thinking maybe is related with some item that appears on the character leg when equipped ? (a handgun, or something like that consisting in some polygonal object "sticked" to the waist), try to equip and unequip items doing zoom at that area to see if something changes

kozarovv said:
I think the same here. Looks like config is applied on other emulation stages in ps2_netemu, and other emus.
Also I just want to mention that config posted for Dark cloud came from PS2 classic PKG. In ps2_gxemu its byte reversed like in right tab on devwiki, which is how to correctly read it.
Click to expand...
Thats a good explain in a short sentence of the endianess differences :)

With dark cloud i guess he means the endianess should not be chaged at the explain at right for the "patch" values (both original and new data) because this is exactly what you are going to see in the ISO
For the other values of the command (like the one that tells the offset where the patch is going to be applyed)... sure that one needs to be swapped for the explain

This applyes only to the explain... so i guess is a matter of concepts of how the cells at the right of that table in wiki are used, is like an style mysis started using but i dont know if there are differences when showing that info in the right cells for other games using same command
 
Last edited:
I try to help users understand the issue through video, since it's the simplest is to save valuable time :)

I know it's just a leg and some body limb to disappear, but it's really bad to see
This is one of the best Survival Horror ever created, this ghost problem ruins everything :(

I know it is very complicated to solve,
but I hope someone will one day find a solution ...... many users would be grateful to him

I wanted to thank all of you for the time you spend solving PS2 games
Thank you :encouragement:
 
SLPM-74232 (test passing) fixes the texture problem
Code:
3D 00 00 00 57 3D 00 00 01 00 00 00 94 08 3C 00
2C 00 00 00 00 00 00 00

SLPM-66275 (waiting for the test), because I'm from China, and I have time difference, sorry.
 
You must log in or register to reply here.

Similar threads

Back
Top