From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware,comp.sys.amiga.advocacy
Subject: Re: Atari Falcon (wasn't: Amiga Falcon)
Date: 16 Apr 92 22:32:00 GMT
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA

In article <1992Apr14.001701.546@imada.ou.dk> micro@imada.ou.dk (Klaus Pedersen) writes:

>>>Where's the time going? The TT and SST using fast RAM do 4/1/1/1 bursts.
>>>TT at 32MHz, SST at anywhere from 25 to 50MHz.

>daveh@cbmvax.commodore.com (Dave Haynie) writes:
>
>>The hell they do.  The TT (I dunno anything about any SST) ran a 32MHz 
>>processor connected to a 16MHz memory design (in fact, the original TTs had
>>this hacked in as a tower, though eventually they put the circuitry on
>>the motherboard).  [..details deleted..]

>They do use nybble mode RAM. The Slow ram in a TT is 64 bit wide and can be
>accessed 4 times per micro sec. That is 8 32 bit words per uS. 

That may be the way the video controller hits it, but that would also be 
useless for CPU burst mode.  First of all, a 250ns random+burst won't get
get you anywhere.  A 16MHz memory system needs 240ns for a four clock 
random access, 60ns per one-clock burst.  That's a total of 420ns per burst,
and it can't be interrupted by video fetch or you lose the page and thus any
reason to run burst in the first place.  This translates to an 8-2-2-2 burst
at 32MHz.

However, I'm pretty sure they aren't running burst cycles into video memory.
The whole concept of video memory, anyone's video memory, implies strict
determinism in the video controller to memory path.  You can't hold off a
fetch, not even for a nanosecond, or the video fetch fails.  So you wind up
with "slow" (Atari) or "Chip" (Amiga) or "Bank A" (Apple IIci) memory which
doesn't support any clever CPU tricks.  

>If what you say is true then Fast ram is slower than Slow ram.
>That is what is needed to do 1280x960 noninterlace 70Hz or 320x480x256 
>noninterlace 60Hz! 

Again, video memory in these aforementioned systems is fast w.r.t. the video
controller.  Amiga video chips have twice the bandwith to Chip RAM that the
CPU has in most systems.  The memory is optimized for video access rather
than CPU access.  To handle 320x480x256 or any similar mode, the ST "slow"
needs an 8x improvement over the original ST, which could do nominally 320x200
with 16 bits/color.  The same total memory cycle timing with burst and a 64
bit bus rather than a 16 bit bus will do just that.  

>Remember that the TT comes _standard_ w. a 32MHz 68882!

Remember that floating point applications are at best 30% floating point
instructions.  And that both floating point and integer instructions depend
very heavily on memory speed in a 68030 system.

>Here is the original post from atari Aug 89
>From: apratt@atari.UUCP (Allan Pratt)
>Date: 31 Aug 89 01:19:58 GMT
>Organization: Atari Corp., Sunnyvale CA

Yup, August '89.  Keep in mind that Atari didn't announce the speedup to
32MHz until much after that (I think it was, suspiciously enough, after the
Amiga 3000 launch of April 1990, but I don't have a reference date).  So
all the memory speed numbers Allan is talking about here apply to the 16MHz
system, just as I stated.

>For dual-purpose RAM, around half the bus cycles go to the 
>video or refresh.  Therefore, the CPU gets around two million MEMORY
>ACCESSES per second, or 2MHz.  There are other architectural details
>which make it a little faster than that.  And remember, each access
>gets you 32 bits, not 16 as on the ST.  

Eg, no burst.  

>"Fast" RAM does not have video taking up any of the cycles, so you
>don't have to wait for that.  It takes 4 or 5 clocks (I think) to set
>up a fast-RAM access, but "nybble mode" means that the CPU fills its
>cache in "burst mode" at one cycle per subsequent access.

With Page-Mode or Static-Column memories (such as used in the A3000), you 
can get 4-2-2-2 at 16MHz or 5-2-2-2 at 25MHz.  The TT here running with 
nybble mode parts better well get 4-1-1-1, but as I said before, that's 
8-2-2-2 at 32MHz.  At it requires 4MB banks of RAM, rather than 1MB, at 32-bit
bus widths.

>The VME logic introduces one wait state, so a VMEbus access takes 5
>clocks. (Your mileage may vary: VME cards vary widely in response
>time.)  

VME-16 is a joke.  Even if the TT can hit it at 5 clocks, the majority of those
cards in the TT form factor (3U, as I recall) are really old and much slower
than that.

>>Does it have a Blitter ?

>No need for one.  The reason for the Blitter is to remove instruction-
>fetch overhead from memory operations, and with the 68030 on-chip
>cache, the TT does just fine without it.

That reflects a flaw with the ST blitter, not blitters in general.  Much the
same as the difference between the on-board DMA of the PC Clone and DMA used
by Amigas and I guess the DMA port on TT/ST (don't know all that much about
the latter).  The ST blitter could run, OR the CPU could run.  They sat on the
same bus.  If the CPU could have done the job better, the blitter would have
been redundant.  An Amiga blitter can run at the same time as the CPU, so as
long as their resource requirements don't conflict, you get roughly twice as
much work done when the blitter's working.  This is also true of most graphics
processors (Weitek blitter, XGA blitter, TI GPU, etc).  
-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      BIX: hazy
      "What would they do if I just sailed away?" -Jimmy Buffett
 
Xref: sparky comp.sys.amiga.hardware:8585 comp.sys.amiga.misc:8295