Daxter (PPSA09695)

[JJenkx]

Tested Daxter (PPSA09695) 01.000.003 natively on Linux 7.2.9 / Ryzen 9 7950X / Radeon RX 6650 XT, RADV Mesa 26.2.4. This is the PSP game inside Sony's PSP emulator (PSPHD 1.7.18601, release/1.7, 2024-07-09). Short bring-up check, not a full playability report.

Result

On main 434e965d46 + #8618 + #8660, the emulator boots the PSP game: Daxter title menu → New Game → the intro movie ("In collaboration with Naughty Dog, Inc.") → gameplay in the first area with HUD and tutorial prompts. It runs at a steady 30 FPS (the emulator's target) through 240 s runs without a stop. Pad input works for menus and movement prompts.

What it needs

• fix(libSceCommonDialog): return ALREADY_SYSTEM_INITIALIZED from a second sceCommonDialogInitialize #8618 (by another contributor): on main the emulator stops about 2 s in with FAILED REQUIRE(ret == SCE_OK || ret == SCE_COMMON_DIALOG_ERROR_ALREADY_SYSTEM_INITIALIZED) Could not initialize CommonDialog (80B80004), because a second sceCommonDialogInitialize returned 0x80B80004.
• fix(libSceVideodec2): flush without draining when no picture is pending #8660: without it the intro movie is black (Failed to obtain a video frame for each frame). PSPHD calls sceVideodec2Flush after every H.264 access unit, and the flush restarted libavcodec, which dropped every P picture.

Known issue

First run only: with no save data yet, the emulator shows its first-run controls overlay (start_select_controls_ps5.png, (AppEmu) STOPPED reason=0010) and segfaults within a few seconds. It reproduced 3/3 with a fresh save directory and 0/8 once the save data exists, so launching a second time works. The fault is in the emulator's ImGui renderer: an ImDrawCmd texture id holds stale memory, a libkernel return address in the emulator's heap. No kernel or AGC call is made between the PNG read and the fault, so the cause is not found yet.

Not verified

Saving and loading mid-game, later levels, audio quality (Atrac3+ music loads), and the PSP "special" pad port (scePadOpen(... SCE_PAD_PORT_TYPE_SPECIAL) returns 0x80920007, which the emulator logs and continues past).

Reproduce

Relink eboot.bin and sce_module/libc.prx with the repo relinker (--registry --rpath <build>/core/libs/libs), then run app.elf from a directory holding app0/. No environment variables are needed.

AI-assisted testing and report: yes, Claude Code.

[JJenkx]

Follow-up on the first-run crash (fresh _sd, no save data). Tested on main 7280a17ec0 + #8618 (0f2dc3887d, still needed for the CommonDialog stop), Radeon RX 6650 XT, RADV Mesa 26.2.4, under gdb. It reproduced 3 of 3.

What happens. On a first run, the PSP emulator writes default.lsd and loads /app0/assets/common/start_select_controls_ps5.png for its controls overlay. It logs (AppEmu) STOPPED reason=0010, and the render thread then takes SIGSEGV at eboot offset 0xf5c54:

mov  -0x18(%rbx,%r12,1),%r13   ; entry of an object table
test %r13,%r13 ; je skip
mov  (%r13),%rax
call *0x10(%rax)               ; faults

The bad entry. The table entry is not null. It is 0x7ffff7cb6261, which is scePthreadMutexUnlock+81 in AnyPS5's libkernel.prx: a host return address. The words around it look like stack contents as well.

Where the table lives. It is at 0x20554b8xx, inside the title's single 2 GB direct-memory mapping (0x200000000+0x7d000000), which the emulator manages with its own allocator. At the fault, no live thread's stack is near that address; the thread stacks are at 0x27d1xxxxx, 0x38f7xxxxx and in host memory.

Reading. The emulator reuses memory that earlier served as a stack for this table and reads an entry it never wrote. On a console the leftover word there is presumably 0, since that run would skip it. Under AnyPS5, host-side libkernel code runs on the guest stack and leaves host return addresses deeper in it than a console would.

This explains why later runs work: the overlay is shown only on the first run.

Not established:

• which thread's stack it was;
• whether a console really leaves zero there.

A generic fix would mean keeping host library frames off guest stacks. That is an architectural change, not a library fix, and I am not proposing one here.

Workaround. Run once until the crash, then start again; the second run reaches the game, as reported above.

AI-assisted testing and report: yes, Claude Code.