Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rochester!pt!b.gp.cs.cmu.edu!ralf
From: ralf@b.gp.cs.cmu.edu (Ralf Brown)
Newsgroups: comp.sys.ibm.pc
Subject: Re: millisecond timing
Message-ID: <65@b.gp.cs.cmu.edu>
Date: Tue, 21-Jul-87 13:56:57 EDT
Article-I.D.: b.65
Posted: Tue Jul 21 13:56:57 1987
Date-Received: Thu, 23-Jul-87 02:40:19 EDT
References: <4343@jade.BERKELEY.EDU> <182@titn.TITN>
Organization: Carnegie-Mellon University, CS/RI
Lines: 27

In article <182@titn.TITN> herve@titn.TITN (Herve Siegrist) writes:
>
>It looks to me that there is a much better way to control timings on
>an AT, as the BIOS provides some neat functions for that. All this 
>is in the interrupt 15H for the cassette I/O. Two timing functions
>are provided, the function code beeing provided in AH:
[details omitted]
>This provides a nice way to get timing information with a microsecond 
>resolution. I should say however that I never tried to use that myself...
>
>FROM:	Herve Siegrist, TITN Inc.  24301 Southland Dr. Suite 200
>	Hayward, CA 94545	Tel: (415) 785-5970
>UUCP:	(decvax|ucbvax|ihnp4)!decwrl!sun!dlb!plx!titn!herve

Unfortunately, though the docs say microseconds, the actual resolution is only
977 microseconds, as these functions use the 1024/sec interrupts from the
real-time clock.  Thus the actual delays get rounded up to the next highest
multiple of 977 (plus some overhead in the BIOS code).


-- 
-=-=-=-=-=-=-=-=-=-= {harvard,seismo}!b.gp.cs.cmu.edu!ralf =-=-=-=-=-=-=-=-=-=-
ARPA: RALF@B.GP.CS.CMU.EDU                  USnail: Ralf Brown
BIT:  RALF%B.GP.CS.CMU.EDU@CMUCCVMA                 Computer Science Department
AT&T: (412) 268-3053 (school)                       Carnegie-Mellon University
DISCLAIMER?  Who ever said I claimed anything?      Pittsburgh, PA 15213
"I do not fear computers.  I fear the lack of them..." -- Isaac Asimov