DOSBox provides a PIT emulation that should cover typical uses, including the default/standard ~18.2Hz (~55ms) interval. Why not go ahead and try it with your app? Keep in mind that DOSBox is intended for games, but maybe your app will work.

We're doing 9600 baud serial communication and using the 55 mSec timer to determine the end of a mod bus packet, the application gets out of sync.
I have the source listing if it would be any help to see how we're accessing the timer?

Some improvements have been made in SVN regarding serial comm., so maybe try a development build to see if your app works any better. Can't be certain of this, but since you're using the standard timer interval, an issue with serial comm. seems more likely than with timing.

Also, just to get this out of the way, how are you configuring the serial port in DOSBox?

Serial 1 = directserial realport:com1

[Thread moved to DOSBox Games/Apps. Section]

DOSBox can't emulate this sort of hack.

DOSBox works like this: run for a part of a millisecond, pause, run again, pause, later it has something else to do than CPU emulation so doesn't process at all, then the operating system needs some time for itself... it is not in sync with what the serial port does. The serial port driver of the operating system may have its own idea of when to send data, and if you add USB you get the polling interval that throws you off. The internal time of DOSBox is not synced to the actual time, so overloading or longer execution adds more de-syncing.

A lot of factors...

We're not using a USB dongle serial port, but the actual hardware com1 port.
I notice your Megabuild6 supports FIFO serial communications.
Our DOS application uses the FIFO of the com port.
It comes down to whether it's the com port or the 55 mSec timer that is causing the problem.
We're trying to determine if DOS BOX can or can not access the 55 mSec tick of days past, or has the hardware mutated into something that can not be accessed any longer?
Others have had good success using your Megabuild6 with serial applications.

Do you think we're out of luck on this one?

The timer is emulated. The real hardware timer is not used for that.

So I do have some form of 55 mSec timer available to me, even if it is a virtual timer? I suppose we could be calling a hard address, and not using the virtual timer.

Here are the defines in the "C" language.

/* 18.2 Hz counter */

#define CLK_SEG 0x040 /* 55 msec. counter segment */
#define CLK_OFFSET 0x06C /* 55 msec. counter offset */

It then uses the following statements:

tm = peek( CLK_SEG, CLK_OFFSET ) + dly; /* time-out value */

We're screwed aren't we?

You're screwed anyways if you're trying to use a games-targeting emulator to drive some strange hardware.

There is a ton of legacy equipment out there based on DOS, you might have a market there.

DOSEmu would likely be a better fit than DOSBox.

motorhead wrote:

There is a ton of legacy equipment out there based on DOS, you might have a market there.

Yes, there definitely is a market for legacy equipment using companies.
But Dosbox is aimed at games and not at companies running mission critical stuff in an emulator. Plus, they tend to pay badly and ask for good support 😉

DOSBox emulates the timer tick counter your app is using; but it appears you're relying on a tighter relationship than DOSBox has between the timer and what is going on with the serial port.

If modifying the app is not out of the question, maybe the device you're interfacing with offers some hardware (DTR/DTS) or software (XON/XOFF) flow control you can use instead of timing.