Save States on a real N64

[Nemo]

I'm asking this purely out of curiousity. If I were to dump the RAM or my N64 as it was running and then uploaded that RAM back to it later, I would essentially have a save state, right? What range of memory would I have to dump to get it to work without crashing? And How could I strip a save state of the pure RAM contents? Would I have to do any byteswapping, or is it kept in the native N64 format? I've tried (only twice I think, really) to do a save state on a real N64, but the game (KI Gold) crashed. I figured trying longer wouldn't help, since I had no way of telling what part was failing, be it my methods, my software, or my hardware. Also, if the ranges were noncontiguous would I be able to upload them (as two separate files, since that's how my software handles them) with a slight delay in between? Or would I have to pause execution somehow? Ack, sudden revelation, setting a breakpoint would have possibly solved my problem, since the only "pausing" i did, was relying on the fact that execution stops (Maybe it slows down to an imperceptible speed?) as I upload the RAM back. I tried both dumping #000000-#FFFFFF and #000000-{Wherever the last non-null character was. (Btw, I'm approximating the number of digits it would have, I used the right number of digits when I did it.)

 

[Doomulation]

Afaik, emulators dumps the entire n64 memory, although I'm not sure, and later reloads it. It might to something more when loading, I don't know.
Still, it would be as on emulators: unstable. To my understanding, games don't clean up memory properly (well most of them), collecting a lot of garbage. Or somethiing. When saving, it only saves the essential information which it loads to the memory next time and all the other memory is cleared...

But that's all I know.

 

[tooie]

don't forget about the GPR, cop0, cop1, VI_Registers, etc .. memory is only one part of the system

 

[Nemo]

Ack, didn't put enough thought into it I guess. I didn't even think about other components. I got so excited for a few seconds the first time I tried... heh "YES, IT WOR... Oh wait, it's just uploading VRAM... bleh." then it froze, lol.

I've been using my Gameshark for all these things, have to say that's one versatile piece of hardware... WAY underutilized by Interact. Oh well, at least someone wrote better software for it.

 

[Tagrineth]

Yes, it needs to dump all CPU and RCP registers as well. No use having RAM contents if what the processors were working on is gone.

 

[nephalim]

I think it's impossible

 

[Nemo]

I don't think so either, but hardly a disappointment. I entered the discussion in hopes of finding out what prevented me from doing it, rather than thinking there was a way I actually could. Heh, kinda pessimistic, but oh well. Just thought it would be cool to find yet another unintended use for my Gameshark, heh. My screen capture device/rom dumper/cheat device/memory card backup/SRAM backup just can't do save states, I guess, hehe. (I think that's all I can use it for... Tons of cheating tools though, but I guess that's to be expected). Heh, it's great to have it secretly attached to the computer and change variables at will. If you know the memory address (same as the code) you can change Mario's hat on the fly. Too bad it desyncs way too easily, didn't seem to be as bad at first, oh well. If anyone out there knows of any cool GS software other than the one from Interact/Datel and the one from CMGSCCC (I have the newest one, not the one on the site... kinda odd, the newest version isn't available at the creator's site, you have to go elsewhere), please post a link here. Anything but Mac, or some completely unheard of OS would be fine. Dos/Windows/Linux, Preferably Windows (I have to boot to windows for N64 games anyway.)