PS3 Compatibility List - PS2 on PS3

already did that long time ago,flashed various 4.83,4.82,4.81 various cfw's basically anything patched for noBD that i could find.
 
I am running out of options here for troubleshooting.

You patched a NoBD Firmware, which means your BD Logic board its broken.

My Rebug it's a regular one, without the BD patch, my logic board still works.

But it shouldn't play it on the Net_Emu, its quite strange.

Sent from my G8341 using Tapatalk
 
i'm not saying it's on netemu,i'm saying it's on cobra,and i can't find what cobra files/mode are,and asking how to be sure it's on gxemu...

and i don't think noBD patch affects ps2 iso's,but obviosly as a noob i really don't know.all i know all was good before accidentally forcing softemu via rebug toolbox.
 
umart666 said:
i'm not saying it's on netemu,i'm saying it's on cobra,and i can't find what cobra files/mode are,and asking how to be sure it's on gxemu...

and i don't think noBD patch affects ps2 iso's,but obviosly as a noob i really don't know.all i know all was good before accidentally forcing softemu via rebug toolbox.
Click to expand...
Run a PS2 game and press the PS Button, if the Screen its transpartent, you are running Net_Emu, if pitch black its the GX_Emu, another indication its the Temp Display, GX_Emu doesn´t support it, Net_Emu does!
 
umart666 said:
then it's not gxemu?isn't cobra a netemu derivative?
Click to expand...
Basically, cobra works as a proxy that passes the info needed to mount the game to the PS2 emulators
And the PS2 emulators are the official files (ps2_emu.self, ps2_gxemu.self, ps2_softemu.self, or ps2_netemu.self)

If you are curious about which emulator files you have... copy them from dev_flash ---> to PC ... and check MD5
Then extract the contents of the firmware PUP (same version you have installed) and compare the MD5 of that files



--------------
The "extended" rebug toolbox (easy to recognize because is bigger than 2mb) contains the PS2 emulator .self files
But is intended to simplify that writing process, is not really needed because you can replace the emu .self files manually with a filemanager or ftp
 
is there any way to completely clean ps3 and start from scratch?and last full toolbox is 2.02.12 which is for 4.81.2 rebug (if installed on later rebug it doesn't display cobra and ps2emu settings) and when toggled to 'original' emu files iso's just goes to black screen,no matter how and with what manager (tested with webman,multiman,managunz and irisman).
 
A normal firmware installation should replace the emulator files, have you tryed to reinstall ?

But the first thing i would do is this:
sandungas said:
If you are curious about which emulator files you have... copy them from dev_flash ---> to PC ... and check MD5
Then extract the contents of the firmware PUP (same version you have installed) and compare the MD5 of that files
Click to expand...


*Bonus
Some weeks ago there was a guy here in the forum reporting black screens when booting PS2 games, the problem was he had a damaged hdd sector (or several) exactly in the position of the ps2_netemu.self file (so the emulator file was corrupted)
But a firmware reinstallation solved it, because when you install a firmware the hdd finds the damaged sector and "remaps" it
This "damaged sector remap" is a function of hdd bios, modern hdds have around 2000 "reserved" sectors or so (ready to be remapped)
This means the limit of hdd sectors that can be damaged (and remapped) is 2000... after that point is not posible to remap them, so the damaged sector stays there forever

Edit:
Forget about the "bonus" info, lol, this doesnt applyes to you because your PS3 have NAND flash, where full firmware is installed in NAND chips soldered in the motherboard

Edit2:
sandungas said:
If you are curious about which emulator files you have... copy them from dev_flash ---> to PC ... and check MD5
Click to expand...
Or you can enter managunz filemanager, browse to the folder where is located the emulator .self, then press square to "checkmark" the file, then triangle to show a floating window with options, then "check MD5"
This is easyer imo, and as far i remember that MD5 check was working fine the last time i was testing it
 
Last edited:
Naked_Snake1995 said:
Yakuza also freezes on a CECHC04 60Gb with PS2_GXEmu, on Ch.3 and Ch.10, but it can be bypassed if you eject the disc and reinsert it, people reported the same on the PS2_NetEmu, but no disc bypass, since its an internal image, Yakuza 2 its far a more stable experience.

Yakuza Kiwami its also available for PS3, but only in Japanese, unless you play it on the PS4, still trying to beat Jingu on Legend.
Click to expand...
Hello Thanks for answer!
 
kozarovv said:
Yes this is EE memory offset for precise math. I'm sure, this command was in first config i ever ported (Rygar).


I not messed with this command too much, but it looks like VU (not COP2, my bad) memory offset for precise math, or multiply by 0 hack (but CELL should be able to mul0).


Like i said earlier, this command is related to Memory card. And emulator split u64 value into two u32 values, first is left shifted by 32bits, second is used as is.


I need help.
Click to expand...
What kind of help?
 
Disregard my comment about Wizardry. Managunz' config feature seems to crash any game I apply a config to. Applying the config downloaded straight from the Github seemed to fix it.
 
  • Like
Reactions: Zar
mrjaredbeta said:
Disregard my comment about Wizardry. Managunz' config feature seems to crash any game I apply a config to. Applying the config downloaded straight from the Github seemed to fix it.
Click to expand...
Fyi @Zar
----------------------------------------------------------------------------------------
Fun fact for today:

Today i messed with PS2 emu because i'm looking solution for something. This pointed me to 0x01 command from ps2_netemu. Next step was analyze some of configs from GX, and then i found this: https://github.com/Zarh/Get_CONFIG/blob/7aab2cedf28564af8351220689940cfb780eea98/log.txt#L10350

Like you can see param is 800017E8 and 80001858. Param for 0x01 should be EE memory offset. But EE have access to 0x0 - 0x1FFFFFFF, because that's how EE memory is mapped. So I thought that is some issue with @Zar script to extract configs. So i did it manual way, and found exactly the same result in ps2_gxemu. So there is no issue with extracting. Ok, so what is going on here? Is kind of epic mistake. This config is for PS1 game, yes emu will try to apply it by ID to PS2 version of game. But someone made mistake, and put there offsets for PS1 game. :D 0x8000XXXX addresses are valid for PSX mapping. Is hard to believe that something like this happened, but it is. This make me curious about ps1_netemu possibilities. ;)
 
Zar said:
Also, I was reading the ps1emu page in psdevwiki, the config file is limited... to not say useless.
Click to expand...
Actually offset 0x14-0x1C can be useful. We don't know what it is.
Zar said:
Do you know what are the hardcoded flags ? http://www.psdevwiki.com/ps3/PS1_Emulation#Game_settings
Click to expand...
No, but it looks similar to Xparam2 flags from PS2 bios.
Zar said:
So, this config is probably not working. I'll remove it from the collection.
Click to expand...
Yeah, there is no chance that config work. No idea how it stayed in firmware so long.
 
kozarovv said:
Today i messed with PS2 emu because i'm looking solution for something. This pointed me to 0x01 command from ps2_netemu. Next step was analyze some of configs from GX, and then i found this: https://github.com/Zarh/Get_CONFIG/blob/7aab2cedf28564af8351220689940cfb780eea98/log.txt#L10350

Like you can see param is 800017E8 and 80001858. Param for 0x01 should be EE memory offset. But EE have access to 0x0 - 0x1FFFFFFF, because that's how EE memory is mapped. So I thought that is some issue with @Zar script to extract configs. So i did it manual way, and found exactly the same result in ps2_gxemu. So there is no issue with extracting. Ok, so what is going on here? Is kind of epic mistake. This config is for PS1 game, yes emu will try to apply it by ID to PS2 version of game. But someone made mistake, and put there offsets for PS1 game. :D 0x8000XXXX addresses are valid for PSX mapping. Is hard to believe that something like this happened, but it is. This make me curious about ps1_netemu possibilities. ;)
Click to expand...
I agree that looks weird to use that offset not matching with the EE memory map, and i agree that this is something important, it means they was trying to make changes in the memory map of a PS1 game
But i would not label it as a "mistake" so soon... sometimes they does weird things and that game is a bit special, i was looking at it now
https://wiki.pcsx2.net/FIFA_Soccer_World_Championship
https://en.wikipedia.org/wiki/FIFA_(video_game_series)
FIFA Soccer World Championship (FIFAサッカー ワールドチャンピオンシップ)
Released only in Japan on May 25, 2000, this PlayStation 2 exclusive, a prototype of FIFA 2001, was the first installment of the series on a 6th generation video game console.
Click to expand...
It was exclusive for PS2, and it was used as a prototype for a new game engine
I mean... this game never was released in PS1, at least with that name... the real name of the game for PS1 was "FIFA 2001"

What im saying doesnt proves anything, but it adds a bit more mistery to what happened with the emulators and that game configs. Actually this confusion of names maybe was the reason why they did a "mistake"... but as youself mentioned it... is very rare for a mistake like that to survive so many time without anyone realizing
 
Last edited:
Btw about PS1 configs, imo the most important thing we are missing is how to deal with PS1 multidisc games
The PS3 firmware have nice features for this, and a menu (when you press PS button) to change disc, but this is enabled by the config, and we dont have config so... game over we dont have the multidisc selector features in custom firmware :'(

Im going to explain how i think it works, just incase someone was experimenting with this and could throw some light about it
The PS1 config files are composed of "data blocks", every block is identifyed by a name string, and contains some data "slots"
p3HmVw3.jpg

In this example in wiki it can be seen how the "data blocks" are delimited by the table rows colored in grey
Basically, in this example are used 2 "data blocks", the first one is named PS1EmuConfigFile (lets say is unknown), and the second is named disc_no
Additionally, if you look at the decrypted emulator .elf it looks that it allows for another "data block" named user_memory_size
In short, we know for sure there are 2 "data_blocks" allowed by the emulator and maybe are 3, but sadly we dont have more examples of this PS1 config files

The disc_no (or disc number) is what we need to use for multidisc support, so someone have tryed to create a config with only this "data block" ? (i mean... only this one, but not the PS1EmuConfigFile that is completly unknown)

Maybe when you use the disc selector menu (by pressing PS button), the emulator updates the value located at offset 0x34 in this config example in wiki, then reloads the config and the game... this is just speculation, i have not tested it

If this works then we have the multidisc support working... a different matter is how to implement the generation of this config files for every app (incase of managunz the app itself could create them)
Im guessing in one of the (again) unknown arguments needed to be passed to the emulator at the time you boot the game... one of them should be the location of the config file
In other words... one of this "unknown" arguments could be the location of the config
mZR1YRe.jpg


My deduction to think this is because look at the other arguments passed to the emulator, there is one that tells where is located the emulator .self. Dont you think this is extremelly redundant ?... the location of the .self is obvious but they passes it with an argument anyway (redundancy ftw)
My point is... if they passess an argument with something so obvious like the emulator location... then i think other of the arguments should be the location of the config
Not only because is important to know where is the config, but because maybe there was some point (at development and debuging stages) where they was loading PS1 configs from alternative paths (like USB, or even network)
 
Last edited:
  • Like
Reactions: Zar
hello someone from here will know why the program ps2classic gui stopped packing the pic0 or pic1, I have the last 3 vertions and the same thing happens with all of them including with the original files of the program , before this happened to me, if someone could help me.
 
Hello. Could someone try creating config to Ghost in the Shell Stand Alone Complex for PS3 Emu? It hangs on first door also there is some fps drops but it in playable limits. There is one for PS4. Maybe it could be converted or something?
 
You must log in or register to reply here.

Similar threads

Back
Top