Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Releasing version 0.01 #57

Open
VocalFan opened this issue Jan 7, 2023 · 4 comments
Open

Releasing version 0.01 #57

VocalFan opened this issue Jan 7, 2023 · 4 comments
Labels
T-question Type: Question

Comments

@VocalFan
Copy link
Member

VocalFan commented Jan 7, 2023

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?

@ultimaweapon
Copy link
Member

We should have at least one game that can boot to the title menu successfully.

@ultimaweapon ultimaweapon added the T-question Type: Question label Jan 9, 2023
@ArbestRi02
Copy link

Any more updates? It's been 1 year since any.

@SuchAFuriousDeath
Copy link
Contributor

I would say we're pretty close to drawing things to the screen

@ultimaweapon
Copy link
Member

TLDR is we don't really know how long we need to release the first version. Here is a long version what was happened since we started this project:

When we forked from Kyty we tried to slowly migrate its code to Rust but we found a lot of things that we don't like like homegrown framework, using Lua as a configurations so we decided to rewrite the project from scratch. We use this opportunity to pursuit a different way of emulation since we don't believe the way Kyty does are the right way because the PS4 has a lot of libraries. It is going to be a tremendous task to reimplement the required functions in those libraries correctly.

We believed the Kyty way is easy to make the project run a small set of games but it is very hard to run all games flawlessly because it is required all reimplemented functions to work in the same way as PS4. So we decided to reimplement the PS4 kernel instead and reuse all of those PS4 libraries. The benefit of this way is we only need to do reverse engineering on the PS4 kernel instead of a hundred of PS4 libraries, which will be much easier to make the implementation closely match wit the PS4. The downside is it will take a long time to boot the first game but once the first game boot most games are likely to boot without any specific hacks.

Our first reimplementation of the PS4 kernel is a user-mode application, which will have a lot of limitations but we think it is enough to run the PS4 game. But as we make a progress we continue to found out this is going to be a problem because:

  1. The PS4 game map at a fixed address, which we cannot achieve with a user-mode kernel without hacks.
  2. We need to patch the game and PS4 libraries to replace some instructions like syscall and fs access, which is one kind of a hack and have some problem to make it right.
  3. The PS4 libraries required some background services and we cannot run those services because of a limitation of a user-mode kernel.

So we decided to make a real kernel that run on a kernel-mode, which we recently successfully boot it. With the kernel-mode kernel we don' need any hacks and all of above issues will be automatically fixed. The downside is people won't be able to boot a game directly from the emulator because they need to boot the PS4 OS and launch the game like they did on the PS4.

@ultimaweapon ultimaweapon pinned this issue Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-question Type: Question
Development

No branches or pull requests

4 participants