PS3 Compatibility List - PS2 on PS3

However i am thinking about getting a decr in hope it could help with netemu (easier debug output and debugging possibilty) and psp and gameplay recording, or shall i rather try getting a dech ?
If I recall correctly @Joonie had problems to run ps2_netemu at all on DECR. He fixed this later by using DEX vsh. Not sure that you can get there any output easier than on DECH. But I can be completely wrong, I never had DECH or DECR.
 
If I recall correctly @Joonie had problems to run ps2_netemu at all on DECR. He fixed this later by using DEX vsh. Not sure that you can get there any output easier than on DECH. But I can be completely wrong, I never had DECH or DECR.

I think the issue was with encrypted isos, but he got it running using isos directly and possibly also by using dex vsh as you say.
DECR at least the 1000 with CP can get lv1 debug output. my thought is to abuse that and redirect netemu stuff to it if possible
 
Sounds promising. :)

@chicco33 iirc is your list: https://drive.google.com/file/d/0B8nnKJxkoLVLY1ZMOFNjcWhaRTg/view
Right?

You mentioned there that Fast & Furious game is freezing at start. Can you confirm this?
My SLUS_214.49 seems to work fine, have minor issues, but work.
MD5 of ISO: 0B69B4D6925A7CE99EE8E73BD1721D34

No :) We have a console community and this is our list: CLICK
Based on your "configs-for-ps2_netemu-explained" guide I try to create custom config files for games like Tri Ace games, Tales of Abyss, Yakuza1, Dragon Quest5, Suffering series, Dot Hack series, Dawn of Mana, etc etc.
But if you need I can look at Fast and Furious game tomorrow.
 
No :) We have a console community and this is our list: CLICK
Lengyel, magyar – két jó barát, együtt harcol, s issza borát ;)

Ok so this was probably list posted by @vaan
Right @vaan ?

Edit:

But if you need I can look at Fast and Furious game tomorrow.

Actually it would be cool if you can test this game, as I'm using custom netemu. I STRONGLY doubt that my emu have different compatibility excluding usb devices, but is good to test on standard emu.
 
Last edited:
Added config for Rumble Racing to devwiki. Is rather unique because I ported it from ps2_emu to ps2_netemu. Next game to fix that way: Disney's Treasure Planet

Thanks to @mysis for finding original patches in ps2_emu, and for resolving hash/name for those games.
 
kozarovv I have a long time doubt it is possible to run ps2 games on ps3 by external hd, it would be very practical, since I use the OPL Loader from my ps2 fat 39001, and I already have about 400 games on the external hd, so it would make it much easier to run on ps3 straight through it. A big hug.
 
Last edited by a moderator:
kozarovv I have a long time doubt it is possible to run ps2 games on ps3 by external hd, it would be very practical, since I use the OPL Loader from my ps2 fat 39001, and I already have about 400 games on the external hd, so it would make it much easier to run on ps3 straight through it. A big hug.

I believe @mysis said that it would take a modification of lv1 to enable ps2 games from an external hdd, but it may be more trouble than it's worth.
 
Last edited by a moderator:
And added config for Disney's Treasure Planet. Weirdest one I ever saw.. But it work.
Weird fixes gives extra bonus :)

I was reading your wiki edits and your messages here and thinking in that offset "displacement" (incase it can be called like that). There are other examples of command 0x0B where it happens that ?




Edit: never mind, i wrote some rambling here about calculators... but i was wrong, i confused the offsets with the sector count
 
Last edited:
Weird fixes gives extra bonus :)

I was reading your wiki edits and your messages here and thinking in that offset "displacement" (incase it can be called like that). There are other examples of command 0x0B where it happens that ?




Edit: never mind, i wrote some rambling here about calculators... but i was wrong, i confused the offsets with the sector count
For Rumble Racing offset of patch is pointing right to original opcode:

Nowy obraz mapy bitowej.jpg

Nowy obraz mapy bitowej (2).jpg


But for Disney's Teasure Planet patch is not hit right place of original opcode

Nowy obraz mapy bitowej (3).jpg

Nowy obraz mapy bitowej (4).jpg


Is very weird for me, why not point to 574? Or why not patch 580 with original opcode that is really there (
02 00 41 14 00 00 00 00 0D 00 06 00 12 10 00 00
00 00 00 00 00 00 00 00
)?

Just $ony things ;)

Edit: Only difference that I found between those games is that RR is a CD game, and DTA is DVD game. I need to check later other 0x0B to find out it matter.
 
Last edited:
Good explain, thx
One of the things i did learn from it is the offset is actually a sector_offset (relative to the start of the sector)... in other words the position where the sector starts is considered offset 0x00 and the sector_offset is a displacement from that position (just some feedback if someone wants to improve the info related with this command in wiki or in your thread because this is something i did not get before)

A part of what i wrote in the previous message (and later deleted) is sometimes there are things that looks weird initially and breaks the standards, but uses to be a good reason for doing it that way
And now after reading your explain with the examples and understanding where is the problem im thinking the same, probably sony has a strong argument about why is needed to do it that way... but i cant imagine why
The only thing i imagine could be happenning is the program you are using is having some problem to "chop" the data in sectors
 
Last edited:
And now after reading your explain with the examples and understanding where is the problem im thinking the same, probably sony has a strong argument about why is needed to do it that way... but i cant imagine why
The only thing i imagine could be happenning is the program you are using is having some problem to "chop" the data in sectors
Actually someone (@mysis ? ) decribed 0x0B with this: offset on disc = sector id * sector size + offset (-0xC) on devwiki. So this damn -12 bytes are known thing. So here config for RR where offset seems right look weirdest comparing to others.

Only reference to anything related to 12 bytes (0xC) in classic algorithm is here: http://www.ps3hax.net/showthread.php?t=53444

After building ISO.BIN.ENC file you should create a file with the title id and pad it with zero bytes from the right side to get 12 bytes total. Then you need to create an EDAT container for this file. Hint: you can see a correct title id when mounting a disc image on your PC and looking at SYSTEM.CNF of it.

Maybe is something related to that? Maybe that file from EDAT is loaded before ISO which change it offset in "memory"? No idea, anyway looks like CD based games (or more precisely BIN (CD) in 2048 Data1 format) don't need that -0x0C when calculating offset.
 
I believe @mysis said that it would take a modification of lv1 to enable ps2 games from an external hdd, but it may be more trouble than it's worth.

Thanks for the response, would have the link, so I take a look? I sincerely still have not seen advantage, in abandoning my beloved ps2, and playing ps2 through ps3, I have ps2 with the OPL Loader and SMB network, it is undoubtedly a great tranquility. A hug.
 
Actually someone (@mysis ? ) decribed 0x0B with this: offset on disc = sector id * sector size + offset (-0xC) on devwiki. So this damn -12 bytes are known thing. So here config for RR where offset seems right look weirdest comparing to others.

Only reference to anything related to 12 bytes (0xC) in classic algorithm is here: http://www.ps3hax.net/showthread.php?t=53444



Maybe is something related to that? Maybe that file from EDAT is loaded before ISO which change it offset in "memory"? No idea, anyway looks like CD based games (or more precisely BIN (CD) in 2048 Data1 format) don't need that -0x0C when calculating offset.
Yep, i was reading wiki again and jut realized at that line, i was about to paste it here, heheh
It needs to be that for sure, is the same 0xC displacement

Before realizing about this i was thinking it matches with the length of the last 3 infos that are needed to patch an opcode: "sizeof present opcodes" + "replace opcodes" + "original opcodes"
That ones are 4 bytes each... 0xC in total
Probably just a coincidence, i dont think is related and i guess mysis will explain it other day

But if is somethign that only needs to be applyed based on the disc media (CD/DVD) as you are saying then could be a new discovery :)
 
Partial fix for Gran Turismo 3, 4: https://www.reddit.com/r/PS3/commen...s3_ps2_netemu_debug_menu_and_options/doj6o07/

Fix: "flickering problems in some cuircuits or parts of cuicuits, generaly zone with dense buildings, etc."
Side effect: The side effect the fps tends to slowdown game a bit (but nothing to worry about)

But if is somethign that only needs to be applyed based on the disc media (CD/DVD) as you are saying then could be a new discovery :)
Actually even cobra use different patch for DATA1 CD (link), so maybe is related somehow.. Or maybe not :p

Edit: maybe something limg sector related?
 
Last edited:

Similar threads

Back
Top