Timing problems

Timing problems

[John Coppens]

Hi all.

I was trying to install a very old DOS data acquisition program for a
friend of mine (under Linux + DOSEMU), but there seem to be strange
timing problems.

After many unsuccessful tests (the link with the sensor wouldn't even
come up), I started suspecting timing issues. I booted the machine with a
real DOS disk and sure enough, everything worked.

I suspect this program uses the DOS 18.xxx Hz timer for its loops. Is the
emulation of the timer under DOSEMU the same frequency? Does it depend on
setting up the 250/1000 tick/s of the kernel?

Thanks in advance!
John

Re: Timing problems

[Clarence Dang]

On Wednesday 20 June 2007 15:08, John Coppens wrote:
> I was trying to install a very old DOS data acquisition program for a
> friend of mine (under Linux + DOSEMU), but there seem to be strange
> timing problems.
>
> After many unsuccessful tests (the link with the sensor wouldn't even
> come up), I started suspecting timing issues. I booted the machine with a
> real DOS disk and sure enough, everything worked.
>
> I suspect this program uses the DOS 18.xxx Hz timer for its loops. Is the
> emulation of the timer under DOSEMU the same frequency? Does it depend on
> setting up the 250/1000 tick/s of the kernel?

DOSEMU can handle about 100 Hz for the PIT.

I have a patch I can dig up that can go up to 250 (or even 1000 depending on 
the kernel version).  It's just a quick hack and not the proper solution 
though.

Re: Timing problems

[John Coppens]

On Fri, 22 Jun 2007 17:40:42 +1000
Clarence Dang <clarencedang@yahoo.com> wrote:

> On Wednesday 20 June 2007 15:08, John Coppens wrote:

> > I suspect this program uses the DOS 18.xxx Hz timer for its loops. Is
> > the emulation of the timer under DOSEMU the same frequency? Does it
> > depend on setting up the 250/1000 tick/s of the kernel?
> 
> DOSEMU can handle about 100 Hz for the PIT.
> 
> I have a patch I can dig up that can go up to 250 (or even 1000
> depending on the kernel version).  It's just a quick hack and not the
> proper solution though.

Hi Clarence,

Thanks for the reply, and my apologies for the delay in confirming...

In reality, the problem is the other way around - I have the impression
that DOSEMU is using anything but 18.29 Hz. At least the program is not
responding the same way under DOSEMU as in real DOS, which causes the
login sequence to fail.

It's rather strange really - using the normal serial port, I get one kind
of behaviour, and using an USB to serial converter, DOSEMU responds
completely differently (none of them correct). I'm somewhat at a loss
where to look for solutions here...

John

Re: Timing problems

[Clarence Dang]

On Tuesday 26 June 2007 11:33, John Coppens wrote:
> On Fri, 22 Jun 2007 17:40:42 +1000
>
> Clarence Dang <clarencedang@yahoo.com> wrote:
> > On Wednesday 20 June 2007 15:08, John Coppens wrote:
> > > I suspect this program uses the DOS 18.xxx Hz timer for its loops. Is
> > > the emulation of the timer under DOSEMU the same frequency? Does it
> > > depend on setting up the 250/1000 tick/s of the kernel?
> >
> > DOSEMU can handle about 100 Hz for the PIT.
> >
> > I have a patch I can dig up that can go up to 250 (or even 1000
> > depending on the kernel version).  It's just a quick hack and not the
> > proper solution though.
>
> In reality, the problem is the other way around - I have the impression
> that DOSEMU is using anything but 18.29 Hz. At least the program is not
> responding the same way under DOSEMU as in real DOS, which causes the
> login sequence to fail.

Internally, DOSEMU is ticking at 100Hz 
[src/base/init/init.c:timer_interrupt_init()] but from a DOS program's point 
of view, it will correctly appear to be whatever the emulated PIT is set to 
(e.g. 18.2Hz).  Emulation of anything less than 100Hz should be fine.

> It's rather strange really - using the normal serial port, I get one kind
> of behaviour, and using an USB to serial converter, DOSEMU responds
> completely differently (none of them correct). I'm somewhat at a loss
> where to look for solutions here...

Maybe setting $_hogthreshold to 0 will help (lets DOSEMU use as much CPU as it 
likes).