Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.hardware Subject: Re: CHIP bus speed (was Re: RAMs for ehe A3000) Message-ID: <22359@cbmvax.commodore.com> Date: 12 Jun 91 18:16:22 GMT References: <618.28484461@busker.fidonet.org> <22124@cbmvax.commodore.com> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 43 In article ronald@ecl014.UUCP (Ronald van Eijck) writes: >In article <22124@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>The Chip bus is synchronous to Agnus. It runs a 560ns cycle, consisting of >>two 280ns memory accesses, one of which the CPU can use if the blitter, >>copper, or video fetch don't lock it out. The only way to let the CPU in for >>more cycles is to double the memory speed during the CPU access window. That >>would require a 140ns cycle and a faster Agnus. [..] Software has done more >>for system performance that this would, anyway, by moving as much as >>possible into Fast RAM... >Sorry to disagree with the master himself but my calculations give very >impressive numbers for a double speed chip memory system. I don't see any disagreement, just a question about what's considered "impressive" perhaps. Certainly a double-speed chip RAM system would be faster, but regardless, you're still better off getting the CPU out of chip RAM in the first place. >Asuming that you are using a hires 4 planes overscanned video the number of >memory slots the CPU/Blitter can use would be 8 (that is eight) times better >if the chip bus was 2 times faster. That's because video fetch will saturate the bus in a 4 plane hires overscanned setup, which is worst case. >The problem is that if the chip bus was 2 times faster we would all want 256 >colors and have a system the same speed we have now. Exactly. You might also want that hires 4 plane overscanned mode available at productivity scan rates. My point was and is, no matter how the chip bus bandwidth improves, if the video scan and fetch mechanisms improve to match it, there will be new display setups that saturate the chip bus with video fetch, and you're back at the beginning again. Anything we can do to give the CPU more chip bus bandwidth will help, in any case, and it's not something I would likely ignore if possible. But getting the CPU's attention away from chip RAM as much as possible will matter even more, and that's a software issue. -- 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.