Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdcad!diablo!phil
From: phil@diablo.amd.com (Phil Ngai)
Newsgroups: comp.sys.ibm.pc
Subject: Re: AMD 8237 feature
Message-ID: <28255@amdcad.AMD.COM>
Date: 5 Dec 89 01:54:10 GMT
References: <1247@adds.newyork.NCR.COM> <28150@amdcad.AMD.COM> <782@ursa-major.SPDCC.COM>
Sender: news@amdcad.AMD.COM
Reply-To: phil@diablo.AMD.COM (Phil Ngai)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 25

In article <782@ursa-major.SPDCC.COM> eli@ursa-major.spdcc.COM (Steve Elias) writes:
|	believe me, some of us were working on software back then
|	that did expose the problem in a big way.  not an easy bug
|	to find.  we couldn't afford an in circuit emulator for 8088,
|	even if there was around that worked...

Sorry to hear that. I meant there wasn't any piece of software which
was popular enough to force all the clone makers to wake up and handle
the problem. 

|	what is the motherboard patch which precludes this bug?

As I understand it (I haven't actually done this) the problem is that
the Read and Write lines on the old 8237 were not gated with the CS
line. There is a recovery time on either or both of the read and write
lines and a read or write which are too close together can violate
this recovery time EVEN when not addressed to the 8237.  The solution
is to use two AND gates to condition the read and write lines going
into the 8237 so that they only go active if CS is also active. 

As a user, I think I'd just swap the 8237 for a newer one. They
can't be very expensive.
--
Phil Ngai, phil@diablo.amd.com		{uunet,decwrl,ucbvax}!amdcad!phil
AT&T Unix System V.4: Berkeley Unix for 386 PCs!