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