Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!mailrus!cornell!uw-beaver!zephyr.ens.tek.com!tektronix!sequent!norsk
From: norsk@sequent.UUCP (Doug Thompson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: .84 usec Timer resolution on PC (actually jmp $+2)
Message-ID: <25893@sequent.UUCP>
Date: 6 Dec 89 01:20:49 GMT
References: <3056@cbnewsl.ATT.COM> <2685@optilink.UUCP> <57@qmsseq.imagen.com>
Reply-To: norsk@crg2.UUCP (Doug Thompson)
Distribution: usa
Organization: Sequent Computer Systems, Inc.
Lines: 24

In article <57@qmsseq.imagen.com> pipkins@qmsseq.UUCP (Jeff Pipkins) writes:
>The IBM AT Tech. Ref. manual says that successive IN and OUT
>instructions, which "lock the bus" can starve out DMA transfers.
>Do any of you hardware guys know more about this?
>
>It seems to me that if I were making an AT compatible machine that
>was faster, it would have to run AT software WITHOUT MODIFICATION
>in order to be anything but worthless.  This means that the designers
>should compensate for only getting one Jmp short +2 instruction
>between INs and OUTs.  Someone please tell me this is true.  While
>you're at it, maybe you can tell me that it was all a mistake and
>that IBM never really screwed up this bad in the first place... @;-)
>

Compaq I believe has the necessary hardware that detects such IO
accesses and automatically does the required waiting (at least on
my 20/e) and IBM did screw it up - just look at the BIOS source code
in your Tech-o-Ref manual and you'll see it peppered with 'em.

-- 
Douglas Thompson		UUCP: ..{tektronix,ogcvax,uunet}!sequent!norsk
Sequent Computer Systems	Phone: (503) 526-5727
15450 SW Koll Parkway	!"The scientist builds to learn;the engineer learns in
Beaverton OR 97006	!order to build."  Fred Brooks