In RSP interpreter, it is DisplayError and I feel like it's an important
message, so it should be DisplayError in RSP recompiler as well, in my
opinion.
the & 0xFFC was missing, which caused it to return true when it should
have returned false. This means that LLE audio should be more optimized
now.
I also made it do delay slot, incase the delay slot instruction writes
to accumulator. Minor optimization here.
As for JAL, I made it do break instead of return FALSE because in Battle
For Naboo, it actually does come back and continue an existing
calculation. I think it is only an issue if you do a separate analysis
for the Low Accumulator and Mid/High Accumulators. It's still better to
be safe, just incase I or someone else actually implement a separate
analysis for the Accumulators later down the road.
Due to the newer spec design in PJ64 2.x, CloseDLL() doesn't get called
as often. So there are instances where it calls AllocateMemory()
multiple times without ever calling FreeMemory().
I previously made a commit to fix a reordering issue, but did not
realize it needed that COPO_MF_Instruction flag for branching. This
should fix the Ogre Battle issue.
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.
unknown