Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!van-bc! From: lphillips@lpami.wimsey.bc.ca (Larry Phillips) Newsgroups: comp.sys.amiga Subject: Re: 68040 vs 80246 (Was Re: Xerox sues Apple!!!) Message-ID: <936@lpami.wimsey.bc.ca> Date: 20 Dec 89 11:23:36 GMT Lines: 38 Return-Path: To: van-bc!rnews Keywords: In <1617@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) writes: >In article <824@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >> >>Does anyone have any more horror stories? >> > >How about the inconsistancy between 68000 & 68010? (Specifically the MOVESR >problem). The 'inconsistency', as you call it, is a bug fix. Is it a big deal for you? Was it worth leaving in the machine so future genrations of the chip would have to have ever more kludges to work around the problem? >For myself, I prefer the Intel approach - that is, make the successors >have exactly the same bugs as well. That way, a pin-compatible '010 will >really be pin-compatible. You are one sick puppy. You remind me of the fellow with the broken watch who won't get it fixed because he is used to the way it loses time, and having one that worked would only confuse him. >How about the '020 MMU being a subset of the '851 MMU? Not a bug, but >certainly an extremely undesirable feature for a later member of any >architecture family. Undesirable feature? How would you suggest implementing the I/O stuff, when the MMU has been moved inboard and made inaccesible to the I/O? Tell me.. how many 8080's are in the latest CPU array from Intel? -- " All I ask of my body is that it carry around my head." - Thomas Alva Edison - +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+