Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!think!husc6!endor!siegel From: siegel@endor.harvard.edu (Rich Siegel) Newsgroups: comp.sys.mac Subject: Re: 68000 vs 68020 Message-ID: <2198@husc6.harvard.edu> Date: 11 Jul 89 14:39:16 GMT References: Sender: news@husc6.harvard.edu Reply-To: siegel@endor.UUCP (Rich Siegel) Distribution: comp Organization: Symantec/THINK Technologies, Bedford, MA Lines: 52 In article sarrel@sioux.cis.ohio-state.edu (Marc Sarrel) writes: >SE. How much performance difference is there between a 16MHz 68000 >and a 16MHz 68020? Roughly a factor of two, on the side of the 68020. >problems. You have to buy more memory to put on the separate board to >take advantage of the wider data path and at least one manufacturer The Radius Accelerator 16 for the Mac Plus doesn't require additional memory; it has a 32K SRAM cache for performance, with no sockets for additional memory. This was a win for Radius (IMHO) for two reasons: - When SIMMS were in short supply, they were one of the few accelerator makers who were able to keep up their volume of boards. - Not relying on SIMMs for additional memory keeps the cost down. >expensive). There were also compatability problems. Even some >software that would run on a Mac II, would not run on a Plus with some >68020 accelerators. The Radius Accelerators are fairly compatible; the new ROMs for the Plus model are a big improvement. >Are 68000 accelerators a cost effective alternative? Can you get It depends on the performance. 68000 boards to tend to be half the price, but they're also have the speed. Besides that, a 68020 board with a 68881 or 68882 sitting on its coprocessor bus will do floating point much faster than a 68000 with the FPU mapped in as a peripheral. I have no association with Radius except as a satisfied customer and occasional beta site. -Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel I classify myself as a real developer because my desk is hip-deep in assembly-language listings and I spend more than 50% of my time in TMON. ~~~~~~~~~~~~~~~