Problems I find if I want to create a save state for real HW

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
eteream
Very interested
Posts: 81
Joined: Tue Dec 22, 2009 2:13 pm

Problems I find if I want to create a save state for real HW

Post by eteream » Wed May 25, 2011 11:01 pm

So lets say that we have done a flash card, or something like it, that lives within the real hardware, and we want to implement a save state for any program or game like an emulator. Is it possible? What problems will we be facing?
Obtaining the CPUs status seems not so much difficult, but how about graphics ans sound?

NOTE: this is a "what if", I have not done any flash card, the only purpose is to know more about the architecture.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Thu May 26, 2011 6:26 am

States of the video chip internals would be tricky, especially if its mid-DMA. Dumping VRAM and other RAMs should not be troublesome.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu May 26, 2011 7:45 am

There are many stuff you can't read back, such as YM2612 registers, PSG registers, VDP registers , etc.

About CPU states, it's possible to dump most registers (though it might be hard as your savestate routine probbaly needs to use registers) but I don't see how you could save current PC, which is kinda problematic.

LocalH
Very interested
Posts: 152
Joined: Tue Dec 19, 2006 5:04 pm

Post by LocalH » Fri May 27, 2011 9:08 pm

The C64 freezer carts that could "read" unreadable registers would actually sort of "shadow" those memory locations so that the cart would always have an up to date copy of each write-only register. Perhaps something similar can be done on the Megadrive?

As for CPU internal state, it could be more or less pushed to the stack and then pulled back off on loading of the state. This would only ever be an issue if the stack was almost full. The cart could possibly also be modified to provide additional working RAM for the savestate code which could be placed where it wouldn't negatively affect most software. This would also make a "stack full" scenario much less likely.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri May 27, 2011 11:07 pm

You would need to snoop the bus during IO writes to keep your own copy. For the CPU, switch out the rom from the cart with your own, then generate a NMI (int of level 7) with the Lvl7 autovector pointing to a routine that saves the CPU state, pulling some info off the stack. The code when then go on to save all the work ram, the snooped IO state, then the CPU state.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Sat May 28, 2011 7:23 am

LocalH wrote:The C64 freezer carts that could "read" unreadable registers would actually sort of "shadow" those memory locations so that the cart would always have an up to date copy of each write-only register. Perhaps something similar can be done on the Megadrive?
It is feasible only for 68K side, for Z80 side you need to solder in a "spider" that snoops all I/O and stores things of interest (particularly YM writes).
It will still cause games using YM timers to have problems but its as close as it gets I suppose...
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Post Reply