Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!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: My A3000/25/50 seems a bit slow... Why? Message-ID: <21606@cbmvax.commodore.com> Date: 15 May 91 17:03:19 GMT References: <21451@cbmvax.commodore.com> <1991May13.201603.1388@cinnet.com> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 59 In article <1991May13.201603.1388@cinnet.com> kilian@cinnet.com (Kilian Jacob) writes: >From article <21451@cbmvax.commodore.com>, by daveh@cbmvax.commodore.com (Dave Haynie): >> This will always be the case on Amigas. Even with faster >> systems way in the future, Chip RAM will always be optimized for the needs of >> the video chips, while the Fast RAM will always be optimized for the needs of >> the processor bus (CPU, FPU, DMA for SCSI, whatever else lives here). >But it *was* not always true for the Amiga. Sure it was. The Chip bus has always been optimized for Agnus. Heck, it can kick the 68000 out for very long periods of time, should you crank display and blitter activity way up. Sure, when this activity was way down, you could interleave 68000 and Chip bus activity, but that's hardly a "feature", simply an indication of how slow the 68000 was. >I think the way the CPU/DMA CHIP RAM access is timed on a 68000 based Amiga >was *the* unique feature of the Amiga hardware. No it wasn't. Systems with "interleaved" video memory, in which the CPU and the video processor alternate cycles are very plentiful. They include the Atari ST, the Atari 800, the C64, C128, VIC-20, Apple II, etc. That method arose from the need to restrict the amount of memory in a system and still get video. It was realizable because memory was so much faster than either video or CPU requirements that a full speed video and CPU cycle could alternate and still not exceed the speed of the memory. Though even before the Amiga, this was already on the way out. The C128, for instance, could kick up to 2MHz mode, but that required switching off the memory shared video (VIC chip) and using only a register-based video controller with it's own private memory (the if 8563). There was plenty of uniqueness about the Amiga's video hardware, and for the most part, there still is. Most other system still don't provide anything like the Amiga bimmer or copper, nor do that provide slot driven DMA channels like the Amiga's. But the actual interleave of CPU and video subsystems was "old hat" in 1985, and like all other such systems, the Amiga's was optimized for video access. And it has to be -- you don't want your microprocessor to take a wait state, but it can. Any delay at all in video, audio, floppy, or copper fetch and it doesn't just get slower, it fails completely. >Well, it would have been rather expensive to reimplement this "perfect" bus >timing in a similar way on a 68030 based system. I think "impossible" might better describe it. Consider that, for a perfectly interleaved system, you need memory that cycles in half the cycle time of your video and CPU. A 25MHz 68030 cycles in 80ns, minimum. Assume you have a new, advanced, video processor that does likewise. That means you need memory that cycles in 40ns, possibly even faster. Typical DRAM cycles in just under twice its access time. So we're talking about 20ns DRAM here. If you have lots of money to spend, you can get 60ns DRAM, maybe 50ns in small quantities. 20ns is fast for even expensive SRAM. >Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.