search

mupen64plus / mupen64plus-core

Core module of the Mupen64Plus project
1.29k stars 257 forks source link

Controller Pak saving occurs too quickly #273

Open ruadath opened 7 years ago

ruadath commented 7 years ago

Not sure how high of a priority accurate emulation of the saving process is on your list of things to do, but it would be really cool if you guys could get the emulation of the controller pak to take the same length as it would on console. It would allow for save corruption techniques that are applicable to certain speedruns to be done on emulator (especially for TAS purposes). In particular, I am thinking of Quest 64; I will link you to the following threads discussing how the save is corrupted (fairly easily and reliably) on console and how the corruption is not possible on emulator:

Save Corruption Discussion: https://forum.speeddemosarchive.com/post/quest_64_save_corruption.html

Not possible on BizHawk port of mupen64: http://www.speedrun.com/quest64/thread/u8vg6

loganmc10 commented 7 years ago

This is probably only possible on a cycle accurate emulator like CEN64. On a real console, the data transfer would take (for example) 0.5 seconds, and the data would be copied bit by bit over that 0.5 seconds.

In mupen64plus and PJ64, all the data is copied immediately at the beginning, and the interrupt is just delayed for (roughly) 0.5 seconds.

CEN64 is supposed to simulate that "bit by bit" data streaming, so memory corruption techniques might be possible there (if it is working properly there)