Nothing tested sceParseUri, and it showed. Measured on a real PSP by the new
net/parseuri tests:
- A URI without "//" was rejected outright, so mailto:, urn:, about: and even
file:///tmp/x all failed. They parse fine; that is what noSlash is for.
- A fragment ended up appended to the path, because the code looked for "#"
inside the query rather than the whole remainder.
- An empty path came back as "/", because Url insists on one.
- Ports take at most five digits and at most the value 65536, which wraps to
zero; anything longer or larger is refused. A host runs while the characters
are alphanumeric, dot or dash, so an underscore or a bracketed IPv6 address
falls through to the path.
- The three error codes are real and specific - 80433060 bad URI, 804331FE no
output pointer, 80433022 work area too small - where everything returned -1.
Leaving out either area is a size query that succeeds.
So sceUriParse no longer goes through the Url class, which is built for HTTP and
has nowhere to put a fragment.
sceUriEscape kept the wrong two characters: hardware leaves "*" alone and escapes
"~", which is the other way round from RFC 3986. It also fills what it can before
reporting a buffer too small, and leaves the length output alone when it does.
sceUriUnescape was a null entry, so calling it got "library not linked". It is
implemented, including the odd positive return value - one per plain character
and five per escape - that the hardware hands back.
Also lists the two exports libparse_uri.prx has that we did not know about, so a
game calling one is named in the log rather than appearing as a bare NID.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The GE keeps the sign of the z of the last Bezier patch's normal at its last
corner (flipped by patch facing, 0 when sideways or degenerate), and lights a
normal that is exactly zero as that sign times (1,1,1) in model space
(ppsspp-re geprobe exp226-253). Normals the tessellation generates don't take
it. Nayuta no Kiseki and Zettai Zetsumei Toshi 3 rely on it.
Frame dump playback draws a flat +z patch after INIT, as the PSP replayer does
before each replay, so both start from +1.
A run's chunks read the sign and the generated-normals flag, so changing either
waits for the run.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
~2us plus ~0.2us per sample on hardware, 15us for 64 (pspautotests
ctrl/peekcost). We charged a flat 1.5us.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
On hardware the vblank interrupt comes as the last line (285) ends, and
hcount wraps to 0 inside it. It takes ~66us of CPU from whatever runs, or
~78us with a handler, which runs ~29us in. It releases the vblank waiters
after the handlers, and they get the CPU once it's done: ~81us after it,
~91us with a handler, ~3us later for each extra waiter. The vblank ends
~818us after it (pspautotests display/vblankphase).
We charged nothing and released waiters from a separate event 48us after
the vblank, and hcount started at 1 because user code rarely sees line 0:
the interrupt takes most of it. Now the interrupt carries those costs, the
waiters are released inside it, hcount runs 0-285 over the real frame
length, and a thread that waits for the vblank pays the ~6us that makes
waiters take turns ~12us apart, as on hardware.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The app's iDepthRasterMode: Auto, Low, Off or Always on. Its default depends on the device (Low on
Android and iOS, Off without SIMD), which a core option can't express, so "Default" picks that.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
When the color blend uses the src alpha and the stencil has to be written as alpha, both need the alpha
output, so it took dual source blending, and without it the alpha came out wrong. Where the src alpha is
only in the src factor (SRCALPHA or INVSRCALPHA, with DSTALPHA, INVDSTALPHA or a fixed color for the
dst), the shader now applies the src factor (REPLACE_BLEND_PRE_SRC), which leaves the alpha output for
the stencil on every GPU. That's WipEout Pure's additive glows, among others. On a Mac (MoltenVK), none
of the 1,141 dumps in the frame dump collection change with dual source blending on. With it off,
God of War's black squares and one of WipEout Pure's shield dumps now match its render exactly, and
two more WipEout Pure dumps come closer (3,631 -> 2,793 and 4,642 -> 4,163 pixels off).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On a BXM-8-256 (Moto G54), a vertex shader that writes both clip and cull distances doesn't get culled,
while either one alone works. Geometry the PSP culls got drawn: the ground in DBZ Tenkaichi Tag Team,
scenery in Monster Hunter 3rd. With cull distances off, those draws get clipped and culled on the CPU
instead, and the frame dumps match a desktop GPU's render.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Since a37e1f3660, the CPU waits for the depth rasterizer every time a display list ends, because Syphon
Filter reads its depth buffer for the light flares right after. It reads it in the list's GE interrupt
callback though, and so do Wipeout Pure and Resistance: Retribution. On hardware the drawing is done
when that runs, so that's where to wait now, letting the worker overlap with the CPU until then.
sceGeDrawSync and sceGeListSync wait as before.
With interpreter loads from the depth buffer counted and the worker slowed down by 10-50 ms a batch,
no read in Syphon Filter: Logan's Shadow, Wipeout, Resistance or Midnight Club: L.A. Remix landed while
it was busy. Without any wait, nearly all of Syphon Filter's, Wipeout's and Resistance's did.
L.A. Rush reads its depth buffer only after sceGeDrawSync, and the new compat flag
DepthRasterNoCallbackWait skips the callback wait for it.
10 emulated seconds on a Moto G54 (two Cortex-A78, six A55):
Wipeout Pure 7.24 s -> 6.50 s
Resistance 17.98 s -> 13.26 s
Midnight Club 8.75 s -> 8.01 s
L.A. Rush 5.95 s -> 4.76 s
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An ignored bad access takes microseconds of host time and no emulated
cycles, so a guest looping over a bad pointer stretched a single emulated
frame out for seconds. On Android the emulator only checks for exit between
frames, so destroying the surface waited on it until the app hit an ANR.
Play reports show the render loop inside the fault handler when that happens.
Past the limit, the access is treated like one that can't be ignored: the
core stops with the memory exception, which notes why.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Looking for a file whose name differs in case lists the whole pack on
the first miss. For a pack behind a content URI, that's one content
resolver query per directory, which in a big pack takes long enough
that a Play report hit an ANR: the surface was destroyed while the
render loop sat in the texture cache's destructor, waiting for a load
blocked on the index. Shared storage already ignores case, so the index
couldn't find anything there anyway.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On a PSP, two PTP sends made back to back arrive about 1 ms apart (0.95 ms plus 0.65 us a byte), so
a receiver polling fast reads them one at a time; once both have arrived they come back as one read
(pspautotests net/adhoc/pair/ptpsegments, ptpmsg). Through the relay both arrived together, and
Capcom Classics Collection Reloaded's Street Fighter II, which expects them one at a time, dropped
the connection as the match started.
Relay PTP sessions now run in aemu_postoffice's block boundary mode, which hands over one send at a
time. Each block goes into a queue on the socket, up to its buffer size, and becomes readable no
earlier than the previous one plus the PSP's gap, counted from when it arrived; the relay's 1 ms poll
takes blocks as they come, so a receiver that looks late still gets them all at once. P2P mode
can't do this: its TCP stream has no send boundaries.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A firmware only has the files of the model it was installed for, and its XMB looks for the files of
the model we report, so a mismatch brings back #22909's blank theme colors and 6.61's red error
screen. Which models an install is for shows in the names of its ipl/ files (nandipl_01g.bin,
nandipl_psp2000.ipl); an install for every model has all of them, and firmwares older than the
PSP-2000 have one ipl for every model.
Changing the PSP model to one the installed firmware doesn't fit now asks first, with a way to
cancel, and booting the XMB with a mismatch shows a warning.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On a Moto G54 (PowerVR BXM-8-256), F1 2009 and MX vs. ATV Untamed crash every few seconds in
vkCmdDrawIndexed, with a write fault at the start of a page inside vulkan.mtk.so.
At draw time, the driver writes the address and range of every dynamic UBO in the bound descriptor
set into a table, but sizes the table for the ones the shader stage reads. Our layout has two
dynamic UBOs, base and lights (vertex only), and a vertex shader without lighting reads only base,
so each such draw writes 16 bytes past the table. That's usually harmless, and faults when the
table ends a page.
With the new PVR_UNUSED_DYNAMIC_UBO_OVERRUN set on PowerVR, Vulkan vertex shaders always declare and
read the lights UBO. Declaring it isn't enough. On the G54, F1 went from crashing in 5 of 5
10-second runs to 0 of 5, and MX ran 3 of 3. The SPIR-V cache is keyed by source, so no cache
version bump is needed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The VSH goes by this to decide what the PSP has. With the PSP model set to PSP-1000, the firmware
installer only writes the PSP-1000's files, so a shell told it's on a Slim looked for the Slim's:
3.71's theme color list showed its extra colors (flash0:/vsh/resource/13-27.bmp) as blank entries,
and 6.61 stopped at its red error screen. Both reproduced with the reporter's NAND and a PSP-1000
install of 6.61, and both are gone with this.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An upgrade gets its own notice, informational rather than a warning, since the new shell migrates
the registry and nothing is lost. ReplaceFirmware stays for when a version can't be told.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Installing a firmware set category_version to the new firmware's schema, so no shell ever migrated
the settings PPSSPP keeps in its config. A shell upgrades the registry itself at its first boot: it
writes the default of every key added since the stored version and stores its own (seen booting
2.82, 3.71, 4.05, 5.50 and 6.61 from 1, and 3.71 and 6.61 from the previous firmware's version).
So an upgrade now leaves the version alone. A PSP can't be downgraded, and an older shell takes a
newer version for a corrupt registry, so a downgrade sets it back to 1; that shell's first boot then
rewrites everything added since 1.50, the theme, colour and wallpaper settings among them. Values a
newer shell left there across a downgrade and back broke the theme settings and then 6.61's boot.
The install screen says a downgrade resets the XMB's settings. Headless no longer sets the version
per boot either, so each boot migrates like a fresh config does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Colin McRae Rally 2005 interprets about 2 million of these each 10 emulated seconds, mostly vf2h.q.
vsrt1-4 become pairs of FMin/FMax, which order and break ties like the interpreter's vfpu_min and
vfpu_max, in the same operand order. The D prefix applies as usual (Colin masks half the lanes);
S and T prefixes, which vsrt rewrites, still go to the interpreter. vf2h gets an IR op of its own,
FFloatToHalf2, calling vfpu_f2h; the native backends call the IR interpreter's version of it.
vf2h with any prefix, and sizes other than pair and quad, still go to the interpreter.
The CPU equivalence fuzzer finds no differences on the IR interpreter or the ARM64 JIT, for these
ops alone, with random and unknown prefixes, and with the D prefixes Colin uses.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
