[comp.sys.amiga.hardware] CHIP bus speed

ronald@ecl014.UUCP (Ronald van Eijck) (06/05/91)

In article <22124@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>No, the CPU access speed is the same, just 32 bits wide rather than 16 bits
>wide as on the A2000 and A500.  It doesn't make sense to refer to Chip RAM
>access as "7.16MHz" or "25MHz", since they really doesn't say anything about
>what's happening.  The CPU always runs at 25MHz (in a 25MHz system), it just
>takes waits states when accessing Chip RAM.  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.  That's not quite attainable yet.  When 60ns DRAMs become as
>cheap as 80ns, that may be something to consider.  Software has done more for
>system performance that this would, anyway, by moving as much as possible into

Sorry to disagree with the master himself but my calculations give very
impressive numbers for a double speed chip memory system.

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. This would make a lot of programs fly in
this mode. 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.
(So dave If you can find cheap 60 ns rams start working ;-)

>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.

--
  +-------------------------------------------------------------------------+
  |  Ronald van Eijck                  {eunet!}hp4nl!cbmnlux!ecl014!ronald  |
  |                                                                         |
  |  We do the impossible at once for a miracle we need a little more time  |
  +-------------------------------------------------------------------------+

daveh@cbmvax.commodore.com (Dave Haynie) (06/13/91)

In article <ronald.3804@ecl014.UUCP> 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.