PS3 Compatibility List - PS2 on PS3

Im looking at netemu 0x08 output in the https://github.com/Zarh/Get_CONFIG/blob/master/log.txt
In your web browser... ctrl+f... and search for: "NetEMU ID : 0x08"
Then press F3 key repeatedlly in your keyboard for a fast overview of all them

It looks like what i imagined (just because is next to the others), works in the same way than netemu 0x09 and 0x0A, the differences are:
0x08 = Patch EE memory with 4 opcodes
0x09 = Patch EE memory with 2 opcodes
0x0A = Patch EE memory with 1 opcode

In 0x8 the "new data" appears in the first 4 opcodes.... and after them the 4 opcodes of "original data"
Note in some games how the first 3 opcodes for the "new data" have the same value... than the first 3 opcodes of the "original data"... is because are only patching the last opcode of the group of 4

In some of them is not like this though (they patches more data, so there are more changes when comparing them)... but the point is for this ones im saying is obvious 3/4 of the data is used as a "search pattern" (or for verification purposes) and is not going to be modifyed



Edit:
Additionally, if you look at the command data in a hexeditor you are going to notice there is not any place that indicates the length of that "patch data" (for both original and new)... so is a fixed length
Is a chunk of 0x20 bytes everytime the command is used

Edit2:
Also... look at where they stores the data, there are a lot of games using this command... but only stores the data at a few locations:
0x3229C0
0x3229E0
0x322A00
0x322A20
0x322A40
0x322A60
0x322A80
0x322AA0

0x322F88

There are only that few locations, but a looooot of games using the data on that locations, this cant be a coincidence, the same data is applyed to lot of games made by different game companies with different game engines, etc...
So is patching something that is "generic"
 
Last edited:
kozarovv said:
I think you are wrong here.
Click to expand...
I just said EE to say something... but it could be any other thing instead of EE memory

Look this one from SLUS-20607 Disney's Extreme Skate Adventure (and a lot of the tony hawk's too)
Here is patching a single byte... or half a byte to be more precise... but the command uses a lot more data... is overkill, heheh
Code: 
	NetEMU ID : 0x08
		Data Offset : 0x322A40
			Param 1 : 0x80000000
			Param 2 : 0xFFFFFFFF
			Param 3 : 0x80000000
			Param 4 : 0x53400000
			Param 5 : 0x80000000
			Param 6 : 0xFFFFFFFF
			Param 7 : 0x80000000
			Param 8 : 0xD3400000

Or this one, here can be seen better, from SLUS-21727 Naruto - Ultimate Ninja 3, other narutos, and some of the .hack// games
Here is patching 2 bytes
Code: 
NetEMU ID : 0x08
		Data Offset : 0x322A60
			Param 1 : 0xFFFFFFFF
			Param 2 : 0xFFFFFFFF
			Param 3 : 0x01E0A740
			Param 4 : 0x8000033C
			Param 5 : 0xFFFFFFFF
			Param 6 : 0xFFFFFFFF
			Param 7 : 0x01E0A740
			Param 8 : 0x80001EFC
 
Last edited:
kozarovv said:
I think that you are wrong with idea it patch 4 opcodes. I never found any "original data" when looked at games it fix. Vide thps series.
Click to expand...
It can be other stuff, maybe is patching the emulator itself and not the game
Lets deal by now with...
0x08 = Patch something with 4 opcodes
0x09 = Patch EE memory with 2 opcodes
0x0A = Patch EE memory with 1 opcode

The bigger difference i see with 0x09 and 0x0B is in them is needed to tell additionall info about the patch such offset/sector/size
But after that you have the same in 0x08... half the data is like a "find pattern" and the other half is the "replace pattern"... 0x10 bytes each
 
Last edited:
Look at all them together

Stored at offset: 0x3229C0
Pattern 1 = 0xFFFFFFFFFFFFFFFF000002FF003E604E
Pattern 2 = 0xFFFFFFFFFFFFFFFF01C039D0003E604E

Stored at offset: 0x3229E0
Pattern 1 = 0xFFFFFFFFFFFFFFFF81E1344B46FA0000
Pattern 2 = 0xFFFFFFFFFFFFFFFF81E1344B43A00000

Stored at offset: 0x322A00
Pattern 1 = 0xFFFFFFFFFFFFFFFF01C62968500B07FB
Pattern 2 = 0xFFFFFFFFFFFFFFFF01C62968500B07FA

Stored at offset: 0x322A20
Pattern 1 = 0x80000000FFFFFFFF80000000FFFF8000
Pattern 2 = 0x80000000FFFFFFFF80000000FFFF8001

Stored at offset: 0x322A40
Pattern 1 = 0x80000000FFFFFFFF8000000053400000
Pattern 2 = 0x80000000FFFFFFFF80000000D3400000

Stored at offset: 0x322A60
Pattern 1 = 0xFFFFFFFFFFFFFFFF01E0A7408000033C
Pattern 2 = 0xFFFFFFFFFFFFFFFF01E0A74080001EFC

Stored at offset: 0x322A80
Pattern 1 = 0xFFFFFFFFFFFFFFFF0111948D80000EFC
Pattern 2 = 0xFFFFFFFFFFFFFFFF0111948D10030203

Stored at offset: 0x322AA0
Pattern 1 = 0xFFFFFFFFFFFFFFFF8040D6A54B000000
Pattern 2 = 0xFFFFFFFFFFFFFFFF8040D6A54B000001

Stored at offset: 0x322F88
Pattern 1 = 0x00000000FE000000000000002C000000
Pattern 2 = 0x00000000FE0000000000000010000000
 
kozarovv said:
Hmm I need to make dump of GS memory for some of those games. At first look is from gs ram part.
Click to expand...
Hope the last list i made helps, but really looks like "find and replace" patterns, the amount of bytes that matches in between what i called "pattern 1" and "pattern 2" is huge, i dont think this is a coincidence because it happens in all them

The minimalistic record are the ones stored at 0x322A20.... this one seems to be patching only 1 bit, lol
But to patch 1 bit is using a command that deals with 0x10 bytes legth "patterns", this is overkill and uneficient, there must be a good reason for that
I guess is because this is the only command able to patch that "something area"... or in other words, the area patched cant be the "EE memory" because to patch "EE memory" is better to use command 0x09 that deals with much smaller "patterns", this would be more efficient, but they are not doing this... so is not patching the same area than command 0x09

Btw... if you try to search where appears this "patterns", realize i just copypasted them in the same order that appears inside gxemu... i have not made any endianess swap or reordering of the opcodes because i have no idea if is needed
It was just a dirty way to show all them together
 
Last edited:
sandungas said:
Btw... if you try to search where appears this "patterns", realize i just copypasted them in the same order that appears inside gxemu... i have not made any endianess swap or reordering of the opcodes because i have no idea if is needed
It was just a dirty way to show all them together
Click to expand...
I search then earlier, not right now. In both endianess. I'm 80% sure is GS memory patch, but I can't test it now.
 
Ok I managed to recreate thps u2 bug in pcsx2, and take gs dump.

Strings found then inside dump:

8000000053400000
80000000D3400000

String not found:

80000000FFFFFFFF

Now let me test with correct game settings.

Same result. I'm close, but I have no idea what is first part of config:

80000000FFFFFFFF

Edit:

hmm... This look like kind of "mask" with some additional settings. Only non zero bytes seems to be changed.
Here are snaps of gs if anyone else is interested. You can look at jpg to realize which dump is with bug, and which is not:
https://www.mediafire.com/file/d7n1poyak1yeplx/snaps.zip

Edit 2: Mask seems to be similar in usage to some cheat devices for ps2 where for example F is apply all the time, E only on some condition, etc. But still is unknown what is what in mask. But for sure it is mask.

Edit 3" Also mask seems to keep kind of search pattern if needed, like in 80000000FFFFFFFF case.

So is something like:

If 80000000D3400000 found replace with 80000000FFFFFFFF where FFFFFFFF is something unknown or other part of patch, so 53400000 in this case.
 
Last edited:
kozarovv said:
I think that problem is in function "shGetJamesFootPos", but I can't resolve it :(
Or maybe is problem with "james_anim_set"
Click to expand...

there is no hurry,
do everything in tranquillity and especially when you have time to devote, solve all the really problematic PS2 games before :)

over time somebody will probably understand the problem
it would be great to play this title on Upscaled PS3
without ghost problems :)
 
GS patching with mask and patterns, pretty cool, keep the good work :)

---------------------------------------
There is an small mistery with gxemu 0x15 (netemu 0x17), and affects your code @Zar not sure if you made on purpose though but take a review of it
Im calling it a "mistery" because is not a big problem, is just about endianess, but is indicating something that goes out of the standards, or we have an error related with this

This is how the data is stored inside gxemu, for game bully SLUS-21269
Code: 
0051DCA0  00 00 00 15 00 00 00 00 01 00 00 00 00 00 00 00  ................
0051DCB0  00 00 00 00 00 00 00 00                          ........
We have been considering all data inside gxemu is in big endian, right ? (or at least this is what i been thinking)... so the value stored is 0x01000000

To convert it to a config file for netemu is needed to swap endianess, right ?... well, with this one is not like that, see this example of an official PS2 classics posted in wiki for the game bully NPUD21269
Code: 
00000000  3D 00 00 00 89 3D 00 00  17 00 00 00 01 00 00 00 =....=..........
00000010  00 00 00 00 53 4C 55 53  2D 32 31 32 36 39       ....SLUS-21269
The value used here is going to be endian swapped by the virtualized EE (like other commands), right ?... so the value here is 0x1
And this is an official config, so is right and has been tested, there is also another example in wiki of this command used in a config file for the game SLUS-20983 Musashi: Samurai Legend and is doing the same

So.... i can imagine only 3 posible reasons for this:
-the value inside gxemu is not in big endian (i would not bet on this one)
-the value is not endian swapped by the virtualized EE (i would not bet on this one either)
-the value is composed by 4 * uint8_t (this is my winner horse !!!)

In wiki it tells is an uint32_t... but i think it happens the same than with the others netemu commands 0x1C, 0x1D, 0x1E... (check them in wiki) where it says... read uint32_t (use uint8_t)
Initially the value is managed as uint32_t... but at some point is "cropped" in 4 single bytes... and from them the emulator only takes the first byte
This is why the 01 byte appears most at left when you look at gxemu, in other words, i think it needs to be displayed like this by your app @Zar
Code: 
	Command ID : 0x15
	NetEMU ID : 0x17
		Param 1 : 0x01
		Param 2 : 0x00
		Param 3 : 0x00
		Param 4 : 0x00

--------------
Another couple of details @Zar again not sure if you made on purpose but i will mention them anyway:
NetEMU ID : 0x22 (gxemu 0x1F) <-------- is outputing data (always lot of zeroes), but this one seems to be a "switch", so doesnt stores any data
And so... you can just output the string "Nothing to do" like with the other switches

"Hash Offset :" <-------- the output needs to be substracted 0x10000
This is not an error, but imo is better to substract the 0x10000 because the other offsets that appears on the log.txt follows this rule... all them are "offsets relative to an area" (and that area starts at 0x10000)
With this one you are showing the "absolute offset" (from start of file)
To standarize all them (using same rules) is needed to change this one by substracting the 0x10000 from it
But as i said, this cant be considered a mistake, i been thinking maybe you made it on purpose, so is ok anyway, no big problem
 
Last edited:
nice found about the commandID 0x17, lol I read it several time i didn't notice the value wasn't 1, lol.

It's fixed : https://github.com/Zarh/Get_CONFIG/blob/master/log.txt

And it make me think that PERHAPS the command ID 0x20 (which is making the game timeplitter 2 to freeze the system) is not working because of something similar ? I supposed it was a uint64_t because it wrote in devwiki. But it could be a 2 uint32_t and the first value is always equal to 0 ? Or it can't be possible ? what do u think ? (I'm going to try ;) )
 
Who can help me in testing games if I'm create some config from Zar's list and post them here?
And a question: what about those configs where I found "TODO" command?
 
chicco33 said:
Who can help me in testing games if I'm create some config from Zar's list and post them here?
And a question: what about those configs where I found "TODO" command?
Click to expand...

my bad I didn't sync my local project to the github, 2 updates were missing in github lol. Anyway, now it's up to date. There isn't any TODO command but only unknown :p
 
Zar said:
my bad I didn't sync my local project to the github, 2 updates were missing in github lol. Anyway, now it's up to date. There isn't any TODO command but only unknown :p
Click to expand...

Thanks Zar, its ok now. I will start to make configs from the top of the log to the end and if someone help me in testing I will add the tested and workin configs to our common google drive storage.

@Zar:off topic, but I will send you a hungarian translation for ManaGunZ tomorrow :)
 
  • Like
Reactions: Zar
You must log in or register to reply here.

Similar threads

Back
Top