pSX 1.13 Bug

[Xifanie]

So, I was debugging my hack this morning, and noticed something REALLY strange going on. I had half-words stored as 0xFFFF when breakpointing, and barely above 0 otherwise.

After 2 hours of trying to figure it out, I finally realized this:

The immediate in slti/sltiu is SIGNED in non-breakpoint mode (normal), and UNSIGNED in breakpoint mode.

I was checking if a value was less than 0xFFFF and setting it to 0xFFFF if it wasn't. At least, that was until I remembered that it would actually check if the value was under -0x0001. So in breakpoint mode everything was running as I wrongly expected.

If something isn't working as expected when breakpointing, that might be why.

[Choto]

what exactly defines breakpoint mode from non-breakpoint mode. Is it when code execution is stopped already? Or when you set a breakpoint ON a sltiu command?

I'm sure it's a simple and probably obvious answer, but I'd like to be sure

[Xifanie]

If ANYTHING is listed inside the breakpoint window, you are in breakpoint mode.
Even if it never ends up breaking on something, it will "corrupt" all slti/sltiu into unsigned.

[Glain]

Isn't it supposed to be signed for slti and unsigned for sltiu?  If it's always signed in non-breakpoint mode, that sounds like it would break sltiu.  You'd think that would lead to more odd behavior playing the game normally...

[Xifanie]

No, the immediate is signed. What CAN be set as signed/unsigned are the registers.
0xFFFFFFC0 will be either -40 or 4294967232 if you use slt or sltu. Just like when using addiu r2, r2, 0xFFFF, it actually subtracts 1 to r2. While it doesn't seem to affect FFT much, I've gotten values zeroed out in Valkyrie Profile entering the main menu.

[Glain]

Okay, I forgot how weird sltiu was...  I had to re-read the documentation a bunch of times.

Apparently, it sign-extends the immediate value, then treats it as an unsigned integer for the comparison (which is weird).  So if 0xffff was the immediate, it would be sign-extended to 0xffffffff and be treated as 65535?  The result in that case would always be true (1) unless the register being compared also contained 65535...