ProsperoLichess (PPSA99009)

[babyhuey]

Existing thread

• I searched this category for the title ID and no thread exists for this title on any platform.

Title

ProsperoLichess (PPSA99009)

Content version tested

01.000.000 (catalog release)

AnyPS5 commit

Windows: main ea2bbef, alone and with #4611 and the sceNetGetsockopt SO_ERROR fix stacked. Linux: main ea2bbef.

System tested

• Windows: Windows 11 Pro 25H2 (26200.9457), RTX 3080 (NVIDIA 591.86), WinLibs GCC 15.2.0 r7, Release
• Linux: Ubuntu 24.04, GCC 13.3, headless (SDL offscreen driver, no window)

Furthest point

In-game (menus and offline puzzles), offline only

What is shown

On Windows it renders its home screen (about 35 fps): Home / Puzzles / Play / Watch / Profile / Settings, an offline puzzle streak with a chess position, and Pass & Play. It shows an "Offline" pill and "OFFLINE - No connection - Puzzles still work", because every request to lichess.org fails:

net: GET https://lichess.org/api/puzzle/daily -> 0 Could not connect to server (curl 7: Failed to connect to lichess.org port 443 after 5203 ms)

DNS (sceNetResolverStartNtoa) and the TCP handshake work. Its curl waits for the connect with sceNetEpollWait on OUT (0x2), then reads SO_ERROR with sceNetGetsockopt:

1. sceNetEpollWait polls for SCE OUT as 4, so the wait never sees the connect finish and gives up after about 5.2 s. That's fix(libSceNet): sceNetEpollWait takes 2 as the OUT event #4611.
2. With fix(libSceNet): sceNetEpollWait takes 2 as the OUT event #4611, it fails at once (curl 7 after about 100 ms), because sceNetGetsockopt has no SO_ERROR (0x1007) and returns EOPNOTSUPP.
3. With both fixed, it connects, then stops at TLS: ca=/gkbHtXc3Wq/common/cert/CA_LIST.cer (MISSING), curl 77: error adding trust anchors from file. The title loads the console's system CA list from that path, which AnyPS5 doesn't provide.

On Linux the headless run stops at the DisplayWindow throw before any request.

Current blocker

Update 2026-10-14: #4611 and #4988 are merged. On main it reaches lichess.org and stops at TLS (CA_LIST.cer (MISSING), curl 77), so it runs offline. The CA list is #5280 (issue #5001). With it on Windows, it goes online: the daily puzzle and Lichess TV load. Separately, it runs at about 3 fps on Windows, not yet investigated.

How it was run

The catalog eboot.bin unwrapped and relinked (--windows on Windows), run from a folder with app0 and an empty data folder, 60 s per run.

[babyhuey]

Update 2026-10-13: the SO_ERROR fix is #4988. Open pull requests ProsperoLichess needs, in order: #4611 (sceNetEpollWait OUT bit), then #4988 (sceNetGetsockopt SO_ERROR). With both on main c2565f0 (Windows 11), it connects to lichess.org and stops at TLS, because /gkbHtXc3Wq/common/cert/CA_LIST.cer is missing (curl 77).

[LeandroLP23]

A setup note for anyone running this from the catalog zip: copy eboot.bin into the app0 folder too.

With filesystem access, storage::app_root() picks the first of /app0, /system_ex/app/PPSA99009, /data/homebrew/PPSA99009 and /mnt/sandbox/PPSA99009_000/app0 that holds an eboot.bin. It falls back to /data/homebrew/PPSA99009 when none does (src/platform/ps5/storage_paths.cpp). If eboot.bin is left out of app0, it looks for its assets under /data/homebrew and stops early:

[PCH] font inter-regular.pchfont failed:
[PCH] fatal: renderer init failed

With eboot.bin in app0, main 88107b7de on Windows 11 (Radeon 860M) runs the full 60 s at its start screen. That run had no network setup, so it doesn't cover the lichess.org connection steps above.

AI-assisted: yes (Claude Code)

[Sevthered]

Update on the TLS stop, with a question about where the certificate list should come from.

Windows 11 (26300), RTX 3080 Ti (NVIDIA 616.56), WinLibs GCC 15.2.0 r7, Release, main 0aa4cb1c2 with #4988 cherry-picked. Catalog release 01.000.000, eboot.bin and sce_module/libc.prx unwrapped from their SELF containers, relinked with --windows, eboot.bin copied into app0.

With #4988 the connection completes and every request stops at TLS, as described above:

net: curl tls rand=1 ca=/gkbHtXc3Wq/common/cert/CA_LIST.cer (MISSING)
net: GET https://lichess.org/api/puzzle/daily -> 0 Problem with the SSL CA cert (path? access rights?) (curl 77: error adding trust anchors from file: /gkbHtXc3Wq/common/cert/CA_LIST.cer)

With a PEM bundle at that path and no code change, the title goes online. I copied the ca-bundle.crt of Git for Windows (150 certificates) to gkbHtXc3Wq/common/cert/CA_LIST.cer beside the executable, which is where the guest path resolves today:

net: curl tls rand=1 ca=/gkbHtXc3Wq/common/cert/CA_LIST.cer (found)
[PCH] lichess reachable
[PCH] lichess probe status=200
[PCH] tv game <id> <white> vs <black>
[PCH] tv moves=1 t=1.0
...
net: callback listener on port 28844
net: callback listener received /callback
[PCH] signed-in user=<name>

In a three-minute run it follows Lichess TV move by move (four games, 73 move updates) and completes sign-in through the browser callback. So after #4988 this file is the only thing its network path still needs on Windows.

What the title expects, from its source (src/platform/ps5/curl_platform.cpp): it looks for /system/common/cert/CA_LIST.cer, falls back to /<sceKernelGetFsSandboxRandomWord()>/common/cert/CA_LIST.cer, and passes the path to CURLOPT_CAINFO (libcurl 8.18.0, OpenSSL 3.5.2), so the file has to be PEM. Its comment calls it "the system's list of certificate authorities, CA_LIST.cer (plain PEM)" and credits the ProsperoRadio curl guide, so other titles built on that guide probably read the same file.

No issue or pull request covers this file (searched CA_LIST). Which of these would be accepted?

1. Document it, as for system fonts: the user supplies the file (a console dump or any PEM bundle), for example anyps5-cert/CA_LIST.cer beside the executable with an environment variable to point elsewhere, served at both guest paths.
2. Build it from the host trust store when a title opens the path (the ROOT store on Windows, the distribution bundle on Linux, the keychain on macOS).
3. Only document that the file can be placed under gkbHtXc3Wq/common/cert/.

I can implement the preferred one after my open pull request (#5440) is merged; as a first-time contributor I can have only one open.

AI-assisted: yes (Claude Code); the runs are from my machine.

[Sevthered]

Correction to my question above: this is already tracked. Issue #5001 covers the missing CA_LIST.cer for every title that bundles its own OpenSSL, and #5280 serves a bundle built from the host trust store at that path; babyhuey ran ProsperoLichess with it (curl 77 gone, probe 200). I missed both when I searched. The design question is open in #5001, so I'll follow it there instead of here.

[DavidSamir]

macOS status: Apple M2, MoltenVK 1.4.2 (LunarG Vulkan SDK 1.4.363), macOS 26.7.1, x86-64 under Rosetta, catalog release 01.000.000.

The tree is main ce991f1 plus the macOS runtime work that isn't on main yet: #4627, #4630, #6124, the four macOS relinker PRs and mugurc's port branches. The title then stops on GPU features MoltenVK lacks. The open pull requests it needs on macOS, in order:

1. fix(agc): normalize unused viewport depth ranges #6535 (unused viewport depth): clears viewport depth outside [0, 1] requires VK_EXT_depth_range_unrestricted on its first such draw, which has no depth target.
2. fix(agc): draw a last provoking vertex that no pixel input sees without the extension #6741 (last provoking vertex that no pixel input sees): clears last provoking vertex requires VK_EXT_provoking_vertex with provokingVertexLast enabled, on a triangle fan whose pixel shader has no inputs.
3. Then it stops again on the viewport-depth refusal, this time on a draw with depth −1..1 and a depth target bound. That's feat(agc): remap a viewport depth range the device cannot express into the vertex shader #4650's case (remap the depth range in the vertex shader). feat(agc): remap a viewport depth range the device cannot express into the vertex shader #4650 conflicts with main at the moment, so I haven't been able to test it.

Each step was 3 runs of 3, 60 s each.

AI-assisted: yes