Adding PPSSPP as ported emulation core for Sony PSP
Adding https://github.com/TASEmulators/ppsspp/tree/ported as new ported core in Bizhawk
- [x] Core compiling and running on Bizhawk
- [x] Add proper cd callbacks
- [x] Correctly handle shutdown
- [x] Add save/load
- [x] Add inputs
- [x] Add memory domains
- [x] Load ini with compatibility flags
- [x] Print UI messages to
CoreComm.Notify - [x] Handle disc swap
- [x] Handle thread create on save
- [ ] Preserve NVRAM
- [x] Load language ini file
- [x] Load atlas font file
- [x] Add sound
- [x] Find out why some games crash on load (whereas they don't for https://github.com/SergioMartin86/headlessPPSSPP)
- This is most likely due to BizHawk not having support for larger mediums (DVD size).
- [ ] gamedb
- from Spike:
- [ ] Font shenanigans
- [ ] Font that's being called from PPSSPP isn't correct to how PPSSPP presents it, most notably the Trademark Symbol is absent.
- [ ] Font replacement isn't being done in titles such as Crimson Room: Reverse and Ghost in the Shell so font displays as blank.
- [ ] CSO and CHD support.
- [ ] When an ISO and CSO are present in the same folder, Hawk will complain about the other file. This previously wasn't the case.
- [ ] Certain titles are rendering for a split frame green and black vertical bars (Namco Museum Battle Collection demonstrates this quickly).
- [ ] Certain titles are showcasing incorrect graphics, solve why this is happens. This appears in Ridge Racer.
- [ ] Certain titles have broken models, solve why this is happens. This appears in Tekken: Dark Resurrection.
- [ ] Find out why some games crash during gameplay Exit (fails to play mission) and Mercury Meltdown (fails to load first FMV).
- [ ] Find out why certain movies desync when creating a TASProject (see Tekken 6).
Check if completed:
- [x] I have run any relevant test suites
- [x] I, the committer, have read the licensing terms for contributors (last updated 2024-06-22) and am compliant
I get this error when trying to load a rom (both ISO and CHD)
As of - https://github.com/TASEmulators/BizHawk/pull/4284/commits/3d3a12ab1277de0124992c0f8c23f49077c3fdba All issues that were initially in this post has been resolved (check comment history).
Regardless, hell yeag on getting titles to work eien86.
Second thing to note as above is related. Some titles can crash out in BizHawk. Example title being used is Jetpack Joyride (minis) where the game will be able to boot
This should be fixed now.
The core is now mostly functional and I reduced the diff wrt upstream the most I could.
Still, there seems to be some games (Crash Tag Team Racing (US).iso) that fail to load. These games DO work on my headless playerhttps://github.com/SergioMartin86/headlessPPSSPP, so no idea why putting this into bizhawk could be a problem.
I haven't figured out how NVRAM is saved so that is still pending.
I truncated out the issues from my above post. Just read the History for what's been fixed (good shit eien).
In terms of new issues (by the autobuilds here). Using f1a8d12.
The major one besies the wrong font is being called compared to PPSSPP for some reason.
Is that the "™" is missing from "Memory Stick™":
Compared to PPSSPP:
And according to KAGE-008 at the very least this font issue affects Ghost in the Shell, Assassin's Creed Bloodlines, Crimson Room: Reverse, Jeanne D'Arc and Dissidia.
I was able to validate this missing text issue with Crimson Room: Reverse.
Another title having issues beside Crash Tag Team Racing is Xyanide Resurrection according to KAGE-008 as well. You're able to boot into the game, but you land into a loading loop before the gameplay starts.
And you're currently unable to access PSP > Settings.
(At least all these are issues with autobuilds)
Missing glyphs aside, could the difference in font metrics cause any problems? Would a scrollbar appear if the message was slightly longer?
I don't believe it would be a situation where for example you're missing the Japanese Locale and the entire game would run differently. But I also haven't run into a situation where it might have happened to me.
Regarding unstability for some games. I suspect there is some memory corruption that causes issues on Bizhawk+Windows. When running the core on my own driver (https://github.com/SergioMartin86/headlessPPSSPP), it works perfectly for the games that crash
Can someone link a prebuilt zip file for linux?
https://github.com/TASEmulators/BizHawk/actions/runs/14476049776/artifacts/2950288002
And it doesn't load star wars battlefront 2.
That's been an issue of latest build (16th), the previous one still works fine (above my previous ramble about the list of issues). Just bar every issue I already outlined within the two posts.
"ah must be because I compiled it in debug mode (again)?" -eien86
Eh, having some stability issues over here with it. Weird problems like it not working on an x86_64 machine but then "sometimes" works on some windows emulator for android. Limited to gdi+.
I'm assuming it's not wbx because of performance? As a taser, performance is of no concern unless it's running at like 1fps.
I'm curios why this is not waterboxed. I know waterbox would affect performance, but I don't like tasing while worrying about desyncs.
I'm curios why this is not waterboxed. I know waterbox would affect performance, but I don't like tasing while worrying about desyncs.
The interpreter crashes when waterboxed. We don't know exactly why, but for now a waterboxed implementation is out of the question. The core seems to have solid load/save state procedures so I'm confident it can still be used ported directly.
Linux build doesn't work (InvalidOperationException: got null pointer from dlopen, error: dlerror reported no error).
$> ldd output/dll/libppsspp.so
linux-vdso.so.1 (0x00007fa7b2076000)
libavcodec.so.57 => not found
libavformat.so.57 => not found
libavutil.so.55 => not found
libswresample.so.2 => not found
libswscale.so.4 => not found
libSDL2-2.0.so.0 => not found
libstdc++.so.6 => not found
libm.so.6 => /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libm.so.6 (0x00007fa7b0317000)
libgcc_s.so.1 => /nix/store/4y1jj6cwvslmfh1bzkhbvhx77az6yf00-xgcc-14.2.1.20250322-libgcc/lib/libgcc_s.so.1 (0x00007fa7b203e000)
libc.so.6 => /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libc.so.6 (0x00007fa7b0000000)
/nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007fa7b2078000)
Linux build doesn't work (
InvalidOperationException: got null pointer from dlopen, error: dlerror reported no error).$> ldd output/dll/libppsspp.so linux-vdso.so.1 (0x00007fa7b2076000) libavcodec.so.57 => not found libavformat.so.57 => not found libavutil.so.55 => not found libswresample.so.2 => not found libswscale.so.4 => not found libSDL2-2.0.so.0 => not found libstdc++.so.6 => not found libm.so.6 => /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libm.so.6 (0x00007fa7b0317000) libgcc_s.so.1 => /nix/store/4y1jj6cwvslmfh1bzkhbvhx77az6yf00-xgcc-14.2.1.20250322-libgcc/lib/libgcc_s.so.1 (0x00007fa7b203e000) libc.so.6 => /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libc.so.6 (0x00007fa7b0000000) /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007fa7b2078000)
Fixed now for me
Is there a reason the linux version depends on the entirety of ffmpeg and the windows version... doesn't?
both depend on ffmpeg -- in windows the prebuilt files are provided by ppsspp; in Linux, only the statically compiled libs, so I had to build the relocatable ones.
After some testing with other games and re-recording extensibly wit TAStudio, seems like this port is more stable than I previously thought. It works correctly as ported for Linux and Windows.
I believe this could be even released normally (i.e., not as experimental), if we can produce some movies and have them peer-synced
Tested midnight club 3 and this showed up:
DB: hash 391844022ABD2FEBA85CDF48FD7543FD not in game database. In PPSSP Core [CD] Sector count: 81584
And opening the zip file just crashes bizhawk. I had to extract the zip to even get that far.
@InfamousKnight This branch doesn't add to the gamedb, and you can't load discs from archives, see #2046.
After some testing with other games and re-recording extensibly wit TAStudio, seems like this port is more stable than I previously thought. It works correctly as ported for Linux and Windows.
Does this mean
Find out why some games crash on load (whereas they don't for https://github.com/SergioMartin86/headlessPPSSPP)
was resolved? Or just that you haven't found any sync problems with games which do load?
After some testing with other games and re-recording extensibly wit TAStudio, seems like this port is more stable than I previously thought. It works correctly as ported for Linux and Windows.
Does this mean
Find out why some games crash on load (whereas they don't for https://github.com/SergioMartin86/headlessPPSSPP)
was resolved? Or just that you haven't found any sync problems with games which do load?
As far as I tested, all the games on my test bench work right and don't suffer from sync issues.
Only exception: Crash Tag Team Racing (US).iso which gets stuck reading the disc on startup.
Alright, let's see what's different... and new things to mention.
Refer to the other two, which have a list of things that I have been editing if something has been corrected.
- https://github.com/TASEmulators/BizHawk/pull/4284#issuecomment-2791408518
- https://github.com/TASEmulators/BizHawk/pull/4284#issuecomment-2799913953 Everything in the second one still stands.
A new one is when loading the iso and having a cso in the same folder it'll notice the cso and complain about it.
Oddity: Much like with encore there is a first boot desync type thing going on when going TAStudio -> bk2. When I did stumble on this, all I had to do was add a frame that corrected it. This uses Namco Museum Battle Collection (USA) as the test game. The fail file was the fresh experience of it so what's typical to stumble on. The "fix" made a frame adjustment after stumbling into this oddity. NMBC.zip
There's this issue which you can only avoid by going with frame advance. For some reason in certain titles like Namco Museum Battle Collection or The Basics the emulator will flash green for a frame. This isn't present in PPSSPP.
eien is using the Software Renderer.
As pointed out by KAGE-008, we don't know where the games are saved on our system.
Took me about 10 minutes to figure it out. The folder with all save data is in C: or whichever your main drive is, in the root dir. To sync you might want to remove all savedata before proceeding, or backing up your own savedata if it was already started with it.
And yes, sync wise this core is way more stable than what I initially thought. Yesterday I did a 15 minute test of The 3rd Birthday with successful results. Same with a 5 minute test of Lumines, a game which supposedly gives 'random' blocks.
This is what happens when I try to open the 3rd birthday...
chromebook using crostini. I can load everything else but psp games.. I have all dependencies installed: mono, libc6-dev, libsdl2-dev, libopenal1 and ffmpeg.
Maybe debian bookworm has an issue with it? that's what the default Chromebook Linux subsystem uses
Most of the games that I tested worked fine, the exceptions are Tekken DR, Assassins Creed, God of War, they don't present any error but simply stuck on a black screen with the frames running. Sillent hill origins I get a black screen after the start menu. The only thing missing is the rewind function, I don't know if it's disabled intentionally or I messed up something I did a 10 minutes movie test on Avatar and did not desync once
Can the ppsspp folder be in any subfolder (submodules, ExternalProjects, ExternalCoreProjects) that isn't root? I would like to move away from polluting the BizHawk root folder with random core folders.
~~Almost!~~ edit: Morilli is right, this I think is pulled from Mono's closure? ldd ${mono}/bin/mono --> libstdc++.so.6 => /nix/store/xvzz97yk73hw03v5dhhz3j47ggwf1yq1-gcc-13.2.0-lib/lib/../lib64/libstdc++.so.6
$> LD_LIBRARY_PATH="$PWD/dll:$PWD:$LD_LIBRARY_PATH" ldd dll/libppsspp.so
linux-vdso.so.1 (0x00007f0637c31000)
libSDL2.so => /home/yoshi/Documents/BizHawk/output/dll/libSDL2.so (0x00007f063663e000)
libstdc++.so.6 => not found
libm.so.6 => /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libm.so.6 (0x00007f0637b40000)
libgcc_s.so.1 => /nix/store/4y1jj6cwvslmfh1bzkhbvhx77az6yf00-xgcc-14.2.1.20250322-libgcc/lib/libgcc_s.so.1 (0x00007f0637b12000)
libc.so.6 => /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libc.so.6 (0x00007f0636400000)
/nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007f0637c33000)
libdl.so.2 => /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libdl.so.2 (0x00007f0637b0b000)
libpthread.so.0 => /nix/store/zdpby3l6azi78sl83cpad2qjpfj25aqx-glibc-2.40-66/lib/libpthread.so.0 (0x00007f0637b06000)
$> ls dll/libstdc++*
dll/libstdc++-6.dll
I think that's correct. A lot of current .so's rely on libstdc++.so.6.