This commit. I hate it. In order to cure the game's extreme speed, I kept lowing the VI, and it's now running at 15fps. But the ingame clock seems to match 1:1 close enough for most purposes. Game needs RSP Audio Signal to boot, interestingly.
These new values are based on the ones that got very good results on Resident Evil 2 with FAT enabled - 1500\530. They mostly play nice with Azimer's, except for Gauntlet Legend. There is sometimes mild crackle with Jabo, but Azimer's tends to cure that.
Infernal Machine (U) now crackles in menus but sounds lovely ingame. Fair enough compromise, IMO. I disabled various self mod methods since they don't seem to be needed.
That Rush 2049 sure does have some lovely MusyX tracks. Turning down the overbearing SFX volume really drives home how good they are.
I also set Hydro Thunder to CF1. Game is much smoother. Timers and boat handling seem fine.
Tried my best to make sure I didn't miss any op-codes. (Ctrl+F searching for "!= 0" and "== 0" throught the file shows me that I didn't.) If I did miss any op-codes, it's no bug, just remaining extra unnecessary checking for zero.
In the RSP, MFC0, MFC2, and CFC2 were all susceptible to overwriting $zero. Some of us have tried waiting for some games to use handcoded assembly in an attempt to purposely overwrite $zero in their microcode (to throw off emulators), but so far what few occurrences there have been of this have not included using those 3 opcodes. Since it was decided to centralize the security of register $zero in the main R4300 CPU, it was decided to do so in the RSP as well.
In both the 32- and the 64-bit interpreters, ADDI, LUI, LB, LW, LWU, LL, SLLV all check if the destination register specifier is 0, when none of the other interpreter ops do. Actually, none of these 7 need to really check it either, since handling $zero overwrite is already managed in a single location in the main interpreter loop.
unknown