From: gblock@csd4.csd.uwm.edu (Gregory R Block)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: REAL FALCON 030 SPECS
Date: 2 Oct 1992 08:13:21 GMT
Organization: University of Wisconsin - Milwaukee
Distribution: world
NNTP-Posting-Host: 129.89.7.4

Chris_Millar@lppl.mi.org (Chris Millar) writes:
: Ok, I've had it up to here with all of the slandering the Falcon has taken
: because of it's shared processor/video bus.  I was arguing from the
: viewpoint that you already knew how the ST's architecture worked, but I was
: mistaken, SO, here is why everything is just fine with thre shared bus.

Not.  Cycles aren't "imaginary", pal.  If one system is taking some,
then the other system is losing something that it could have all of.
Are you trying to say that a 68030 couldn't go faster with full access
to ram rather than every other access?

: The ST uses 16Mhz memory - utilizing 8Mhz for the processor, and 8Mhz for
: the video - this worked out great in the old ST's, and the processor worked
: at full capacity......So, the TT came along, and it just so happened that

WOW.  16Mhz.  I'm, like, totally shocked.  I'm not sure whether you
mean 16-bit memory, 160ns ram, I don't know.  Anyways, that's not
important.  We'll assume it's not important, and we'll be right.
Because even if it had been using 120ns 16-bit ram, if you're taking
away half the cycles for your graphics system, you're leaving half
behind for your main processor.

: the bandwidth for the new TT modes far exceeded the capabilites of the ST's
: way of handling video, even when using 32Mhz memory - it cuts such huge

I just don't know what to say.  32MHz memory?  Anyways, again...

: chunks outm of processor time it is unbelievable - SO, Atari reworked the
: way it worked for the TT - using 32 bit memory (as in the Falcon - NOT
: Burst mode) the memory is mapped in such a way that there is a certain "bit
: feedback" per cycle - 8 bits back in an 8 bit computer, 16 for the ST, 32
: for the TT, SO, the Atari engineers reworked the video fetching system so

You really need to use more descriptive terms.  And maybe some correct
ones.  Again, you're taking away half your cycles, so that TT isn't
running at full processor speed either, is it?  Do you think it's
missing burst mode because they decided it wasn't necessary???

: that it grabs 64 bits of info per cycle - MUCH, MUCH faster - it does it by
: way of a special "latching" system which I'd rather not go into great
: detail with right now.

That's fine:  We know how it can be done.  Use 32-bit ram, page mode,
and do a pseudo-64 bit fetch.  At least, that's one way.

: Now, the TT supports all ST resolutions plus 640x480 16 colors, 320x480 256
: colors, and 1280x960 monochrome - the Falcon's modes are much larger memory
: wise, but by using the 16Mhz COMBEL and a 64 bit video fetch, it doesn't
: cut into processor time at all - oh, yes, TOS 4.0 works 'em in parallel.  

It DOES cut the processor time--because it's still taking memory
cycles.  Don't you see that?  If you run a 68030 in Amiga FAST ram,
you're NOT taking ANY cycles away.  Burst mode works.  It's got FULL
access to ram, not "every other cycle", or however it's being done.
They're NOT using VRAM.  So the video system takes cycles, and that's
why burst isn't possible.  Burst doesn't work in Amiga chip ram
either, don't you know why?

: Finally, some of you bonheads are claiming that since processor time is cut
: in half (NOT), or since video speed is so slow (NOT), that the Falcon is

Processor time is cut, period.  Half, quarter, all depends on the
resolution and how they set it up.  I would say it's probably half,
though, because it seems to be the easiest way of doing it--taking
every other cycle for the video system.  Video speed?  Video speed
gets priority, pal, I'm sure it'll be damn fast.  However, there's a
tradeoff--the more bandwidth needed by graphics, and I'll explain this
again, the less that is available to the CPU.  Because the graphics
system has priority over the CPU--it has to, otherwise video stops
working.

Bandwidth is a FIXED limitation.  It's not variable, it doesn't
magically change when you increase your resolution.  If something
takes more of it, that means there's less left over.

If you've got ten oranges, and you take five away and give them to
your video chip, then you've got five (not ten) left over for your CPU
to eat.  Now, let me continue.  If you give every other orange to your
video chip, that leaves every even/odd orange for your cpu to eat.  If
they take turns...

Your video processor eats the first orange.  Your processor gets its
orange, and it finishes it...  It goes to reach for the second, but it
can't.  That one belongs to the video processor.  So it waits for the
video processor to eat the first, eat the third, and then it eats the
fourth.  However, he was using really fast teeth on that one, it only
takes him a cycle to eat an orange when he's wearing those teeth.
When your CPU, however uses any number of cycles that isn't an even
number, it's going to be waiting a whole orange for your video system
to eat its orange.

Got it?

I hate to treat you like an idiot, but once I started the analogy it
was too cute to let drop.

: unusable - oh, ok.......If that were the case, then how was the Falcon able
: to perform the following feat at the Boston Computer Society Meeting:
: 3 1/2 minutes of digitized 640x400, interlaced, 65,536 color video, showing
: at 24 frames per second, WHILE playing back 3 1/2 minutes of 16 bit, 50kHz,
: digitally sampled audio.......took up 90 meg of hard disk space and running
: on a 14 meg machine - 4 meg if compressed.........I couldn't if you were
: right - fortunately, you are NOT.........

People have done better with DCTV, you know.  Ask someone to show you
a coup'la minutes from Back To The Future III, I believe.  Also, I
think there was a T2 demo...

It's not even impossible on a fairly limited graphics system such as
the 2000, (limited, of course, by your perceptions...)

Anyways.  That's not the point.  People aren't saying the video system
is going to be slow.  They're saying the CPU is going to be slow as
long as you've got video.  And that's what's bad.  Hopefully, you'll
understand why I see this as an architectural mistake.

Greg

--
(: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
(: 	"Yeah, if improving the system is screwing the user base,     :)
(:	 you all need to be screwed more often." -Dave Haynie	      :)
(: (: (: (: (: (: (: (: (: (: (: (: (:) :) :) :) :) :) :) :) :) :) :) :)