Date: Tue, 8 Oct 1996 08:26:46 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "John M. Aldrich" <fighteer AT cs DOT com>
Cc: djgpp-workers AT delorie DOT com
Subject: Re: Stub error messages (Was: Re: 'Cannot open')
In-Reply-To: <3259DCC3.5BA2@cs.com>
Message-Id: <Pine.SUN.3.91.961008081127.4486H-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Mon, 7 Oct 1996, John M. Aldrich wrote:

> Well, I'm not entirely sure why it's necessary to wait between port
> calls in the first place, but is the timing that critical?

Yes, timing is important when accessing I/O ports.  Most modern CPUs can 
run circles around the slow peripherals, so if you don't wait a bit, you 
might get garbled data (because the peripheral didn't yet assemble it).  
My references suggest waiting about 1 microsecond between 2 accesses.  
Usually you will find a small assembly function that just loops for a 
while, but that immediately plunges you into CPU-dependency, and I didn't 
want to mess with that in my small hack thrown together during a lunch 
break.

> As I recall,
> sleep() works in millisecond increments, right?

I didn't want a function that requires a timer tick before it gets out of 
`sleep' (`sleep' reads the BIOS timer).  When I wrote the code, I was a 
bit scared by the warning about disabling interrupts (which I can't from 
a DPMI program), so I preferred something that will wait for much less 
than 50 msec.  Btw, `sleep' works with a second resolution; `usleep' uses 
a microsecond resolution, but since both call `clock' (which reads the 
BIOS timer), you cannot wait for less than 1/18.2 of a second, unless I 
missed something.

> Actually, another
> program I have uses a routine for microsecond timing, using the
> functions in <sys/time.h>;

Well, what's wrong with `uclock' which I used?  It does just that: read 
the 1.19 MHz clock counter.  That gives you 800 nsec resolution.