Now that I think about it, it would be impossible to implement savestates because the emulated dos program sometimes depends on memory other than RAM (for example HD) and loading a memory state saved during a HD write would be...well...bad, to say the least.

Type in save + state into Search.

Oh, sorry. Didn't know that a "+" was required in search box.
Well, I guess that it *could* be done if DosBox could use some kind of hard-drive image filesystem as well as local r/w filesystem, but the effort/gain ratio of such impementation woud be very low.

> during a HD write
Such things are atomic in Dosbox.

borisb wrote:

Now that I think about it, it would be impossible to implement savestates because the emulated dos program sometimes depends on memory other than RAM (for example HD) and loading a memory state saved during a HD write would be...well...bad, to say the least.

The main reason why it wouldn't work just saving RAM would be the internal states of all the emulated hardware and the emulated DOS. I guess the harware objects (if they are objects, I'm not entirely sure) could be extended with a 'safe state' method, but this is a major operation. Not something anyone would like to do 😀. But I admit it would be a nice feature...

JAL

There's some recursiveness (RunMachines and Pagefaults) which can
not be resolved easily.

If some research was done into how a psp saves everything into temporary memory so that if the psp is turned off then on again it picks up where it left off, that may give you the answers you seek. Not completely obviously as its an entirely different system, but I think it would be something worth looking into.

icemann wrote:

If some research was done into how a psp saves everything into temporary memory so that if the psp is turned off then on again it picks up where it left off, that may give you the answers you seek. Not completely obviously as its an entirely different system, but I think it would be something worth looking into.

That would be of absolutely no use whatsoever. What the PSP does is what Windows or Linux does when hibernating. But remember that's OSes doing that, not emulators! Besides, the PSP is a closed sytem, there's absolutely no way to do 'some research' into it. If anything, looking at other emulators would be useful, but we basically already know how to do that stuff, it's just its a goddamn awful lot of work.

JAL

Even if leaving out console emulators, there are some differences in
dosbox compared to e.g. bochs/qemu which make it even more difficult
(not that savestates are an easy thing in bochs).
It is caused by the callback design, which resulted in the need for
an interesting but hard to save pagefault mechanism, as well as the
code for RunRealInt/RunRealFar (though those have been reduced
in amount already).

wd wrote:

Even if leaving out console emulators, there are some differences in dosbox compared to e.g. bochs/qemu which make it even more […]
Show full quote

Even if leaving out console emulators, there are some differences in
dosbox compared to e.g. bochs/qemu which make it even more difficult
(not that savestates are an easy thing in bochs).
It is caused by the callback design, which resulted in the need for
an interesting but hard to save pagefault mechanism, as well as the
code for RunRealInt/RunRealFar (though those have been reduced
in amount already).

Without knowing the details, could this be handled by delaying the actual safestate to a (slightly) later time (e.g. when any pagefaults have been resolved)?

JAL

Except if they aren't resolved for a long time or aren't resolved until game exits?

Maybe use a special handler which would dump dosbox process memory to image is possibe, but it needs to take care about saving state of input/output, date&time, filesystem (maybe enable this only within archive file so changes can be tracked?)...and maybe it requires changes to SDL too. It'd be very hackish.

Though for simpler real mode games it might be possible without a lot less headache (those without save ability are mostly older).

Actually having some checkpoints (ie. waiting for pagefaults to
return) is the solution i have in mind for the pagefault case.
It is already assumed (normal/full core only, and callback c-code)
that pagefault handlers always return, and they should do so in
very little time (not noticable to the user).
But this technique cannot be used for recursive calling of the
shell (simple example: something uses int21/4b with command line
"command.com /c program.exe") because it might delay saving for
program-running time (too long...)
Also it doesn't work for keyboard input loops (dos con device
reading, which uses CALLBACK_RunRealInt(0x16); to read keys
using the bios). Faking key-presses is not an option as int16
might be intercepted.

Saving the running executable image sounds nice, but surely
would limit the savestates to one executable, so it's not
really preferable imo.

Good to see that you guys are looking into it, in either case. Save States is something we`d all love to see at some stage.

Save States is something we`d all love to see at some stage.

I'd like it to be implemented so that people would stop asking about it. Geesh. Does anyone read the "Wish List Thread"?

> I'd like it to be implemented so that people would stop asking about it.

Go ahead. Hope you'll get everything sorted out. Same for the wishlist.

Umm, not sure what your saying but my post was basically stating that I really didn't give a **** about save state support except to get rid of the whiners. I guess you have a problem with that?

Well, I guess WD misunderstood you... (thinking that you mean it literally, not ironically - and therefore getting angry).
It struck me immediately when I saw both comments in the morning... I wanted to add my reply here but was too lazy...

No need to start fighting...

Mirek

DosFreak wrote:

Umm, not sure what your saying but my post was basically stating that I really didn't give a **** about save state support except to get rid of the whiners. I guess you have a problem with that?

I don't have a problem with you not being interested in save states, but personally I find it a very interesting topic. Most posts here weren't wining but constructive thinking (imho, of course).

JAL

Not here, the posts we get every week on the forum asking for save state support. Annoying to put it mildly.