PS3 Compatibility List - PS2 on PS3

Problem is that i don't have that file, i'm only basing my knowledge on emu memory dump :/
And cobra i guess ?, take a look at the comments at lines 2515 and 2696
https://github.com/Joonie86/COBRA-7.3/blob/master/486/LITE/stage2/storage_ext.c

So cobra patches (or the way how cobra parses the info from ps2bootparam to netemu) could be breaking something related with the emulated PS2 peripherals ?
I guess there is one way to bypass all that cobra management... by booting the game in "PS2 classics" format (installed as a PKG)
 
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.
I did remember your nick when i saw you talking about burnout yesterday, but with the few posts you have i was not sure why i did remember you, is nice you was around that days joining the party :)

Let me try to complete the story a bit (in relationship with burnout too as far i remember)
At some point kozarovv found a table inside an emulator .self (not sure if it was gxemu or softemu first) where there was data that was looking like configs... but the way how is stored the data is not so straightforward, the data for a single config is like "spreaded" at lot of different positions of the table, like ordered in 3 "hierarchy levels", there was also other problem because the TITLE_ID of each config was missing (instead of it the table stores some kind of CRC32 hash for it)
At some point we was confident the data in the table was configs (and there was hundreds of configs, it was like a rosetta stone)
At some point mysis published the code needed to recover the TITLE_ID's... and from that point we had a list of which game was the owner of each config

And... we wents a bit mad with it, kozarovv reversed most of the table structure, zar and me helped him a bit (i even wrote a tutorial about how to extract the configs manually, but never published it)
And we started converting some configs to netemu format... but it was very tricky because it was needed to move back and forth to different offsets lot of times in a hexeditor just to create a config, with the configs that was using only 2 levels of the hierarchy it was relativelly easy (but the configs using 3 levels of the heirarchy was a complete pain)

So we started guinea pigging some simple configs, from the list of game names (the ones we found more interesting)
At some point we extracted the configs for burnout 3 manually and was very confusing because all them are unknown commands and all them was filled with zeroes, this is still a mistery, this is why i posted the info about them in my previous post, is nice you mentioned it

The weird thing is the best config we have for burnout 3 (made by mrjaredbeta) is very different than the officials, it makes me wonder if it would be better to merge them, but are unknown commands and the config from mrjaredbeta doesnt seems to need them so is a bit pointless, also the weird detail about the memory card is making this more confusing, lol

-------------------
The story continued with the table i made in wiki talk page when we was trying to see how the command ID's changes for gxemu, softemu, and netemu, this was tricky and required a lot of speculation and intuition (this is when we realized there was some configs using commands that doesnt exists in netemu, like netemu command 0x05)
And some weeks later we stopped extracting configs manually from gxemu and softemu when zar made the "get_config" tool
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.
Im not sure right now what happened with that config, but i can imagine it... the problem is the command 0x0C seems to use 2 parameters of 16bits each (this is a bit unusual, at that point we thought all parameters was 32bits). So... we was adding excesive zeroes to the command 0x0C

Later we realized there are other commands using parameters of 8bits (and there is even a couple using 64bits, this is specially weird because i guess the PS2 cant handle values that long)
Is just it seems the emulator code "splits" (or joins) some of the command parameters before passing them to the emulated PS2
 
Last edited:
And cobra i guess ?, take a look at the comments at lines 2515 and 2696
https://github.com/Joonie86/COBRA-7.3/blob/master/486/LITE/stage2/storage_ext.c

So cobra patches (or the way how cobra parses the info from ps2bootparam to netemu) could be breaking something related with the emulated PS2 peripherals ?
I guess there is one way to bypass all that cobra management... by booting the game in "PS2 classics" format (installed as a PKG)
Nah, i have 2 dumps that are most likely done without cobra. I remember i checked that, and there were no usual cobra patches in memory. At least in one from 2015y
Also looks like mysis added some more info to page i created on wiki, so i think my offsets in emu for that file are fine. Since he followed the same "pattern".

(and there is even one using 64bits, this is specially weird because i guess the PS2 cant handle values that long)
There are more commands that use 64bits ;) But.. Only few commands hit real PS2 code (0x08/9/A, etc.). And finally, PS2 is mix of 128/64/32 bit, so it would be no issue to for example set some 64bit value that way ;)
 
Can someone test this config? Scarface US - SLUS-21111
PLEASE don't get exited, is not a fix yet. I just need to know there is any speed difference or no to make next attempt.
There will be minor glitch around character, i'm aware of that.

Code:
3d 00 00 00 11 11 00 00 0a 00 00 00 02 00 00 00
40 2f 64 00 C0 FF BD 27 08 00 E0 03 44 2f 64 00
80 00 02 3C 00 00 00 00 00 00 00 00

Edit: There is also option that will break loading of most graphic (it will be bad sign for us btw.. Then i also need to know that game is faster or no).

Oh Boy
I want to test it , but i have NO iday of what i have to do to specifically check the Config File & games
dont forget that im on CFW PS3 (Cobra Rebug 4.86.1 lite)
its just that im used to use config file already "ready" in files and place them inside my hdd games folder.

like this :
https://www.psx-place.com/resources/ps2-config-database.796/

ohh lol i see its your work :)
 
With all this coding discussion that's way over my head it sounds like you guys are on the way to 100% compatibility for PS2 games on PS3.



Kidding of course. :)
 
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.

Out of curiosity, could you try cmd 0x19 regarding the memory card?
 
Isn't that pad/analog related? I know it set something very close to VMC, but is seems to be PAD related. Still, worth to try.

indeed ye, i looked a bit into pcsx2 and noticed that too it could be pad related, not VMC...idk :smile: this SIO2 could mean anything...maybe its pad reset or so.
 
Can someone test this config? Scarface US - SLUS-21111
PLEASE don't get exited, is not a fix yet. I just need to know there is any speed difference or no to make next attempt.
There will be minor glitch around character, i'm aware of that.

Code:
3d 00 00 00 11 11 00 00 0a 00 00 00 02 00 00 00
40 2f 64 00 C0 FF BD 27 08 00 E0 03 44 2f 64 00
80 00 02 3C 00 00 00 00 00 00 00 00

Edit: There is also option that will break loading of most graphic (it will be bad sign for us btw.. Then i also need to know that game is faster or no).

I don't know, maybe a little difference in speed. The most difference in speed can be seen when the guy in violet shirt appears on the screen.

 
I don't know, maybe a little difference in speed. The most difference in speed can be seen when the guy in violet shirt appears on the screen.

Thank you for test. This is actually really good news for us. In config above i removed loading of shader that is cause of bad speed on pcsx2 (infamous I bit hack). So if emu is still slow, this mean PS3 issue is different. Most likely can be fixed. Now i need to create config that remove most possible effects, and someone need to test it then. Maybe is similar case to RawDanger.
 
I did remember your nick when i saw you talking about burnout yesterday, but with the few posts you have i was not sure why i did remember you, is nice you was around that days joining the party :)
Completely understandable. I'm more well known around the psx-scene, which is apparently still down. When Rebug firmware first got support for CONFIG files, I was trying to study the samples ex: Contra and Gradius V, but there was so little information at the time. After I had seen some some heavy digging being done here, I figured I would eventually have to become a member at some point. The config tutorial by kozarovv really helped a lot.https://www.psx-place.com/threads/w-i-p-configs-for-ps2_netemu-explained.15034/

Nice synopsis of of how the story unfolded. I vaguely remember finding the fix for Onimusha 2 via trial and error before a clear cut way was found. It was fun.

The weird thing is the best config we have for burnout 3 (made by mrjaredbeta) is very different than the officials, it makes me wonder if it would be better to merge them, but are unknown commands and the config from mrjaredbeta doesnt seems to need them so is a bit pointless, also the weird detail about the memory card is making this more confusing, lol
In regards to Burnout 3, I still feel like I have some unfinished business. Last year I had seen and collected all sorts of info about Burnout 3, Burnout Revenge, and Burnout Dominator. Generic wide screen hacks, which were not included in the pcsx2's widescreen database as well as a few of those speed hacks. Some PS2 games, such as those three, do have native widescreen support when you change the screen setting within the PS2 screen menu. The game will detect the setting and adjust accordingly. Of course, I haven't figured out if that is really possible on the PS3. Maybe a generic universal BIOS setting cheat code?

Anyway, since I have all but the first Burnout game for the PS2, I had planned on doing some tests on the PS3 to see if there might be some benefit. I'm very pleased to see that those speed hacks, put together by mrjaredbeta, did make a difference.:)

As far as merging, that's were things went wrong for me last year. The type 0x0A or 0x0B commands refused to work with the de-facto config. Utilizing both Command 0x21 and 0x0C together was the culprit. I had take either one or the other out of the config file in order for Command 0x0A patches to work. Otherwise while attempting to launch Burnout 3, the PS2 Boot Logo would not appear and the TV just says no signal. Then I'm forced to have to hold the PS3 power button for a few seconds, listen for the beep, and inevitably wait for the system to escape back to the PS3's main menu screen. After all that, one has to plug-in the PS3 controller to resync the controller do to the dirty escape from the PS2 emulator. Oh and finally reassign the virtual memory cards.

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.
Oh, I did notice the current WIP Burnout 3, SLUS-21050, config is malformed. Type 0x0A code should be set to four instances since it contains four memory address patches not five.

I'd go with this
Code:
 00000000  3D 00 00 00 57 44 00 00 0A 00 00 00 04 00 00 00
 00000010  28 5F 66 00 01 01 01 01 00 00 01 01 30 5F 66 00
 00000020  41 70 00 00 00 00 00 00 3C 5F 66 00 41 A0 00 00
 00000030  00 00 00 00 80 53 13 00 A8 BA 60 AC A8 BA 43 AC
 00000040  13 00 00 00 00 00 00 00 60 F9 00 00 00 00 00 00

or this for 0x21 command as the other more than likely MC fix
Code:
 00000000  3D 00 00 00 57 44 00 00 0A 00 00 00 04 00 00 00
 00000010  28 5F 66 00 01 01 01 01 00 00 01 01 30 5F 66 00
 00000020  41 70 00 00 00 00 00 00 3C 5F 66 00 41 A0 00 00
 00000030  00 00 00 00 80 53 13 00 A8 BA 60 AC A8 BA 43 AC
 00000040  21 00 00 00 00 00 00 00 00 00 00 00

I pretty sure that the 0x21 command contain the memory card fix. Whether or not the MC fix requires the additional 0x0C command has yet to be completely determined. Only while testing other custom config settings, did I experience issues with memory card reading, ex: the game telling me on load that its game save file was corrupted, but this only occurred while I temporarily abandoned the de-facto "SLUS_210.50.CONFIG" file. In other words, testing without using 0x21 or the 0x13 command, so more testing may still be needed to see if command 0x21 can work alone, but so far so good here.
 
Im looking at this collection and there are widescreen patches for burnout takedown (3), revenge (4), and dominator (5)
But there are no widescreen patches for the original burnoout (1), and point of impact (2)
https://forums.pcsx2.net/Thread-PCSX2-Widescreen-Game-Patches?pid=271674#pid271674
All that collection of widescreen patches is included in managunz btw, could be converted to the config format, but alternativelly you can use managunz to apply them

Btw, regarding the tests you made with command 0x0C keep in mind we was adding 4 more zeroes that was not really needed, at the point the emulator reads that zeroes it thinks is the command 0x00 (config terminator), so it stops reading the config file
With this i mean... incase you had other commands after the (incorrect) 0x0C then i guess the emulator was ignoring them

And yeah, now you mentioned i realized about it, there was a mistake in the last burnout 3 config (in the 0x0A command the counter with a 5 needs to be replaced by a 4), damn this game is driving us crazy :D
Im wondering if this problem could have a similar effect than what i mentioned above... the emulator expects to find 5 codes... but there are only 4... so whatever other command you add after 0x0A is going to be "broken" because is going to be taken as the fifth code for 0x0A
Im wondering if this is what happened in the last tests made by mrjaredbeta (when i suggested him to try with 0x0C and 0x21), maybe the config was "broken" after the 0x0A
 
Last edited:
...and im wondering if the order of the commands could change the results, the theory is... some commands could be used at a "preboot" stage (before the virtual PS2 boots), and other commands are "postboot"

Just to mention a couple... the commands discussed in the last posts that could be related with the memory card could be "preboot", but others, like patching the EE memory with command 0x0A looks like "postboot" because the memory is only populated when the game is loaded
Another example, the command 0x0B to patch the ISO looks like "preboot", because the emulator can apply the patch to the ISO before loading the game

In few words, when messing around with the commands that seems to be related with the memory card try to locate them af first position, just incase
 
@E P @sandungas Haha yeahhh, I tend to make some mistakes with the configs here and there. In actuality, netemu just BSODs if there are more instances of 0x0A stated than there are in the config. I quickly figured that out and changed it without reposting the new config. Also, the official configs seem to do nothing, and I have played through the entirety of 3 now with my current config and no extraneous problems have surfaced.

Regarding the widescreen, all Burnout games have native widescreen from BIOS settings. Setting PS2 upscaler to "off" in XMB settings will boot the games that have BIOS widescreen settings to their widescreen format. You'll be stuck at 480P output though. I assume booting as fullscreen will do the same, but I haven't tested it!

I found that Burnout Revenge has the same menu video problem as 3. It is a little less apparent though, and it actually seems to break out of the loop and correct itself after a while. This menu video bug is really getting to me and I can't stop thinking about it...I haven't been at my PS3 the past couple of days, but gonna try and test the SIO2 command you mentioned soon as well as see if that bug is fixable.
 
Even though I have them all on my 360 due to having a steering wheel for it I love that you guys are taking an interest in the Burnouts. I remember the first time I saw Burnout 3 at a kiosk at Best Buy I thought it looked absolutely amazing never seen anything like it. It is a shame that EA destroyed Criterion, and everything else they touch.
 

Similar threads

Back
Top