well you can limit dosbox in it's usage (low cpu cycles, minimize screen/ high frameskip) So the application uses less power. But dosbox doesn't allow low level acces to your modem so I think that is a problem.

...so you're saying that when the app tries to open a modem on com2: it can't be mapped/allowed?

FYI I have 2 such servers - one with a dumb old USR modem on com2:, and another with a Lucent Win Modem mapped to com2:.

As a performance issue for DOSBOX, you might find it useful to detect wait-loops where the CPU just spins null ops, while it waits for input. In OS/2, there was a detection mechanism that was adjustable, and it made a big difference on the dos emulation. You might find it useful to detect and adjust for such wait loops fro DOSBOX.

BTW - thanks for the very prompt reply

drone wrote:

...so you're saying that when the app tries to open a modem on com2: it can't be mapped/allowed?

Indeed. Maybe in the future but there are no plans for it. (our virtual modem is present on com2

drone wrote:

As a performance issue for DOSBOX, you might find it useful to detect wait-loops where the CPU just spins null ops, while it waits for input. In OS/2, there was a detection mechanism that was adjustable, and it made a big difference on the dos emulation. You might find it useful to detect and adjust for such wait loops fro DOSBOX.

Well lot's of games are programmed that way. They actuall act on the timer. I think the overhead of detecting it would slow dosbox down and that's not worth it.
(DOSBox doesn't aim for emulation for programs (used by companies in servers) It aims on single user-machines wanting to play an old dosgame.

Well lot's of games are programmed that way. They actuall act on the timer. I think the overhead of detecting it would slow dosbox down and that's not worth it.

In actual fact programs that rely on timers can differ, with some games estimating wait periods by having an estimate based on the estimated CPU speed, and the programmers "experience" or program tests with the running of empty loops.

loop a zillion times
NOOP
endloop

Those programs that calculate pauses based on spinning empty loops can fall prey to the variety of ways in which newer CPUs handle optimizations. It is only those programs that "need" detection. As for the trouble of detecting such loops, I suspect there are only a few constructs that need to be caught.

If you run into problems with some games, then perhaps you can keep this in mind, and consider whether a timing loop issue might not benefit you at some future time.

(DOSBox doesn't aim for emulation for programs (used by companies in servers) It aims on single user-machines wanting to play an old dosgame.

Touche. Ne'ertheless, if it worked, I would have used it. Ah well.

Perhaps I'll use DOSBOX to try to ressurect the ancient DOS SHOOT! game for my wife who misses blasting old west icons with a mouse-pistol. CPUs faster than 30 MHz made its timing routines "lumpy" and unusable.

Thanks anyway!