I'm working on a few unusual mods for the N64. One of them involves extensive use of a Gameshark. For this one, I need to be able to freeze execution of an N64 game for a period of time (and, of course, resume it). I also need to be able to add/remove active cheats via parallel port comms while the game is running. I've realized the two ways that a running N64 game can be frozen: by sending a trainer command over the Gameshark's parallel port, and by pressing the GS button (bringing up the in-game menu). One of these is more volatile than the other. I've found that sending a command over the parallel port and disconnecting causes strange instabilities in OoT, and I assume in other games as well (perhaps more so in games that require a Gameshark keycode). The longer the period that OoT is frozen, the more severe the glitches seem to be. Commands that finish in less than a second usually only cause minor audio blips that recur regularly after the game resumes. However, sending a command and not disconnecting until 5 seconds (or more) later consistently causes the game's main thread to either exit or enter an infinite loop. The audio thread continues to play music, but the screen is not updated and no controller input is processed. Something to note is that the "spinner" on the 7-segment LED (present whenever the code generator is on) rotates unusually rapidly when the game gets stuck like this. Freezing the game the other way, via pressing the GS button and entering the in-game menu, does not cause any of these issues no matter how long the game is left frozen. However, parallel port comms don't seem to work when the in-game menu is pulled up, so I can't add or remove active codes while taking advantage of the fact that the in-game menu correctly gives control back to the game (i.e. enter in-game menu, send parallel commands, close parallel connection, exit in-game menu). Why there is a difference between control passed back from parallel comms and control passed back from the GS menu? Is there some watchdog or other system process that the in-game menu kicks which isn't touched when parallel comms are used? Or is the in-game menu just coded better so that it initiates and exits more cleanly? I'm interested in finding a way to add or remove active codes without flirting with that issue of corruption.
Just can speak from gba expirience, it s a special bios command that always prefers codes with a certain flag attached so the code of the gameshark willbe prefered from the games code. And there the point the games operation will be loaded in each clock in the same place so if your press the gs button the flags are detached. Thats how some gba flashcards aply cheats. Maybe these flags arent detached so the console processes information that lies behind the code which is still on wait so it crashes. If i were you i would use an emulator it way more comfortabel and in combination with a bios rom there shouldnt be any issues. Hasnt the BUNG DR V64 special development options for stuff like this ? It turns every n64 in dev state and can recieve commands over printer port someone can name modern cheap alternatives ?
