Comment on why some games may run too fast in NTVDM

[MugenFighter]

A while ago I tested the 1st Mega Man DOS game and mentioned it ran too fast. Some more tested with the same game and another and both FreeDOS and DOSBox relieved that some DOS games (mostly older ones) will one on the max available cycles with no means of slowing down. The only way to fix the speed issue would be to slow down the cycles of the cpu. Just thought anyone testing programs for the NTVDM should know.

[PurpleGurl]

You'd only have to slow down the virtual CPU or the time slices getting to it. You would not have to slow down the real CPU.

[Konata]

Does NTVDM have a virtual Turbo button? Might be a helpful addition.

[MugenFighter]

You'd only have to slow down the virtual CPU or the time slices getting to it. You would not have to slow down the real CPU.

I don't think I mentioned anything along the lines of real or virtual, just trying to correct something I said in the past. But, quick question: Can you do that in ReactOS's NTVDM?

[PurpleGurl]

I don't think I mentioned anything along the lines of real or virtual, just trying to correct something I said in the past. But, quick question: Can you do that in ReactOS's NTVDM?

I was speaking in general and from a design perspective. I don't think the end user can, but we'd need to ask the devs.

[hbelusca]

Answer: currently our timing emulation is quite inaccurate (because we haven't focused on it, but just enough so that keyboard & mouse IRQs are almost correctly emitted), we don't compute time slices etc... : we are in fact always in "turbo mode" i.e. we always execute as many instructions as we can. It is planned to be improved, but not before a certain time.

[MugenFighter]

Answer: currently our timing emulation is quite inaccurate (because we haven't focused on it, but just enough so that keyboard & mouse IRQs are almost correctly emitted), we don't compute time slices etc... : we are in fact always in "turbo mode" i.e. we always execute as many instructions as we can. It is planned to be improved, but not before a certain time.

Thanks, I've had a lot of stuff happen lately (my grandma has been sick and died, and my grandpa on the other side of the family has been sick), so I haven't really had time to test programs or do proper research, but I still wanted to point that out because I didn't know if anyone knows of anything that could be done now in ReactOS.

[PurpleGurl]

An end user could get a slow-down TSR and make sure it is loaded before their game. DOS used TSR (terminate and stay resident) programs that stayed resident and hooked onto interrupts to do certain things. In a way, they functioned much like services. Some of the TSR type programs included programs to slow down the computer. After you played your game, you could uninstall the TSR if it has that option as a command line option. And if you do it regularly, then you might want to make a batch file which loads the TSR, loads the game, then uninstalls the TSR when the game terminates.

[MugenFighter]

An end user could get a slow-down TSR and make sure it is loaded before their game. DOS used TSR (terminate and stay resident) programs that stayed resident and hooked onto interrupts to do certain things. In a way, they functioned much like services. Some of the TSR type programs included programs to slow down the computer. After you played your game, you could uninstall the TSR if it has that option as a command line option. And if you do it regularly, then you might want to make a batch file which loads the TSR, loads the game, then uninstalls the TSR when the game terminates.

Thanks.

[Forever Winter]

An end user could get a slow-down TSR and make sure it is loaded before their game. DOS used TSR (terminate and stay resident) programs that stayed resident and hooked onto interrupts to do certain things. In a way, they functioned much like services. Some of the TSR type programs included programs to slow down the computer. After you played your game, you could uninstall the TSR if it has that option as a command line option. And if you do it regularly, then you might want to make a batch file which loads the TSR, loads the game, then uninstalls the TSR when the game terminates.

If you can control the emulation speed anyway, it seems more user friendly to just put an extra option in the pif editor that lets the user select the desired cycles per second and saves it to the program's pif file (Like an advanced version of the virtual turbo button as mentioned by Konata). This way there is no need to mess around with a slowdown tsr.

[PurpleGurl]

True on the .pif file thing. However, this is a workaround for now, just like in MS-DOS days... I remember having an XT clone that ran double the speed of the original and had a button to put it around 4.77 MHz for certain programs. But then I removed the 8088 and put the V20 in there, and even slow mode was a bit fast for some things. One of the crucial differences in the 2 CPUs was that the multiplier was totally in hardware, and not microcode. Changing how 1 instruction was implemented greatly helped. The V20 used a smaller design and had more room to work with.

Then when that board fried the chipset, I put a 286 board in there and couldn't believe how much faster it was. I didn't understand how 6 MHz faster could account for the difference. But there were a number of differences. Not only was it clocked faster, but it was true 16-bit (not 8/16 hybrid) -- so no internal vs. external bottleneck, some of the microcoded instructions were given dedicated hardware, and the address and data lines were separated rather than multiplexed.

Yes, I drifted topics a bit, but it was under DOS and it was a matter of choosing different programs or using a TSR.

[sv00010]

This is a general problem. I remember to run a game from 386-times on a pentium.
Some games run normal and some games run to fast. I think the kind of programming the game is relevant for this problem.

[PurpleGurl]

This is a general problem. I remember to run a game from 386-times on a pentium.
Some games run normal and some games run to fast. I think the kind of programming the game is relevant for this problem.

That is correct. In real mode on standardized hardware, you can use loops to control the timing.

For instance, in QBASIC

For X = 1 to 1000:Next X

The problem with that is that different machines will execute this at different rates. At one time, that would take a second or longer to execute, but now, that is almost instantaneous.

Then I discovered a way to use the V-blank pulse, either that, or the lowest byte of the system timer, that was recorded in a a few bytes in the system segment. So I'd make a loop waiting for the lowest byte in it to change and then loop through the desired number of times. So it would be accurate to 1/18 a second on nearly any machine. I used the Peek command to get it, not use the Timer command, since Timer would pull in the floating point set. If you are using Timer to poll for changes rather than actually use the numbers it returns, that is pretty much a waste. So seeing if a byte has changed takes less code.

[erkinalp]

The only way to fix the speed issue would be to slow down the cycles of the cpu.

Trap on Virtual DOS Machine's all memory region, single step an instruction every 2µs and trap it again. Problem solved.