search

mupen64plus / mupen64plus-user-issues

Issue reports from users go here
http://www.mupen64plus.org/
17 stars 3 forks source link

Invalid operation exception missing in TRUNC, CEIL, CVT, FLOOR and ROUND instructions #673

Open davidroldan opened 8 years ago

davidroldan commented 8 years ago

Some months ago we found a glitch on Super Mario 64 called Parallel Universes. This glitch is described here: https://youtu.be/kpk2tdsPh0A?t=639

As described on the video, we take advantage of the trunc (TRUNC.W.S) instruction to perform this glitch. Also as described, there's some certain situations where console would crash while performing this glitch, but emulator doesn't.

We did some testing with an everdrive cartridge on a real console, and we figured out the console crash was being cause by an invalid operation exception that TRUNC instruction throws.

After reading MIPS documentation, it seems that TRUNC instruction (and also CEIL, CVT, FLOOR and ROUND), if the source value is Infinity, Nan, or rounds to an integer outside the range -2^31 to 2^31-1, the result cannot be represented correctly, an IEEE Invalid Operation condition exists, and the Invalid Operation flag is set in the FCSR.

Source: http://www.cs.cornell.edu/courses/cs3410/2008fa/mips_vol2.pdf

I have been checking mupen's core source code and it seems like it ignores this exception, so the game always continues without crashing (however it may crash on console).

I'm reporting this instead of pulling a request because I'm not really sure how to change the core's code to make this work.

Thanks

richard42 commented 8 years ago

Technically it would be more accurate if Mupen64Plus threw this exception and caused the game to crash, but does this behavior really have any benefit? It seems doubtful, since a real game would never want this to happen. And it may have a performance impact, since we will have to check the input/output values for ranging and throw the exception if necessary.

Isotarge commented 8 years ago

A major goal of the Tool Assisted Speedrun community is to create runs that are reproducible on real hardware. We have recently created robots that play our runs back on real hardware by interfacing with the controller port as shown at recent "Games Done Quick" events. This hardware is expensive and complicated, well out of reach for the average hobbyist TASer, and simply cannot provide the advanced debugging tools or save states that emulation can. These tools are invaluable not only for creating these runs but also for finding new glitches and exploits to make the runs even faster and more impressive in the future.

Since it's impractical if not impossible to create these runs on real hardware in reasonable time, and verifying new glitches to be possible on real hardware is not practical for the majority, we, the TAS community, ask that accuracy improvements like this be implemented into our tools.