NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/atari/st/tech/5647

Text File | 1992-11-15 | 4.1 KB | 93 lines

Newsgroups: comp.sys.atari.st.tech
Path: sparky!uunet!think.com!spool.mu.edu!darwin.sura.net!rmece49.upr.clu.edu!rmece02.upr.clu.edu!raist
From: [e-mail] (Ricardo Hernandez)
Subject: Re: Falcon BUS..
Message-ID: <[e-mail]>
Sender: [e-mail] (placeholder for future)
Nntp-Posting-Host: rmece02.upr.clu.edu
Organization: UPR-Mayaguez--ASEL Lab
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 15 Nov 1992 20:30:34 GMT
Lines: 80

In article <[e-mail]>, [e-mail] (Ben Gilbert) writes:
|> In article <[e-mail]> [e-mail] (Ricardo Hernandez) writes:
|> >In article <[e-mail]>, [e-mail] (Ben Gilbert) writes:
|> >|>
|> >|> In conclusion, the CPU does not HALT for anything -- you may run into
|> >|> some bus contention when DMA or similar operations are taking place,
|>          ^^^^^^^^^^^^^^
[stuff deleted]

|> I don't want to start a flame war or anything :), but I believe I did mention
|> the issue of bus contention.  Yes, the CPU may slow down if there is DMA

   Ooops!  Sorry for that one :-| :-)

|> taking place, and yes, it may not be able to use the bus if the "interleave"
|> is turned off (I don't know which is physically implemented on the ST).
|> However, even if the CPU is not using the bus, it may still be doing something,
|> although this brings up the issue of cache coherency during DMA again.
|>
|> I still think, though, that the coprocessors in general will always speed up
|> the computer's overall performance -- we shouldn't worry that just because
|> the SDMA engine or blitter can take control of the bus, they will hinder
|> the CPU in any drastic manner.  And just to add one other point : why is
|> this an issue now when the ST and STe and TT have used a 99% similar
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> design for years?  The Falcon doesn't have some special flaw due to its
   ^^^^^^^^^^^^^^^^^

  ST's, STe's and TT's have an old design... doesn't mean is better. :-)

|> larger number of coprocessors -- it's working on the same tried and true
|> concept which has worked on almost all SISD microcomputers for ages...

   True, having coprocessors always helps (or in the average case, it
always helps).  But between a computer that has a separate bus for the
coprocessors and another for the CPU, so there's none CPU bus contention,
that computer will run much faster under some situations.

   Since I don't want to start a flame war either ( :-) ), I know of
another computer that doesn't run into this problem by providing two
kind of buses (some people can imagine what computer I am talking about).
On that computer, if the CPU is forced to access the coprocessor's memory,
while there is heavy info traffic, the CPU slows down (on some cases
a lot).  But because that computer has another bus for the CPU, when
the CPU runs in its own memory, it runs at full speed (or as fast as
that memory allows).

   Remember the ATARI 8-bits?  The machine is rated @ 1.79 Mhz and actually
runs like @ 1.13Mhz.  This is due to ANTIC's DMA bus contention.  This is
the problem I see in the Falcon.  How many of you (ex ATARI 8-bitters)
remember:

    Poke 559,0?

  This turns off Antic DMA so the machine speeds up like 30%.

  Now, should the Falcon had a separate memory that only the CPU could
access, this would mean that the CPU will slow down only when accessing
video memory under heavy graphic modes.  Same happen with other
coprocessors.

|> >|>
|> >|> --
|> >|> Ben Gilbert                e-mail : [e-mail]
|> >|> Department of Computer Science
|> >|> University of Washington
|> >
|> >- Raist
|>
|> Happy bussing (or is that busing?),   :)
|>

  :-)

|> --
|> Ben Gilbert                e-mail : [e-mail]
|> Department of Computer Science
|> University of Washington

- Raist