From: bgilbert@cs.washington.edu (Ben Gilbert)
Subject: Re: Falcon BUS..
Keywords: Falcon 68030 bus memory
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Thu, 5 Nov 92 20:22:40 GMT

In article <1992Nov5.114927.14711@dcs.warwick.ac.uk> leo@dcs.warwick.ac.uk (Leo Hendry) writes:
>I asked questions similar to these a month or two ago, but nobody answered.
>Perhaps somebody knows the answers now.
>
>1) What is the speed of the Falcon's memory (Somebody said it had 0 wait
>states which seems to imply 16MHz, but they may have been wrong)

I'm not sure, but doesn't it have to be 16 MHz if it is on the same bus?
I should know this because I had a computer architecture class last
quarter, but they didn't go into specific implementations.  Or do you
mean to ask about the access time (such as 120 ns, 80 ns, etc)?  This might
be a more interesting detail.

>2) How does the DSP access the main memory (Somebody said it is not connected
>to the data bus, in which case I suppose it must be some kind of serial link)

Don't know on this one, but I think you're right in that it's not
connected to the data bus.  I guess the link must be sufficient if the
Falcon can grab true-color off the hard disk at 24 frames per second and
display it in real time.  :-)  Although maybe they didn't use the DSP for
that...   

>3) Does the TOS V4 use the DSP to speed up things (for that matter does it
>make intellegent use of the Blitter?)

The DSP is not used by the operating system unless you call it.  The SDMA
sound engine handles all the sound processing, meaning playing 16-bit
50KHz digitized sound can happen with no CPU loading, so that's one thing
you won't have to worry about.  The BLiTTER has been combined with a bunch
of other things on a single chip, and it now runs at 16 MHz.  The BLiTTER
is also used to feed the SCSI port DMA in order to speed up hard disk
access.  I imagine this helps a lot when doing direct-to-disk audio or
direct-from-disk audio/video (as in the Tina Turner video thing).  One more
thing : the DSP operates at 32 MHz and is rated at 16 MIPS.

>4) Is the data bus between the memory and the 68030 16 or 32 bits wide (There
>seems to be an argument going on about this).

The Falcon030 has a 32-bit data bus and a 32-bit address bus.  This _is_ a
32-bit computer, folks.

>5) Why does the benchmarks that I have seen posted here only indicate an
>approx 3x speed increase and real-world tests (excluding any disk access)
>only twice as fast?  If the data bus is twice as wide, the memory twice as
>fast, the processor at least twice as efficent and running at twice the clock
>speed it should be more like 10 times the speed.
>

Ok, some of those points are debatable :
	1) Yes, the data bus is twice as wide which overall should provide
	   a doubling of effective throughput.
	2) The memory twice as fast?  I don't know if this is true at all --
	   perhaps someone else can confirm/deny this.  I really haven't
	   seen any details about the speed/configuration of the RAM.
	3) The processor is twice as efficient?  Are you sure about this?
	   We all know the 68030 is a newer chip, presumably making it a
	   better design (and it also has more stuff, such as the MMU and
	   on-chip instruction and data caches), but you seem to be saying
	   the 68030 can execute the same code as the 68000 but in half the
	   number of cycles.  Frankly, I doubt this.
	4) Twice the clock speed is right, definitely.   That one's not
	   too hard to figure out.  :-)

   So, the way I see it, we'll have about a 4-5x speed increase, and maybe
more with heavy use of the co-processors (BLiTTER, DSP, SDMA), some of
which aren't even available on the ST or STe.
   Also, remember the Falcon video modes require up to two bytes per pixel,
which in 640x400 is 512K of screen memory to wade through.  On a positive
note, though, there have been reports saying that the Falcon's 640x480x256
mode appears as fast as the TT's 640x480x16 mode, which really is pretty
snappy, especially with Warp 9 installed.

>Thanks,
>Leo

Cheers,
-- 
Ben Gilbert				e-mail : bgilbert@cs.washington.edu
Department of Computer Science
University of Washington
Newsgroups: comp.sys.atari.st.tech