Step 1: Freeze emulation
Step 2: Dump DOSBox's internal RAM to file
Step 3: Resume emulation

Hehe if it only were that simple.

Why isn't it?...

Snover wrote:

Why isn't it?...

CPU register status, status of all HW devices, etc.

Schadenfreude wrote:

CPU register status, status of all HW devices, etc.

Surely all of these states are just variables in the emulator memory space, which can be saved/restored as easily as anything else?

Or did you mean something else?

I know many other emulators which manage this perfectly well. Generally its considered an essential tool for debugging purposes, especially when there's an error that pops up halfway through an emulated game. It also allows your users to aid you by giving you a savestate when reporting a problem.

Hehe, it's not that easy. Just some things that came into my mind:

Restoring states:
Some restored variable values may imply actions that need to be taken to restore the state correctly. Simple example: Restoring a file status, you have to do some extra actions like: a) open physical file b) move filepointer etc.. it's not just to save and restore "file xxx hast to be open". There are probably more complex actions in other cases. Not that it is that much of a problem, but it's additional coding.

Object consistency:
Some objects are created dynamically (during runtime) in dosbox. If you restore a state you have to be sure to recreate these objects in the right order and with the right dependencies between them.

Savestate consistency:
Better be sure not to change a lot of variables (and the meaning of their values) that need to be save/restored, cos everytime you do that your old savestate file will be invalidated (file format has changed, there's a missing variable, or whatever, in the old files now). And this will probably happen quite some time as long as you are in development and implement new features. Therefore you need a system that can handle those changes and still read older savestate files (->more coding) or you just dont care and some dosbox users are annoyed cos they cant use their old saved states anymore... 😀

Basically it's some work and it's a error-prone task, dont underestimate it. Take a look at computer games, how much problems do they have saving/restoring their game states correctly ?! Lots of incompatibilities and problems in quite a few (even up-to-date) games.

Besides, it doesnt have high priority atm i guess. 😜

Originally posted by Daveybaby I know many other emulators which manage this perfectly well.

But I bet they are console emulators, right? I can see how setting up "snapshots" for a PC emulator could get very messy very quickly.

I remember using an "Action Replay" cart/card on my Amiga and it was fine as long as the game didn't use the OS...or there wasn't more than 3 Megs of memory...or the processor wasn't too fast...etc

Having said all that, the "undo" function in "Virtual PC" works quite well...but the way it works would make for a clunky "quicksave".

Ok well, besides protected games support. What features are currently being worked on at being implemented? if thats not top secret information ofcourse 😜.

Having full support for all of the dos commands is one of the small things I`ve been waiting for, for a while.

the internal dos has been updated a bit.

It would depend on which features you want ....
(it's made more compatible)

Well for example all of the dir commands (dir/w, dir/w/p etc), and the edit command (for editing batch files etc).

edit was a program, not a command.

DIR/P, DIR/P/W, and up/down to cycle through the command history have been working for a while now. I really can't think of anymore DOS functionality that DOSBox needs at the moment.

For what it's worth, the version of EDIT.COM that comes with Win2K works perfectly in the current CVS version of DOSBox. So if you absolutely must edit text files from within DOSBox, there ya go.

Tab completion is also present.

dir.exe and shortcuts like that are possible as well
dir.vol
del.

Nicht Sehr Gut wrote:

But I bet they are console emulators, right? I can see how setting up "snapshots" for a PC emulator could get very messy very quickly.

...

Hmmm... yeah, now i've thought about it a bit more - dosbox *is* a more complex job than the average emulator... the main difference being the fact that youre using the same filesystem as the host, instead of running off of an 'image' of a filesystem, like most console and old home computer emulators do.

Its still possible - but it is always a very hard job to plumb something like that in once a project is halfway through... its much easier if the software structure has been designed with that in mind from the beginning.

DOSBOX is C++; as long as every relevant object has a nicely-writen serialization method... 😀

V.

Hehe it's more like an evil combination of C++ and a C and savestates should also be endian 32/64 bit compatible if you'd want them to be exchangable.

Guys, take a look at Game Wizard...
I think thats an better idea to make Game Wizard compatible with DosBox...

PS: Lokk I'm talking about the old versions of Game Wizard, not the new like Game Wiz 1.43 for Win32, cause this don save states, its only for cheathing.

hey guys... first thx fou all tha greAt work! now i can run flashback, syndicate and dune correctly and rock the games like i was a lil poop playing the games of the older brother..

but i dont understand how to quicksave the games... is there an quicksave implemented in dosbox or can i do something (codingless) ?

hmn.. without it , i go mad on flashback! i never can save and when i gotta go afk i cant shut down the game or else i got to do the whole lvl again.. grr.. i cant hold that!

u know smth to save?

just minimizing the window is a lil stressfull

thx!

staychilled
cia!O

Nope, DOSBox is very complicated and the authors didn't have quicksave/save state support in mind when they started developing it. As a result, it's going to be a very non-trivial task to implement such a feature.