Possibility on Reviving PS2 Backwards Compatibility?

E

ExperimentalEnthusiast

Forum Noob
Hi, my first time posting here!

I want to ask whether it is possible or not - through HFW, HEN or whatever, to access the repository nodes of the PS3's Lvl 1 Hypervisor where if so, then the file "sys.hw.config#0" determining (via a flag of 1 or 0) could be accessed and modified.

And if it is possible, is it possible to change that flag to 1 (which would therefore state to the XMB when it goes to check the flag that the PS3 is indeed backwards compatible), and install that altered config file onto the PS3 as part of Hybrid Firmware or as a Hybrid Firmware update?

It has me curious to see if this will result in the ps3 thinking itself to be backwards compatible, where it should in theory output "PlayStation 2 Format Disc" when a ps2 disc is inserted.

Furthermore onto what the result might be, I am curious to see when you select 'start' through the XMB; if it will boot into the ps2 logo - proceeding to a likely crash or black screen due to there being no emulated components to do their job.

You may be wondering why even bother? Why should I even be curious about this? Well I'll explain the reasoning behind this curiousity, which in turn may even nab your interest.

The other day, I was experimenting with my Cech-4000 (Super Slim) PS3 regarding it's incompatibility with PS2 games to see how it behaves when I actually pop in a PS2 game disc.

My experiment involved tests of the following:

- Antipiracy
- DVD vs CD Speed
- Recognition as PS2 Media

1. Anti Piracy

I noticed that for any ps2 game disc, once inserted and the tray closed; the PS3 would make that quick 'liquid-wobble' sound (it's the best I can describe it) that occurs in PS2 consoles for a brief period prior to recognising a disc to be a DVD, CD, Data Disc, PS2 game, or PS1 game to the menu.

That quick liquid-wobble sound that briefly occurs is likely the wobble-check of the console in action, given that it goes away once the disc has been verified or not.

Anyway, I wanted to see if the PS3 will come up with 'unsupported software' when you try backup PS2 game discs on it, where if the result differs from genuine Ps2 discs it would suggest that it displays 'unsupported software' in place of 'Playstation 2 Format disc' after the game disc has been verified as genuine; suggesting it's the ps2-behaviour running as normal under a different coat of paint instead of the coat of paint that is 'playstation 2 format disc' on fat ps3s.

So I went on to test this idea, and to my fascination it did not show up with 'unsupported software' (which is also under the GAMES section of the XMB, supporting my coat of paint idea) on the XMB; but instead as 'Data Disc' in the Video and Audio Sections of the XMB - the exact same way as what happens if you try a backup ps1 game or an actual data disc on the ps3.
This seemingly confirms that the Copy Protection for Ps2 games - like that of PS1 games, is actually still intact and working, suggesting that the DMA, Mechacon, and possibly the Operating System of the PS2 is still being emulated, where it is probably piggy-backing off the PS3's Disc wobble hardware, given that like in a real PS2; it blindly verifies all ps2 games instead of verifying by listed titles as is the case with Original Xbox games on the Xbox 360.

2. DVD vs CD Speed

Have you ever popped in a CD-based PS2 game and noticed how fast it spins compared to DVD-based PS2 games, PS1 games, movie DvDs, and music CDs?

In this experiment I inserted a CD-based ps2 game to see how the speed of spinning the disc would compare against DVD-based PS2 games, PS1 games, Music CDs, and Movie Dvds on the Ps3, where upon trying it out, I found that it will only spin CD-based PS2 games at the high speed a real ps2 would spin it at, further suggesting that it is emulating the disc drive behaviour of the ps2.
If you have tried out a CD-based Ps2 game on a PC with PCSX2 not running; the PC will just display it as a data disc without the high spinning speed.

It is only when the emulator is running does the disc start to spin (ensuring that you have execution from disc activated so that IPU emulation is running) at the high speeds that a PS2 will spin them at.

Given that PCSX2 requires IPU emulation to enable the OS of the PlayStation 2 to run discs - in the behaviour of a real PS2 disc drive, from the disc drive of a PC, it is therefore likely that the PS3 is emulating the IPU of the PS2.

3. Recognition as PS2 Discs

Though more of a reasoning than a test, I want to note that when inserting a PS2 disc into the PS3; the XMB will return 'unsupported software' under the games section, where selecting 'Start' (almost like it 'starts up' the message instead of what would be PS2 emulation) displays the message "This model of the PlayStation 3 is not compatible with PlayStation 2 Format Software".

The fact that this occurs under the XMB's Game section suggests that the PS3 recognises the disc as a game; and it is redirecting to a message instead of redirecting into the (non-existent) PS2 virtual machine when starting the 'game'.

Furthermore, it is interesting that it only does this with PS2 discs and only if those discs are genuine copies.

Hence it makes it likely that the PS3 really does recognise PS2 game discs; and in fact, it may very well be that the disc drive emulation of the PS2 has been left intact to make the backwards compatibility flag output it's results only for PS2 discs.

Conclusion

All in all, I want to see if Slim and Super Slim PS3s really are just like the fat models when it comes to PS2 games albeit with most of the PS2's guts being absent from emulation with the flag for backwards compatibility determining the PS3's response behaviour when it comes to reading ps2 discs.

My proposal here is that the PS2soft_emu that resides in PS3 Slims also resides in Super Slim PS3 consoles as well.

So if it is possible to change the backwards compatibility flag in non-CFW compatible PS3 consoles, I wonder what the possibilities could be in regards to PS2 emulation on the PS3.

Could it be possible to stitch the emulated PS2 components of the PS2 Classics emulator to whatever file holds the emulated IPU of the PS2? Thereby effectively allowing games to actually load upon booting? Could PS2 backwards compatibility be restored?

Such considerations interest me, and I'd like to know if the questions posed in this post are possible with Non-CFW PS3s or not.

Thanks for Reading!
 
Softemu was removed from all current firmwares when netemu replaced it, so there is nothing for it to run if the disc is actually detected as a PlayStation 2 disc.
 
Just a fair warning..

Generally speaking, messing with low level data can potentially lead to severe malfunctions & booting issues, the slightest error on the user's part may have dire consequences that may be more or less difficult to recover from.
Be aware of that fact if/when you start messing with the repository & other data at that level.
 
mrjaredbeta said:
Softemu was removed from all current firmwares when netemu replaced it, so there is nothing for it to run if the disc is actually detected as a PlayStation 2 disc.
Click to expand...
Well, given the observation, it appears that something of the PS2 is still being emulated, given that the disc drive behaves exactly like a PS2 would, where it appears to exhibit this behaviour only when reading a PS2 disc. It also requires something to distinguish PS2 discs from other discs given the fact that the "unsupported software" message only happens for PS2 discs.

So whilst soft_emu may indeed be gone, there appears to be some kind of emulation going on - atleast for the disc drive of the PlayStation 2, and definitely the anti-piracy check. So even without softemu, it will just take a bit of looking around to find out where this disc-drive emulation is coming from (perhaps it is utilising the disc drive aspect of PS1_emu to do the job, filling the role for the behaviour or functionality of the PS2 disc drive?)
 
Last edited:
I correct what I suggested regarding the PS1 emulator, I had forgotten that it had been stripped of Ps2-related functions in a firmware update. However, when checking the revision history of OFW 4.86 to 4.88, I noticed PS2_emu is listed as one of the files changed, but is not one of the files removed. Ps2_emu appears to still exist even in the current OFW of the PS3.

Perhaps that is the source of the Ps2-like behaviour of the PS3 disc drive? It would make sense that they would leave some basic functionality behind, rather than code in some new script just for detecting PS2 discs only to reject them.
 
It is nothing special about it and the IPU has got nothing in common with it. They designed their BD drive to support the PS2 24x CAV mode due to the backwards compatibility. And it just stayed like that till the end of the lifespan. Simple as that.
 
I have never worked on ps2 emu so far so I cannot give you all the answers you seek but modern Cobra payloads include ps2 emu support so if you wanna find out how ps2 emu support is added to CFW, in theory you would only need to look at the Cobra 8.x (or Mamba 8.x) source code in github repos (you can use repos from Joonie, Evilnat or aldostools). In practice, understanding the Cobra ps2emu code might be quite challenging without any prior background knowledge.

HEN is a Cobra 8.x payload in which all the code requiring lv1 peek/poke has been commented/removed & features leveraging that code disabled, everything else is about the same so I am guessing that if habib didn't include ps2 emu support in the HEN payload he put together from the Cobra source, it's most likely because he was not able to do it without yet another exploit or more, in other words you probably need lv1 to be exploited in order to get the ps2 emu self files running or something along those lines, at least the way it is done on CFW.
 
Last edited:
bguerville said:
I have never worked on ps2 emu so far so I cannot give you all the answers you seek but modern Cobra payloads include ps2 emu support so if you wanna find out how ps2 emu support is added to CFW, in theory you would only need to look at the Cobra 8.x (or Mamba 8.x) source code in github repos (you can use repos from Joonie, Evilnat or aldostools). In practice, understanding the Cobra ps2emu code might be quite challenging without any prior background knowledge.

HEN is a Cobra 8.x payload in which all the code requiring lv1 peek/poke has been commented/removed & features leveraging that code disabled, everything else is about the same so I am guessing that if habib didn't include ps2 emu support in the HEN payload he put together from the Cobra source, it's most likely because he was not able to do it without yet another exploit or more, in other words you probably need lv1 to be exploited in order to get the ps2 emu self files running or something along those lines, at least the way it is done on CFW.
Click to expand...
I'm not worrying about enabling PS2_emu, I just want to set the flag for stating if a console is backwards compatible (in sys.hw.config#0 of the repository nodes) from 0 to 1 in order to see what will happen.
 
ExperimentalEnthusiast said:
I'm not worrying about enabling PS2_emu, I just want to set the flag for stating if a console is backwards compatible (in sys.hw.config#0 of the repository nodes) from 0 to 1 in order to see what will happen.
Click to expand...
Everything is ready in PS3HEN to use
lv1_modify_repository_node_value(/*IN*/ n1, n2, n3, n4, v1, v2 );

You only need to have
Code: 
#include <lv1/lv1.h>
in the C file where you make the call.

Make sure you understand how to specify the node level keys (n1/n2..), there is an example in the wiki. And there are more examples in the HEN source, the FIELD macros can be used or you can just take the ascii value for each letter, build the 64bit unsigned integer you need & use that as parameter, for instance, iirc the first key n1 should look something like this
"sys": 0x0000000073797300ULL

According to the wiki, for sys.hw.config.#0
v2 should be 0x0ULL.
v1 is a 0x2000000000000000ULL mask ored with the 32 bit value you wish to use for config, in the wiki the example uses 0xfffffeff, I assume that's what you want to change.
 
bguerville said:
Everything is ready in PS3HEN to use
lv1_modify_repository_node_value(/*IN*/ n1, n2, n3, n4, v1, v2 );

You only need to have
Code: 
#include <lv1/lv1.h>
in the C file where you make the call.

Make sure you understand how to specify the node level keys (n1/n2..), there is an example in the wiki. And there are more examples in the HEN source, the FIELD macros can be used or you can just take the ascii value for each letter, build the 64bit unsigned integer you need & use that as parameter, for instance, iirc the first key n1 should look something like this
"sys": 0x0000000073797300ULL

According to the wiki,
v2 should be 0x0ULL.
v1 is a 0x2000000000000000ULL mask ored with the 32 bit value you wish to use for config, in the wiki the example uses 0xfffffeff, I assume that's what you want to change.
Click to expand...
Thank you! I'll be preparing (to avoid bricking my PS3) and setting up what I need in order to perform this, and will report back on what the findings are.

I want to set the Non-backwards compatible flag to resemble the flag shown in the wiki:

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0100 0000 0000 0000 <--> Mask:Backwards Compatible Flag

I'm wondering, would RPCS3 be a good sampling ground before trying it on an actual PS3?
 
Last edited:
bguerville said:
the FIELD macros can be used or you can just take the ascii value for each letter, build the 64bit unsigned integer you need & use that as parameter, for instance, iirc the first key n1 should look something like this
"sys": 0x0000000073797300ULL

According to the wiki, for sys.hw.config.#0
v2 should be 0x0ULL.
v1 is a 0x2000000000000000ULL mask ored with the 32 bit value you wish to use for config, in the wiki the example uses 0xfffffeff, I assume that's what you want to change.
Click to expand...

Okay, I have done some studying to learn about how I would code in the keys. It's just one thing that I have a question about. How do you build unsigned integers? I can't seem to find any information on the internet regarding how.

Also what are Field Macros? Sorry about this, it's just that these two concepts are something I have never heard of before (other than unsigned integer)
 
ExperimentalEnthusiast said:
Okay, I have done some studying to learn about how I would code in the keys. It's just one thing that I have a question about. How do you build unsigned integers? I can't seem to find any information on the internet regarding how.

Also what are Field Macros? Sorry about this, it's just that these two concepts are something I have never heard of before (other than unsigned integer)
Click to expand...
You cannot find information on unsigned integers in C?
It's one of the most basic C types, it's in every manual & every tutorial about C/C++.
On PS3 you can declare a 32 bit integer like so:
unsigned int val = 0x00000000; //4 bytes
You can declare a 64 bit integer like so:
unsigned long long val = 0x0000000000000000ULL; //8 bytes

Just look at the existing HEN source code & you will find it uses FIELD macros to build the integers, those macros are built in the compiling tools to help building integers at precompiling stage. But you don't need to use them for your tests.

I already showed you how to make a 64 bit integer with the sub keys in the previous post, you take the ascii value for each character of the subkey string.
You can use an hex editor of your choice & write the string in the ascii column to get the values, each character value is a byte.

I haven't used this stuff for a while so it's all from memory.
The first subkey is "sys" which is 737973 in ascii, the first subkey is placed in the lower 32bit, the others start at higher 32bit.
So iirc the first should look like this
unsigned long long key1 = 0x0000000073797300ULL;
And the 2nd & others should be something like
unsigned long long key2 =
0x6861726477617265ULL;
etc..
Look at the wiki example.

As a matter of rule (even when not absolutely necessary, it's safe practice), I would recommend to first read (and take note or backup to file) any node value you wish to modify (with the lv1_get_repository_node function) in your code. If the sub key arguments are wrong, the get function will probably return an error value (usually functions return 0 in case of success & different from 0, sometimes -1, other times an error code like 0x8xxxxxxx etc.., if I were you I would double check what the lv1 get/modify functions should return in case of success or failure & write code accordingly, the existing Cobra/HEN code should help you). And you might want to avoid using the modify function until you have everything right anyway (for instance when you get no error with the get function call).
 
Last edited:
bguerville said:
You cannot find information on unsigned integers in C?
It's one of the most basic C type, it's in every manual & every tutorial about C/C++.
On PS3 you can declare a 32 bit integer like so:
unsigned int val = 0x00000000; //4 bytes
You can declare a 64 bit integer like so:
unsigned long long val = 0x0000000000000000ULL; //8 bytes

Just look at the existing code & you will find it uses FIELD macros to build the integers, those macros are built in the compiling tools to help building integers at runtime. But you don't need to use them for your tests.

I already showed you how to make a 64 bit integer with the sub keys in the previous post, you take the ascii value for each character of the subkey string.
You can use an hex editor of your choice & write the string in the ascii colum to get the values, each character value is a byte.

I haven't used this stuff for a while so it's all from memory.
The first subkey is "sys" which is 737973 in ascii, the first subkey is placed in the lower 32bit, the others start at higher 32bit.
So iirc the first should look like this
unsigned long long key1 = 0x0000000073797300ULL;
And the 2nd & others should be something like
unsigned long long key2 =
0x6861726477617265ULL;
etc..
Look at the wiki example.

As a matter of rule (even when not absolutely necessary), I would recommend to first read (and take note or backup to file) any node value you wish to modify (with the lv1_get_repository_node function) in your code. If the sub key arguments are wrong, the get function will return an error code. And you might want to avoid using the modify function until you have everything right anyway (when you get no error code on get function call).
Click to expand...
Oh I see, I get it now.

Thanks!
 
bguerville said:
And the 2nd & others should be something like
unsigned long long key2 =
0x6861726477617265ULL;
etc..
Look at the wiki example.
.
Click to expand...

I gather that the 2nd key would be hw, which is 6377 in ASCII. So for your example regarding the 2nd key (unless I am wrong in my assumption that it is hw), I see that it starts with 63, however the rest of the key consists of completely different numbers. Why is that?

Sorry if I sound like a noob when it comes to things like long integers, I've just never worked with such stuff before.
 
Yes of course.
It's the ascii for "hardware"..
I only meant to explain how it worked anyway, not give you the exact values to use..
 
bguerville said:
Yes of course.
It's the ascii for "hardware"..
I only meant to explain how it worked anyway, not give you the exact values to use..
Click to expand...
Oh okay. So the 2nd key would just be 0x0000000000006377 then?

As for config, in ASCII it makes 33 bits, meaning that there is an extra bit that can't fit into 4 bytes. What should I do about that? Would having the last bit be a new separate unsigned integer be effective?
 
ExperimentalEnthusiast said:
Oh okay. So the 2nd key would just be 0x0000000000006377 then?

As for config, in ASCII it makes 33 bits, meaning that there is an extra bit that can't fit into 4 bytes. What should I do about that? Would having the last bit be a new separate unsigned integer be effective?
Click to expand...
No, iirc it should be 0x6377000000000000ULL

config is 6 ascii characters = 6 bytes, it fits into the 8 bytes of a 64 bit integer.
 
You must log in or register to reply here.

Similar threads

Back
Top