obhq / obliteration Goto Github PK

Right now it is master. We already supplied --default-branch dev when building but it does not work somehow.

Currently the code that handle PFS do a little check on PFS. If the input PFS is malformed or decryption is failed it is likely to crash the application due to buffer allocation failed. It will be better if we can notify the user about malformed or decryption failed instead of application crashing.

The only component that need to fix is src/pfs.

Just a context menu when right click on the game and a blank dialog should be sufficient for this issue.

@Mou-Ikkai used the full VS in the past. Now he switched to VS Code so we don't need to keep the full VS generated files in gitignore.

When trying to run Amplitude (And yes, I did a fresh install), Kyty would usually give a missing instruction error. However, when running the game, it now gives a "The kernel crashed" error before Obliteration closes entirely. It doesn't even show the Kyty error.

Currently Vulkan is cited as a requirement for the project when it is not necessary for building and running it. There's also kyty and uplift repo which are being used as reference; it would be more fitting for them to be git submodules as they are also not part of the core emulator.

At least we have something useful before #58 is implemented.

We need to include an ability to edit the location to install games. According to #1 there are some users who want to change it after setting it with initialization dialog.

Failed to install (D:\852\PS4UPDATE1.PUP.dec) to (D:\systemfolder): Cannot create reader for system image -> cannot read root directory -> unknown entry on #1 on cluster #5 (critical memory 1)

This error occurs when attempting to install decrypted firmware version 8.52

When the .exe boots, and tries to load games, the following error appears.
entry_4096: The system cannot find the file specified (os error 2).

So we can print a beautiful text from the kernel :). We can use this code from Qt Creator. Here is the following source that handled ANSI escape on Qt Creator:

ansiescapecodehandler.h
ansiescapecodehandler.cpp
outputformatter.cpp

The reason is because we are going to move to safe functions by default.

When I started this project my plan is to use a single process for everything and the context crate was designed for this scenario. Then I realized it is not a good idea because we load and execute a PS4 app in the same address space so we moved the emulation part to a different process. With the new model we don't need the context crate anymore.

The reason is because the installation path might be differ for other people.

It is introduced by this commit 24bc727

Currently we use https://crates.io/crates/linked-list-allocator. The problem with external allocator is we don't know if it is going to access the memory that already freed or not. We want to change page protection to none so we can catch when the PS4 app try to access the memory that already freed.

From what I've seen, you and InoriRus have been working together on both Kyty and Obliteration, are they at one point going to be merged together for ease of development? Plus it'd help reduce user confusion.

We could make a setting for it, OR, we can have it obey the user's settings on Windows.

    QSettings settings("HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize",QSettings::NativeFormat);
    if(settings.value("AppsUseLightTheme")==0){
    }

I guess the actual algorithm is Zlib, not DEFLATE because the current code need to skip the first 2 bytes, which I suspect it is Zlib header.

So we can see the stack trace when user reporting an issue. We may also need to enable PDB file for the release build.

https://docs.google.com/spreadsheets/d/1FSr7vXfhMcIb5JfZ2R6O6sY4Ki7yKjLFOyogvwHguwU/edit

Made from my Kyty compatibility template, I now set up a sheet for Obliteration!
Anyone can contribute! (The examples below for the features are from the Kyty spreadsheet.)

• Statuses are autocapitalized and color-coded.
• Spreadsheet is sorted by alphabetical name.
  
• PS4 and PS5 are color coded (PS4 is light blue, PS5 dark blue.)
  
• Game tests with the latest emulator version have green text, while older emulator versions have red text.
  
• Compatibility counter updates in real time! (Uses an COUNTIF statement on the status region)
  
  
• Changes color depending on if a game was tested less than a week ago, a week or longer, a month or longer, and a year or longer.
  

Because obliteration-kernel is too long and obkrnl is not conflict with any *nix programs.

Tried to find the reason for this but no luck. Kyty also experienced this problem too.

I want to use direct mounting in the first place because I want to support Unix file permissions on Windows. After I implemented a new memory manager I found out it have a problem with direct mounting PFS. The reason is because it is possible for each file in a PFS to have non-contiguous data, which make our memory manager cannot map it to the memory without the help from the OS kernel. So we have no choice but to drop the direct mounting feature.

When extracting the inner PFS we need to keep each file permission somewhere so we can retrieve it later.

When do you think we should release the first ever version, and what version should it be called? @ultimaweapon
Should it be when we can load firmware? Or when we can load a game without any issues?

This will potentially be very difficult to do with decent performance but it would be quite nice to see macos and arm support (as that's what apple is increasingly moving towards). In regards to CPU emulation, the Unicorn Engine could be used but am personally unfamiliar with its performance and Licensing could be an issue since it's GPL. There is also the option of Rosetta but it is unclear how long apple will support it.

Regarding GPU emulation, since the core emulation is written in Rust rendering with WGPU might be a good option.

As of right now, there's no guide on how to decrypt the PS4Update PUP file. Adding one would reduce user confusion.

Currently Obliteration's recompiler only provides support for x86_64 platforms. In order to support m1 macs and perhaps even Linux ARM/Android devices aarch64 will be required.

Right now we use serde_yaml which is quite overkill. So it is better to parse it manually because the file structure that we are using is very simple.

This one I cannot create by myself so I'll appreciate if someone can help me with this :)

Sony now has put update and re-installation .PUP files here now on this site https://www.playstation.com/en-us/support/hardware/ps4/system-software/
Is it possible to install updates from these files provided by Sony? (ofc after decrypting them)

A set of games can't find their required libraries.

Amplitude and Project Diva X: [E] Cannot find libSceGnmDriver_padebug.

Persona 5, Dancing In Starlight: [E] Cannot find libSceFont-module.

Homebrew Store: [E] Cannot find libSceFreeType.

Right now the permission is read, write and execute. Better to remove write just in case so we don't have any strange bugs in the future.

As recompilation takes significant effort due to sheer amount of x86 instructions, we've decided to shift our efforts CPU emulation using the Unicorn Engine framework. This would be a significant change in the codebase which would allow us to more easily pursue pertinent tasks in regards to supporting ps4 games (e.g. graphics, sound, etc...).

QMessageBox have rendering problems on Linux with Wayland (at least on GNOME).

It just look weird to have QC / Quality Checks like:

PR Build / QC / Quality Checks (pull_request)
PR Build / Build / Windows (pull_request)
PR Build / Build / Linux (pull_request)
PR Build / Build / Mac (pull_request)

VS:

PR Build / Pre-build / Quality Checks (pull_request)
PR Build / Build / Windows (pull_request)
PR Build / Build / Linux (pull_request)
PR Build / Build / Mac (pull_request)

We can also add other steps that does not related to QC in the future because it not only for QC anymore.

Because it will try to load the games by enumerating the directory.

Right now the only way to stop emulator kernel once it was started is to exit the application so we need to add a toolbar button and menu item to stop the kernel without exit the application. The only file that need to edit is src/main_window.cpp.

So macOS users do not need to build from sources.

So Linux users don't need to build from sources.

In order to be able to upgrade to RSA 0.7, we need to be able to handle the fallible error for primes. The PR that caused this addition is here: RustCrypto/RSA#167

AFAIK there are no any games using 64-bits inode. So adding support for this just for completeness of the library and it is a good place to learn how PFS is working. Anyone who is interested in learning how PFS working can start working on this issue. You can start by looking at src/pfs/src/lib.rs and follow the code to see how it works.

PFS is an image file similar to .iso where game contents are stored. The PS4 will mount this image as a filesystem similar to how Linux mounts ISO files. So learning how PFS is working also gives you some knowledge on how to write a filesystem driver.

Just found out that MSVC since 2015 no longer break ABI across major version: https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170

I currently have a computer in the attic that is unused (Besides from being a Pi-Hole), it has a Ryzen 5 2600, 16gb of ram, and a 2tb SSD. I might set it up to be a self-hosted runner for quicker compilations of Windows builds.
According to github, their specs for default runners is:

2-core CPU (x86_64)
7 GB of RAM
14 GB of SSD space

While the server I have has:

6-core CPU (12 threads x86_64)
16 GB of RAM
2 TB of SSD space

AppImages are usually easier to use than Flatpaks. (Just double-click to run!)

They also include all of the dependencies and are usually smaller than flatpaks or snaps. All the user would have to do to use Obliteration on linux would be to download the AppImage, and double click.

Ah here we here we go again with the big architectural changes... Our experimentation with Unicorn did not go quite as planned. As such will be lifting our x86_64 code to Cranelift IR and have Cranelift handle codegen for our targeted platforms.