[Core Port Req.] PCSX2 - PlayStation 2

[Spikestuff]

Upstream info

• Website
• Target platforms: Win/Mac/Tux
• Source repo
• Language(s): C++
• License: GPL v3

Merits

PlayStation 2 is probably the one with the largest backlog, and the most potential for people to make runs and submit them. It's insanely vary and I know that RTA runners of certain titles want to get in TASing a PS2 title, due to recent advancements upstream has improved, but it's not quite there yet (unable to TAS with a Memory Card in or from Full Boot. Some titles fail in TASing), the TAS fork is stable enough by comparison (however the amount of games that are playable does reduce as it's a much older build).

Technical details

Now for the updated annoying part (Updated 22nd Sept. '23). With the major improvements to the emulator it has also recieved an overhaul for rerecording-- it still desyncs^, so multiple files are still required to make a movie from start to end unfortunately.

^2024 Update: You are able to circumvent desyncs as long as you save before/after a load screen, similar logic to that of Dolphin. There's has been reports where it will desync under dumping, but that's also only when a turbo is applied.

In terms of Graphics emulation. Software mode is still the best option in terms of practically everything being functional graphically. However the options of Vulkan and OpenGL are still a nice-to-have in preferences due to their goodizers and they will still thankfully as of the latest update still sync movies between renderers.

Within the PCSX2 Settings. Under "Emulation" and "System Settings", "Enable Multi-Threaded VU1 (MTVU)" and "Enable Instant VU1" are still reported as the best two options to have disabled.

Having Overscan and Screen Offsets would be an extreme nice to have for consistency with the NymaShock core as having the Overscan elements makes it more efficient and correct to render out to the 4:3 ratio as PlayStation 2 loves to be a multiresolution system like the previous system.

Anti-Blur and Disable Interlace Offset (NTSC only from what I can tell) might be helpful in the TASing process, and this cosmetic change still doesn't result in desyncs.

As for the Deinterlacing. The options provided which are; None (for Progressive titles), Weave (bff) and Bob (bff) would be preferable. Their newer mode Adaptive would be something neat for TASing.

The Emulator can be forced into a single-thread configuration tweaking some settings across like the two mentioned above.

---

Previous discussion re: PCSX2 port: #1601 This would supercede the WIP DobieStation core: #2250

[CasualPokePlayer]

If this is to be waterboxed, Vulkan/DirectX/GL will not be options (native GPU stuff is not possible in the box), it will have to be software rendering. Single threading would also need to be forced probably (this is configurable so I assume there isn't much work there).

Recompilers might also be issues too if it is to be waterboxed. In theory it should work, in practice it can be messy depending on the implementation. A quick look seems to say at least they don't use fastmem, which probably means it's possible. If it turns out to not be possible (or just not stable), and interpreters have to be used, then waterbox is probably not viable.

Which even then, if this is a native port, how much more stable would BizHawk actually be compared to upstream? We'd be relying on their states, which seem to not be reliable in the first place. At most you can get BizHawk's tools, but you'd still be in desync hell.

[nattthebear]

I don't think waterbox is viable here. Most JITs are too strenuous for it, and (real) multithreading is a no-go as well.

[InfamousKnight]

What is so unstable about upstream I'm curios? Wouldn't it have less desyncs than that aforementioned tas fork? Because while I was following the development of pcsx2, they updated save state code to "hopefully fix desync problems". And sometimes desyncs are frontend related. Plus they are moving away from hacky emulation fixes and have removed several hacks in the past if you followed their progress.

Whats really great is they have compressed save states now which can make rewind more reasonable. They dont want to implement the feature though because of performance problems.

[CasualPokePlayer]

Likely just bad states somewhere, just forgetting a few variables can propagate to disastrous results. Having a JIT around probably is not doing any favors here. Threading in various places also likely doesn't help.

I really doubt much stablity (if any) would be gained by hawk as is. Waterbox is maybe out of the question, and if so we can't easily fix states without a severe amount of work.

[InfamousKnight]

Yeah, well that's game specific. I've heard games like ratchet and clank are pretty stable(desyncs happen between transition to another planet) so it's good for individual levels. I've also heard that for kingdom hearts ii, certain actions had to be avoided to prevent desyncs.

Its very complex.

[CasualPokePlayer]

That further supports it's state related.

[InfamousKnight]

One more thing to add, those reports listed above are rather old. The kingdom hearts tas I was talking about where certain actions were avoided was made in 2020. Back in October 2021, a massive save state improvement was addressed targeting desync issues with missing variables.

Unfortunately for upstream, because of their move to qt, I don't think I can test anything on their end for any up to date info until qt is done on the recording tools side.

[ghost]

Unfortunately wxWidgets has been completely removed and the next stable release of PCSX2 is arriving soon and it will be completely Qt only.

Since PCSX2 is open source, isn't it possible to create a pcsx2.dll from it's source code with exported functions that can emulate the PS2 hardware and BizHawk will load and use it to play PS2 games on windows?

You can also use the PCSX2 source code that saves and loads states, make an export function "SaveState" and another export function "LoadState" and BizHawk will simply invoke them?

I have no need in rewind feature currently.

PCSX2 will also have a working debugger soon but this is not necessary that it will be usable in BizHawk as long as RAM Search and RAM Watch with features to find, poke and freeze memory addresses will work on PS2 games running by the PCSX2 core (pcsx2.dll).

[CasualPokePlayer]

It's a lot easier said than done to just "build a dll" especially when an emulator is not at all intended to be used in such a way. And whether the standalone emu uses wx or Qt is of little concern to us, as such a dll would be stripped of the frontend (same goes for your remarks about a debugger, as that is largely part of the frontend).

Also, the way you say this implies we would consider having a windows only core for PS2. This is unacceptable, Linux should be just as supported, and it is even more unacceptable given pcsx2 works fine on Linux.

Also if you were not aware, simply having savestate support (which in any case is mandatory for releasing a BizHawk core) automatically means rewind support, as the rewinder is implemented purely in the frontend, the core is only responsible for actual savestating.

[ghost]

It's a lot easier said than done to just "build a dll" especially when an emulator is not at all intended to be used in such a way. And whether the standalone emu uses wx or Qt is of little concern to us, as such a dll would be stripped of the frontend (same goes for your remarks about a debugger, as that is largely part of the frontend).

Also, the way you say this implies we would consider having a windows only core for PS2. This is unacceptable, Linux should be just as supported, and it is even more unacceptable given pcsx2 works fine on Linux.

Also if you were not aware, simply having savestate support (which in any case is mandatory for releasing a BizHawk core) automatically means rewind support, as the rewinder is implemented purely in the frontend, the core is only responsible for actual savestating.

So playing PS2 with BizHawk is impossible?

[CasualPokePlayer]

It is impossible at the moment, it may be possible with time. Please do not expect instant results here, we're ultimately just a small group of volunteers, and we already have other things to do.

[ghost]

It is impossible at the moment, it may be possible with time. Please do not expect instant results here, we're ultimately just a small group of volunteers, and we already have other things to do.

What has to be done or implemented in order to make this possible?

I thought that this is sufficient to use only the backend source code of PCSX2 that emulates the PS2 hardware and that there is no need to touch the frontend source code of PCSX2.

I thought that this is what you did with mGBA to let BizHawk users to play their GBA roms on their PC.

You simply used the backend source code of mGBA to accomplish this but not the frontend source code of mGBA because BizHawk users will still use the interfaces of BizHawk and not the interfaces of mGBA even if they use BizHawk to play their GBA roms on their PC.

And I never expect that things will be done quickly in general. I am used to the fact that I have to wait years to get something done.

[CasualPokePlayer]

Wiring up everything and any frontend and core separating is not a quick a trivial task.

[ghost]

Wiring up everything and any frontend and core separating is not a quick a trivial task.

I did not say anything about the complexity and difficulty of doing this. I just wanted to know if this is possible to do it this way.

[CasualPokePlayer]

Yes, in a very generic way that is one way to describe the process. That doesn't simplify things at all, as you are just ultimately describing a very generic version of the porting process that ignores nuances.

[ghost]

Yes, in a very generic way that is one way to describe the process. That doesn't simplify things at all, as you are just ultimately describing a very generic version of the porting process that ignores nuances.

What nuances exactly?