You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To elaborate more on how "making the games work" is hard to use as a measure for accuracy, today invertigo and I investigated why DK64 broke after my PI DMA change to make it slower and theoretically more accurate.
First we verified on real hardware that the PI DMA timing in Ares is close enough to the real one, and it indeed is. That is, my patch that implemented correctly the "9 cop0 cycles per byte" formula is correct.
What happens is that DK64 has a short RSP loop waiting for the PI DMA to finish, with a timeout. The loop is:
so basically it timeouts after 0x200000 iterations, and if it timeouts, DK64 is frozen. There is basically a race between PI DMA and the RSP doing 2M iterations of that loop. The PI DMA being now slower means that the RSP reaches 2M iterations before the DMA is finished.
The problem seems to be that Ares emulates the 4-insn loop in 4 RSP cycles per loop, but on real hardware we measured it takes 7 RSP cycles per loop. That's because of pipeline stalls which are not emulated in Ares. So to get DK64 unblocked with our full accuracy goal, we need to correctly emulate pipeline stalls in RSP to make sure that that loop is slow enough.
The text was updated successfully, but these errors were encountered:
Information about how it broke in ares:
The text was updated successfully, but these errors were encountered: