Closed DerekTurtleRoe closed 10 years ago
MediaCon was also chosen because that's the shorthand, hacker-community known name of the PS4's secondary processor: http://www.psdevwiki.com/ps4/MediaCon
Speaking of the GPU, I am kind of sure that it's not as big of a mystery as people originally thought. Although I can't be certain, I am pretty sure that it's based off of some relativeness to the Southern Islands ISA that similar models to that of the PS4 GPU are, which are also pretty well documented. While it may not be ideal, the documentation of Southern Islands might be an asset to further emulate the PS4's GPU, at least somewhat. I haven't really dug enough in, but I think this may be the best you can findfeto managing to emulate the GPU more
GNU GPL 2 is fine for the license.
Overall, to complete the project we'd be looking at stuff like:
1: 8-core x86-64 emulation. 2: ARM v7/8 emulation for the MediaCon(with it's own separate memory). 3: The GPU, which needs to execute compiled shaders, share the same memory with the APU with the AMD/x86 CPU, and that may require digging in a PS4 to see how the drivers do this with OpenGL/etc. 4: Emulate a Dualshock 4's input. 5: To emulate the boot process the main serial flash would possibly need to be fully decrypted. 6: Some sort of sound emulation ... will need more research as well.
If the games are to be run on Orbits OS, we'd need to do more research on it. If games are to run without it, a whole different method will need to take place. Or both methods could be implemented, starting with the easier one (getting Orbis OS running in an emulator). Though that may not be too easy, there's also another option to add: virtualize and run Orbis OS alongside the host OS (like Virtualbox) and then do everything else for the game (e.g. graphics and sounds and input ).
Though you are also right that high-level emulating it all might be the only way to make progress somewhat now.
The terminology is one of the reasons. In GPL v3 they use completely different terminology, it tends to be misconstrued more, and it seems safer to stick with 2. But I guess 3 is practically the same; more stuff is just covered.
For Qt the idea was originally to use SDL + Qt + OpenGL, and avoid Visual Basic altogether. However, this may only work well with separate processes and possibly inter-process communication, and I don't know if that overhead from the start would do well for this project (SDL, Qt, OpenGL, all interacting together will be a bit of a pain).
Do you have any suggestions on this? Input would help.
As for the game, I have a friend who has a copy of Angry Birds: Star Wars for PS4 (actual disk). I'm trying to get my hands on it to make a copy of it.
As for the rest, I'd recommend not uploading any immediate data/code dumps online ... It'd be best to keep that information by word of mouth and exchange info on it without having to move it around.
A guy was arrested for posting a PS3 hack online (I think) a while back; something firmware related or an exploit of some sort.
I have ISOBuster as well, but no Blu-ray drive/etc. Eventually a PS4 disk will be acquired though and I'll need to buy a need rig, but do what you can with what you got.
For the .gitignore, it really doesn't need much ... just some stuff for multi-OS files, like OSX, Windows, Android, etc. Stuff like .cab, .ini, .apk, and other such files that can be ignored/etc. Don't really intend on making this emulator/virtualizer platform-dependent.
Geohot (George Hotz) had a huuuuge lawsuit on his hands when he cracked the PS3's root key and posted it on his site. I think he even ended up fleeing to a different country for a while.
Which is a good example of why posting anything online (that has to do with PS4 game decryption, firmware decryption, keys, etc.) is a terrible idea. Do the wise thing and keep what you crack/reverse engineer/decrypt/exploit/etc. private, and only use that info for emulation progress.
PS4's main serial flash is public, but not fully decrypted (that I'm aware of). The MediaCon is the secondary-processor, but it's the first processor that is mapped to the main serial flash and initializes the rest of the system on boot up. After that it sits idle in the background and does actually perform secondary-processor work (e.g. downloads, network stuff, bluetooth?). It really doesn't have any role, I don't think, in actually executing games since they will be running under Orbis OS on the main 8-core AMD/x86-64 chip(not certain though). There's some info to help (as embrendassy and vgturtle127 have mentioned about the Southern Islands ISA), but further inspection is necessary.
It's not a requirement that a virtual machine would be needed to get Orbis OS running. If the project calls for adequate emulation of the CPUs and such, Orbis OS could run on the emulator and the games can be read from an emulated Blu-ray drive on the OS on the emulator. Don't know how tough this would be (I'm pretty new to emulation), but I can say for sure that it should be possible to run Orbis OS and games through an emulator ... just don't know how problematic that may be (the OS may have "security checks" or other stuff that might make it hard to work correctly without proper hardware emulation/features/etc.). To run the games straight without the OS? How would that work right off the bat? I mean, aren't the games dependent on system calls to access a driver or such for the hardware?
Still no pull requests - I'm going to need to close this soon.
Yep.
Go right ahead. It's actually refreshing to see anyone want to contribute to this project in the messy, incorrect state it's been in. Apart from that, the main project starter, ghaststeam, faced an ugly legal stint with a Sony lawsuit scare when talking about the GPU's instruction set architecture from AMD, andl he backed down.
Anyways, adding the .gitignore and a TODO would be great. Anything else you would like to do as well. Send a pull request and I'll overview and most likely merge it.