Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.advocacy Subject: Re: The Amiga's Future Message-ID: <22551@cbmvax.commodore.com> Date: 18 Jun 91 20:01:41 GMT References: <1991Jun15.112510.17324@news.iastate.edu> <1991Jun15.121453.5511@mintaka.lcs.mit.edu> <22516@cbmvax.commodore.com> <1991Jun18.021837.10276@mintaka.lcs.mit.edu> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 53 In article <1991Jun18.021837.10276@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <22516@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>>A 32-bit chipset wouldn't work on the A500 which is Commodore's bread and >>>butter of the Amiga line. >>A 32 bit Amiga chipset could live on a 16 bit machine just as easily as the >>current 16 bit chipset lives on the 32 bit A3000. No big deal, technically. > Let me clarify what I meant. As far as I know, no A500 shipped has >32-bit addressing on the motherboard. Unless I'm totally clueless here, >you can't make a 100% 32-bit chipset that will simply plug&play in >existing A500s. That's absolutely true. Same goes for the A3000, anyway, since the current custom chips only have 16 bit data paths anyway. However, the A3000's chip RAM _architecture_ might only need minimal changes for such a chip set, assuming it was designed looking reasonably similar in other ways to today's Agnus, Denise, and Paula. And since CPU access to the chip bus is not really part of the A/D/P design, but a system issue (handled by Gary and two PALs in the A3000), there's no reason you couldn't chop that 32 bit design out of your 32 bit computer and drop it into the 16 bit system with a few minor changes to the CPU access logic. >Sure you could always release a 32-bit chipset daughterboard >which has it's own onboard 32-bit chipram, but anything that >drives up the price of A500 significantly isn't going to do so well. Not driving up the price of the low end is a primary concern for the low end designers. Ideally, any high end technology that's developed should be able to find its way to the low end, but it won't always happen over night, and you can't expect tomorrow's 32 bit chip set to cost less than today's 16 bit chip set at any point. All I'm saying is that it's not impossible, from the technical point of view, to adapt high end stuff for the low end, but price will often preclude that (like, why you don't see 68030s in A500s now, and probably won't for many years to come). >BTW, If C= does do a 32-bit chipset, they should add in another >co-processor like a cheap RISC processor or an ARM. I'm all for additional processors, as long as I can justify the expense (eg, it does something useful, it's not just "way cool") and make sure it integrates into the system. Hardware wise, there are boatloads of neat processors out on the market: RISC, DSP, Math, Graphics, etc. Anything too expensive to neatly mesh with the system is always better as an add-on; you don't want an expensive feature 5% of your buyers will use dragging down the rest of the system by inflating the price. On the other hand, if something neat and relatively inexpensive will have the overall effect of attracting people to your system, it's worth looking into. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "This is my mistake. Let me make it good." -R.E.M.