Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!isc-br!jimc
From: jimc@isc-br.ISC-BR.COM (Jim Cathey)
Newsgroups: comp.sys.mac.programmer
Subject: Re: The 80486 is braindead (was Re: Xerox sues Apple!!!)
Message-ID: <2690@isc-br.ISC-BR.COM>
Date: 8 Jan 90 22:08:56 GMT
References: <14960@boulder.Colorado.EDU> <213@amix.commodore.com> <25347@ubvax.UB.Com> <9378@hoptoad.uucp> <25470@cup.portal.com>
Organization: ISC Systems Corporation, Spokane WA
Lines: 48

In article <25470@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes:
>Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com says:
>> Huh?  I've used TAS instructions within the last two years and they've
>> worked, though not lately.  I don't see how Apple could break part of
>> the hardware instruction set; I'm pretty sure they use standard
>> off-the-shelf 68K processors with no custom microcode.
>
>It should be possible to "break" TAS on a standard 68000 if the
>/DTACK generation logic determines when to deassert /DTACK by
>looking at /AS.
>...
>The logic that generates /DTACK wants to know when the 68000 has the
>data so that /DTACK can be unasserted.  The simplest way to do this
>is to look at /AS.  The more complicated way is to look at both
>/UDS and /LDS ( an extra AND gate!  Gotta watch those pennies...:-) ).

UDS and LDS come out much later than AS on write cycles, so they aren't useful
under a lot of circumstances (unless you like lots of wait states). 

>A read-modify-write cycle is similar, except that after the 68000 has
>gotten the data, it deasserts /UDS and /LDS, but does *NOT* deassert
>/AS.  It then waits for /DTACK to be deasserted.  The data is then
>placed on the bus and /UDS and/or /LDS are asserted.  When it gets
>/DTACK it will deassert /AS, /UDS, and /LDS.
>
>If the logic that generates /DTACK is watching for /AS to be deasserted
>to know when to deassert /DTACK, a read-modify-write cylce will hang
>it up, since /AS will not be deasserted!

That's not the only problem possible, nor even the worst!  Depending on
the way the memory timing is generated, a TAS cycle can totally screw
up RAS and or CAS to the memory which will cause corruption of 'random'
parts of memory.  Designing memory timing logic that will work _at full
speed_ for all the cycle types isn't trivial, especially when it's the
first time you've worked with the 68000, and even more so when you're
trying to keep the cost down by avoiding expensive delay lines.  [It
can even be very confusing to talk about since there're three different
read-modify-write sequences: CPU bus cycle (TAS), instruction (ADD,
BCLR, etc.), and the DRAM's own RMW cycles.]

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc (jimc@isc-br.iscs.com)
! II      CCCCCC !  (509) 927-5757
+----------------+
			"With excitement like this, who is needing enemas?"