I read on the neoflash forums that the latest snes core release 2.3 has real time save support. So what makes it so hard to implement real time save on flash carts? Is it because it requires ram to temporarily dump the state of all the registers? Will everdrive have this feature in future?
Even on SNES, "real time save" is not 100% perect. Some games work fine with it, others have some issues where saving and restoring only works in certain places, and then there are games were it totally fails completely. EverDrive doesn't have enough RAM for doing a real time save. I'm not sure it would even be possible to use FlashROM space to do it but other than that maybe if you could save directly onto the SD card.
Yeah, see I can see ram being an issue. To be able to load/save a state directly from/to the sd card would be incredible. No flash cart seems to have pioneered this properly though, due to the limit of ram. Even in the same fashion as the old console copiers would suffice
I have 3 copiers , I can guaranty that a the real time save function is crap. It doesn't work correctly most of the time , the loaded save has no BGM , boss fail to show up , game glitches all over the place ect.
Yeah I see what u mean... Although real time save works okay on my swc and super ufo. Anyway, it just must be hard to take an accurate snapshot of the actual hardware in action. Emulators seem to pull it off fine, but i guess that's cause the environment they run in already supports it
i never try to implement realtime save. it will be possible on everdrive if snas register and ppu ram have read access. i never try to read them so i dont know. if they have not read acces, then need large ram buffer for ppu ram and registers
I don't know for SNES but 2M seems a lot. I did the calculation some time ago for Genesis, out of curiosity. For internal RAM, you would need 64KB (68k RAM) + 8KB (Z80 RAM) + 64KB (VRAM) + 128 bytes (CRAM) + 128 bytes (VSRAM) = 139776 bytes For 68k registers, you need 20 x 4 = 80 bytes For Z80 registers, you need 18x1 + 4x2 = 26 bytes For I/O registers, you need 16 bytes. These are directly accessible through software and could be dumped by OS program (I can't imagine the difficulty of dumping CPU registers without altering them though). VDP, PSG & FM registers however, are write-only so you would need to sniff all writes to the concerned addresses, decode register writes and store the data. For VDP + PSG registers, you need 24 + 8 = 32 bytes. For FM, you need 2 bytes to store the latched address and 510 byte should be enough for YM2612 registers, 512 bytes total For better compatibility, you might want to decode Z80 bank register, Z80 reset & bus request writes (2 bytes required) as well. Total is less than 140 Kbytes of data to save, the complexity being more in the logic used to decode write-only registers access. Off course, the saved state will never be as compatible as an emulator savestate since you are obviously missing a lot of chip internal data that are never accessible.
Yeah, 2M isn't exact, but it's rounding up. Should he use a 1M & 2x64K RAMs to fit it most efficiently? lol. What about 256K of cart backup RAM? Can't allow that to be corrupted. SNES is basically the same, but there is 1M of WRAM.
I would assume taking a perfect RTS snapshot would be impossible on consoles because just trying to save the state of the machine will ultimately modify the state of the machine your trying to save.
It depends on the method in which the RTS gets control. Usually it's done by hijacking the NMI vector so the state is preserved. Using a normally unused interrupt wouldn't preserve 100% of the stack, but a game shouldn't be that close to allowing the stack to overflow. Another trickier method is to sync to the CPU by watching the bus then feed it a JMP.
Real-time save ability has been implemented for the NES PowerPak: http://www.nintendoage.com/forum/messageview.cfm?catid=22&threadid=41572 Not possible for the EverDrive?
