Slowdown functionality
Brought to you by:
bartoldeman
Menu
▾
▴
1 Attachments
#122 Slowdown functionality
This patch add the possibility to slowdown the DOSEMU execution with a command from inside the running DOSEMU. The amount and duration can be specified with parameters.
I'm using this for a program which crashes during the startup on fast CPUs but can run at full speed when loaded.
It has been tested with a statically linked binary on different distributions like Ubuntu >= 11.04, Mint >= 12 and others.
As there are better ways to implement this slowdown, I would appreciate any help from the DOSEMU mainteners.
Could you please move your code to
cputime.c and employ the CAN_SLEEP()
function?
Also, please explore the possibility
of using the VIP flag. It instructs
vm86() call to return sooner if the
interrupts are enabled.
Other than that I don't see a big
problems with your patch, if it works...
There is a game called "cosmo" that
was suffering from too high speed.
Please check if your patch fixes it.
I will move the "slowdown()" function to the "cputime.c". What I didn't understand is if I should move the call of the slowdown function too. Should it be moved out of the "loopstep_run_vm86()" function ? If yes, where would it go ?
Regarding the use of the "usleep()" function, what would be the prefered alternative ?
As I don't know the DOSEMU code too much, I'm a little bit lost at the moment...
OK, I guess its not that important
to move the code.
In this particular case perhaps there
are not too much alternatives to usleep,
but please at least use CAN_SLEEP() function.
See dosemu_sleep() as an example.
In other cases we use things like coopth_sleep()
or idle() from cputime.c, but in this case
they all look inappropriate...
Use this game to test your patch.
But I don't think it currently fixes
it. Many people tried, all failed. :)
Still, your patch looks like a step
forward.
Sorry, my memory was wrong.
Cosmo represents a different problem,
which is that the timer interrupts are
going in batches.
OKey, then I guess you can test the
famous turbo pascal's Runtime Error 200. :)
Ok, that would be fine. Do we have an EXE which can produce this error ? I've googled around, but all I find is information about TPPATCH and how to apply it.
I think I have them...
The problem is that the 64bit dosemu
has bug, and instead Runtime Error 200
you get a dosemu crash. So I am not
100% sure it is exactly that, but attaching
what seems to be it.
Do you have a 32bit system? Or a pure DOS
system? Then you should see Runtime Error 200
when running this.