srl/srlv rotate when the low bit of their unused field (rs or sa) is
set and shift when it's clear, whatever the other bits hold
(cpu/cpu_alu/shift_encodings). The interpreter treated values above 1 as
invalid and the other cores shifted.
The Allegrex bit ops decode only some bits of sa, so all 32 values are
one of wsbh, wsbw, seb, seh and bitrev (cpu/cpu_alu/allegrex_encodings).
AllegrexBitOp() gives the canonical one for every core. Special3
function 0x18 does nothing on the PSP, where it was decoded as an alias
of 0x20.
The interpreter dispatch is regenerated, and its generator now lists
each instruction name once. CPUEquivalence no longer skips the srl/srlv
encodings.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Interpreted ops run in the guest's mode. A syscall left to the interpreter
(with JitDisable flags, say) is host code and now gets the host's mode, like a
compiled one, and an interpreted ctc1 to fcr31 now takes effect right away:
nothing set hasSetRounding for it, so the mode only reached the host at the
next time slice. Every other interpreted op skips the two calls it used to
make after it. The IR frontend's Comp_Generic, which the IR interpreter and the
IR native backends share, gets the same treatment.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One is a very hardcoded screenshot download / vfpu convert to 565, and the
other is some very weird check to make sure render is clear or has
happened or something.
The screenshot func detects downloads for the "Royal Album". The render
check detects downloads for post-rename (no idea why it checks here.)
Fixes#7695.
Temp revert old version to fix conflict; Implementing built-in PRO Adhoc Server; Add back sceUsbGps
Implementing more Adhoc functions, and some bug fix (i don't remember them anymore)
Based on tests on a PSP, all branches are attempted. The behavior is
technically undefined.
It seems to take the delay slot's target if they differ and both pass.
This is the behavior the interpreter has, but it's more work in jit.
Since only a couple games seem to do this, and clearly expect this
behavior, this fixes all known cases of #1926.
