PS3 Compatibility List - PS2 on PS3

mrjaredbeta said:
Ha, okay it's fixed. It makes saving noticeable slower...maybe its a type of delay to let it finish scanning the memory card and data? And I see this is using the same command and setting as Jak X...I remember that game having some problems with saving on slim ps2s or something, so it makes sense that it has something to do with this, too.

Anyways, thanks a bunch! @sandungas and I having being going crazy over this lol. The only issue left is the menu FMV, but idk if there is even commands to help with FMV decoding/playing.

Here's what we got so far:
Code: 
3D 00 00 00 57 44 00 00 0A 00 00 00 05 00 00 00
28 5F 66 00 01 01 01 01 00 00 01 01 30 5F 66 00
41 70 00 00 00 00 00 00 3C 5F 66 00 41 A0 00 00
00 00 00 00 80 53 13 00 A8 BA 60 AC A8 BA 43 AC
13 00 00 00 00 00 00 00 60 F9 00 00 00 00 00 00
Still a little skeptical about the car detail codes. I may just get rid of them.
Click to expand...
Command 0x13 fixed the save problems ?, damn i was about to suggest it yesterday (but i said so many things before that i thought it was going to be a bit excesive)

The reason i was about to suggest it is because netemu command 0x13 is used in the configs for burnout dominator embedded inside ps2_gxemu.self :)
https://github.com/Zarh/Get_CONFIG/blob/master/log.txt

But... is using a different value than the one you used in your latest config
You are using 0xF960 (from jak x, right?)
Burnout dominator uses 0x9BDC

So... i suggest you to make one more test using the value from burnout dominator in the command 0x13


---------------------------
Just as a recap (i was taking a look at this yesterday), we have all this values confirmed as valid for netemu command 0x13
Code: 
0x9bdc, 0xf960, 0x1d394
Or in decimal...
Code: 
39900, 63840, 119700

That numbers doesnt looks random, they are following some math rule because some are in proportoion to others, as example:
39900 * 3 = 119700 :rolleyes: (one of the values is the triple of other of the values)

While thinking in this i tryed to see his Greatest Common Factor (GCF) ---> https://www.calculatorsoup.com/calculators/math/gcf.php
7980 * 05 = 39900 (bingo)
7980 * 08 = 63840 (bingo)
7980 * 15 = 119700 (bingo)

So.... it looks we can "generate" other valid values for netemu command 0x13 by multiplying 7980 * X :rolleyes:
 
Using pcsx2 and doing some research into the B3 menu video bug...it looks like the videos are handled in the memory range 0x51A850-0x51A9DC. There is data on how it is decoding/handling the video. Since the video bug happens at the loop point, I suspect an address is changed but never changed back, or an address is changed and causes another address to become bugged.

The byte at 0x51A8BB seems to control the loop (if 1, it loops. if 0, video stops at the end/loop point). The byte right after, 0x51A8BC, is set at 0 until the loop point, it switches to 1 and starts the loop and switches back to 0. However, if you switch this value to 1 when it is not supposed to be, it completely bugs the video similarly to the way it is on netemu. I am thinking maybe netemu switches this value to 1 and forgets to switch it off, leaving a bugged and glitch repetitive video. Maybe there's more to it, but I am sure these are affecting it in some way.

Doing more research...

EDIT: Additionally, using Burnout Dominator's value with 0x13 causes a BSOD on boot.
 
Last edited:
mrjaredbeta said:
Using pcsx2 and doing some research into the B3 menu video bug...it looks like the videos are handled in the memory range 0x51A850-0x51A9DC. There is data on how it is decoding/handling the video. Since the video bug happens at the loop point, I suspect an address is changed but never changed back, or an address is changed and causes another address to become bugged.

The byte at 0x51A8BB seems to control the loop (if 1, it loops. if 0, video stops at the end/loop point). The byte right after, 0x51A8BC, is set at 0 until the loop point, it switches to 1 and starts the loop and switches back to 0. However, if you switch this value to 1 when it is not supposed to be, it completely bugs the video similarly to the way it is on netemu. I am thinking maybe netemu switches this value to 1 and forgets to switch it off, leaving a bugged and glitch repetitive video. Maybe there's more to it, but I am sure these are affecting it in some way.

Doing more research...
Click to expand...
Thats EE memory range ?
Im asking because the config from burnot 2 point of impact inside gxemu/softemu are using command 0x01 to "hook EE memory address to function ID 0x19"
And function ID 0x19 doesnt needs any valued passed to it... so the only thing we need to know is the EE address
 
sandungas said:
Command 0x13 fixed the save problems ?, damn i was about to suggest it yesterday (but i said so many things before that i thought it was going to be a bit excesive)

The reason i was about to suggest it is because netemu command 0x13 is used in the configs for burnout dominator embedded inside ps2_gxemu.self :)
https://github.com/Zarh/Get_CONFIG/blob/master/log.txt

But... is using a different value than the one you used in your latest config
You are using 0xF960 (from jak x, right?)
Burnout dominator uses 0x9BDC

So... i suggest you to make one more test using the value from burnout dominator in the command 0x13


---------------------------
Just as a recap (i was taking a look at this yesterday), we have all this values confirmed as valid for netemu command 0x13
Code: 
0x9bdc, 0xf960, 0x1d394
Or in decimal...
Code: 
39900, 63840, 119700

That numbers doesnt looks random, they are following some math rule because some are in proportoion to others, as example:
39900 * 3 = 119700 :rolleyes: (one of the values is the triple of other of the values)

While thinking in this i tryed to see his Greatest Common Factor (GCF) ---> https://www.calculatorsoup.com/calculators/math/gcf.php
7980 * 05 = 39900 (bingo)
7980 * 08 = 63840 (bingo)
7980 * 15 = 119700 (bingo)

So.... it looks we can "generate" other valid values for netemu command 0x13 by multiplying 7980 * X :rolleyes:
Click to expand...
This command is timing related, i can't figure out initial value because i hate PPC (PPC hate me too..). But value set by CMD 0x13 is used in loop that move some value from time base register, and compare it with one from 0x13 (after some additional math). Looping since value from tbr match what code want there. I don't really want to go deeper there. But 0x13 is for sure Memory Card related timing command. Value can be anything nanoseconds, cycles, who knows.
 
@sandungas Yes, EE memory range. First off, I found I can replicate the error in pcsx2 by messing with EE address 0x51A938. This causes the video to do an infinite loop but with a pause that also affects how the menu moves (there's a lag to it when it is looping).

However, this is just one of many errors that can appear on netemu. All of them contain infinite loops, however one contains bugged video graphics and one doesn't. This second one is the one I was able to recreate. Messing with a whole bunch of values in this range can cause garbled video graphics so it could really be any of them and it's hard to pinpoint.
 
mrjaredbeta said:
@sandungas Yes, EE memory range. First off, I found I can replicate the error in pcsx2 by messing with EE address 0x51A938. This causes the video to do an infinite loop but with a pause that also affects how the menu moves (there's a lag to it when it is looping).

However, this is just one of many errors that can appear on netemu. All of them contain infinite loops, however one contains bugged video graphics and one doesn't. This second one is the one I was able to recreate. Messing with a whole bunch of values in this range can cause garbled video graphics so it could really be any of them and it's hard to pinpoint.
Click to expand...
Do it sony way :D Remove video at all, like they did in burnout 2 config.
 
kozarovv said:
Do it sony way :D Remove video at all, like they did in burnout 2 config.
Click to expand...
I'm not sure I understand. Burnout 2 doesn't have any FMV menu...it seems to be real graphics rendered by the PS2, and the 0x01 config doesn't affect it. Unless you're referring to something else?
 
kozarovv said:
This command is timing related, i can't figure out initial value because i hate PPC (PPC hate me too..). But value set by CMD 0x13 is used in loop that move some value from time base register, and compare it with one from 0x13 (after some additional math). Looping since value from tbr match what code want there. I don't really want to go deeper there. But 0x13 is for sure Memory Card related timing command. Value can be anything nanoseconds, cycles, who knows.
Click to expand...
And BaudRate ?
Im going to quote part of my previous post because what im going to say is a bit related with it... maybe are just coincidences, but smells a bit fishy
sandungas said:
Just as a recap (i was taking a look at this yesterday), we have all this values confirmed as valid for netemu command 0x13
Code: 
0x9bdc, 0xf960, 0x1d394
Or in decimal...
Code: 
39900, 63840, 119700

That numbers doesnt looks random, they are following some math rule because some are in proportoion to others, as example:
39900 * 3 = 119700 :rolleyes: (one of the values is the triple of other of the values)
Click to expand...
The valid values we have in decimal (39900, 63840, 119700) makes me remember a bit at the standard baudrate settings for serial communications with jtag, spi, etc... is just the values are not exactly the same, but well, the PS2 memory card could be using whatever they wanted because doesnt needs to follow standards
But they looks a bit similar in the way how the values increases, also are proportional too, let me show you another example, this ones are the valid values we have
Code: 
39900, 63840, 119700
39900 * 3 = 119700 :rolleyes:

And this ones are 3 consecutive standard baudrate values www.ece.northwestern.edu/local-apps/matlabhelp/techdoc/matlab_external/baudrate.html
Code: 
38400, 57600, 115200
38400 * 3 = 115200 :rolleyes:
 
Last edited:
mrjaredbeta said:
@sandungas Yeah, something like that. I have to press power button to return to XMB, and the virtual PS2 card is also ejected as well.
Click to expand...
Well, in some way thats a good detail because is like a confirmation that we was doing something wrong when trying to access the virtual memory card
I dont get why the save problem in burnout 3 is fixed by using the value of command 0x13 from jak X (instead of the value of command 0x13 from burnout dominator)
The common sense told me that the value from dominator it was going to work better because it seems the last burnouts (since 3 up to 5) probably are the same game engine
But dunno, until we find what means that values i guess there is not going to be answers to that mistery :D

At this point there is no need to make more test for the save problem of burnout 3 (im not talking about it to ask you for more test, is just chilling and curiosity sake), you mentioned that now with the fix from jak x is saving a bit more slower than before... but maybe this is the normal speed, what do you think about this ?
Maybe you was used to the previous save speed (with the problem) that was excesivelly fast and now you feel it very slow :D
 
Could be, but I think if any config is wrong or abnormal it always ejects the memory card. But yeah, it could be normal speed now. It's been a while since I tried this on PS2 so I can't really say what the "normal" speed is for sure.

I'm not having any luck with this video bug...I think I might call it quits. Giving me way too much of a headache for something so unobtrusive.
 
lex3a said:
I got my PS3 and can confirm this. Intro video has problems, the video is flickering and the sound is stuttering
Click to expand...
kozarovv said:
I have no idea what is causing that Ape Escape 2 issue, as far as i'm aware this is just Video not even rendered scene. Sorry but i can't help with this as i have no way to reproduce it.
Click to expand...
THX u guys.
I'll play EU version instead.
I dont like EU,bcz sometimes EU just 50Hz
 
mrjaredbeta said:
I'm not sure I understand. Burnout 2 doesn't have any FMV menu...it seems to be real graphics rendered by the PS2, and the 0x01 config doesn't affect it. Unless you're referring to something else?
Click to expand...
I think Kozarovv was referring to my earlier post about Burnout 2.

E P said:
This patch below prevents the game from loading the gameplay demo at the title screen.
Code: 
  [GX] Command ID : 0x09
  [Net] Command ID : 0x0B
  Data Offset : 00344090
  Data Number : 00000001
  Sector : 00000531
  Offset : 000005DC
  Size : 00000008
  Patched data offset : 0x51C5E0
  Patched data : 0800E00300000000
  Original data offset : 0x51C5D8
  Original data : E0FFBD2790898727
Click to expand...

Nice work on all Burnout 3: Takedown SLUS-21050 fixes everyone. I played around with the game back in early 2019 when Aero_ had some widescreen patches. Unfortunately I couldn't get any of those wide screen patches to work while using the following extracted netemu CONFIG below:
Code: 
00000000 3D 00 00 00 57 3D 00 00 21 00 00 00 00 00 00 00
00000010 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020 53 4C 55 53 2D 32 31 30 35 30
I've used that config quite a bit and never seemed to have issues with memory cards while using it. At the time, I couldn't figure out what exactly those two commands in that config file effected. Burnout 3 simply refuses to work when type 0x0A and/or type 0x0B command patches are added to it. So it's still somewhat a mystery.
 
E P said:
Code: 
3D 00 00 00 57 3D 00 00 21 00 00 00 00 00 00 00
0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
53 4C 55 53 2D 32 31 30 35 30
Click to expand...
This one is based in the official configs from inside gxemu self, it does the same for all regions:
Code: 
Title : Burnout 3 - Takedown
Game ID : SLUS_210.50
Commands count : 0x2
	[Net] Command ID : 0x21
		Param : 00000000
	[Net] Command ID : 0x0C
		Param 1 : 0000
		Param 2 : 0000

Title : Burnout 3 - Takedown
Game ID : SLES_525.84
Commands count : 0x2
	[Net] Command ID : 0x21
		Param : 00000000
	[Net] Command ID : 0x0C
		Param 1 : 0000
		Param 2 : 0000

Title : Burnout 3 - Takedown
Game ID : SLES_525.85
Commands count : 0x2
	[Net] Command ID : 0x21
		Param : 00000000
	[Net] Command ID : 0x0C
		Param 1 : 0000
		Param 2 : 0000

The same configs exists inside softemu self, with the same commands, and additionally the command 0x05... but command 0x05 doesnt exists in netemu ! (this is why your config doesnt have command 0x05)
And at the end of the config is used command 0x00 that allows to add the TITLE_ID of the game





EDIT:
I just noticed your config seems to be wrong, i guess it was created by an old version of the "get_config" tool made by zar with some problem in the 0x0C command, or it was created manually. The correct conversion to netemu format looks like this:
Code: 
3D 00 00 00 57 44 00 00 21 00 00 00 00 00 00 00
0C 00 00 00 00 00 00 00 00 00 00 00 53 4C 55 53
2D 32 31 30 35 30

The actual version of the "get_config" tool converts it correctly, can be downloaded from this link ---> https://github.com/Zarh/Get_CONFIG/blob/master/files/SLUS_210.50.CONFIG
 
Last edited:
sandungas said:
The same configs exists inside softemu self, with the same commands, and additionally the command 0x05... but command 0x05 doesnt exists in netemu ! (this is why your config doesnt have command 0x05)
And at the end of the config is used command 0x00 that allows to add the TITLE_ID of the game
Click to expand...
Yes. If memory serves, type 0x05 commands don't exist in my config files because either most of us already knew this from reading this thread, or that the other software emu that lists those commands hadn't been extracted yet. The initial info started within these forums and was organized and posted to the wiki. You know like that table we were all obsessed with populating at the time. During that same period, I did a lot of CONFIG's by-hand back in November of 2017. While everyone was digging through that decrypted log file, Zar was in the process of creating a more prudent way of extracting the individual configs. I know you don't need a history lesson, but I've been around these parts for a while just not posting very often.:) It's truly amazing what such a collective effort has achieved in such short order and what's still left to be uncovered.

sandungas said:
EDIT:
I just noticed your config seems to be wrong, i guess it was created by an old version of the "get_config" tool made by zar with some problem in the 0x0C command, or it was created manually. The correct conversion to netemu format looks like this:
Code: 
3D 00 00 00 57 44 00 00 21 00 00 00 00 00 00 00
0C 00 00 00 00 00 00 00 00 00 00 00 53 4C 55 53
2D 32 31 30 35 30

The actual version of the "get_config" tool converts it correctly, can be downloaded from this link ---> https://github.com/Zarh/Get_CONFIG/blob/master/files/SLUS_210.50.CONFIG
Click to expand...
Good eye.:) I created that file back on November 20th of 2017 (42 bytes). I also have a download of Zar's version saved from back on November 22 of 2017(42bytes). The files do match, but I can now see that Zar's was updated in December of 2017 (38bytes). So the two parameters for 0x0C command fits within four hexadecimal bytes. Thanks for pointing this out.
 
Hello can anyone send me ps2bootparam.dat file? Is located in /tmp/game/ps2bootparam.dat
Before sending it here, please eventually mask your wlan_ssid that is on offset 0x32, and wlan_password that is on offset 0x54 of file.
Just change it in HxD to FFFFFFF.

There is no more personal data included as far as i'm aware. Maybe username somewhere, easy to check.
Can be in PM if you prefer to not post it here.
 
You must log in or register to reply here.

Similar threads

Back
Top