Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!ukc!dcl-cs!bath63!pes
From: pes@ux63.bath.ac.uk (Smee)
Newsgroups: rec.music.synth,comp.sys.atari.st,comp.sys.amiga
Subject: Re: Amiga midi
Message-ID: <1620@bath63.ux63.bath.ac.uk>
Date: Mon, 24-Aug-87 06:22:46 EDT
Article-I.D.: bath63.1620
Posted: Mon Aug 24 06:22:46 1987
Date-Received: Wed, 26-Aug-87 04:38:26 EDT
References: <8708220150.AA24029@cogsci.berkeley.edu>
Reply-To: pes@ux63.bath.ac.uk (Smee)
Organization: AUCC c/o University of Bath
Lines: 51
Xref: mnetor rec.music.synth:1348 comp.sys.atari.st:4898 comp.sys.amiga:7758


Well, everyone is close in describing the ST memory.  Including my first try if
it's escaped.  The real true story is --

The ST memory is approximately 125 nanosecond memory.  It is clocked at the
same notional 8 MHz as the processor.  (Or maybe I should say 'referenced' at
the notional 8 MHz, since I don't know that it's not a multi-phase clock.)

The video shifter references the memory at a guaranteed 4MHz.  It is given
alternate memory reference cycles by the memory management chip.  It always,
and no matter what gets every other reference cycle.  The CPU and any other
DMA devices attached compete for the remaining 4MHz.

The 68000 CPU is not capable of generating a memory reference every clock
cycle -- the best it can do is a ref per 2 clock cycles.  (And usually this
is the pattern it follows.)  So, generally speaking once the CPU has got one
of the 'every other cycles' available to it, it will tend to stay out of
step with the video shifter, and so a 'free' (non-video) memory cycle will be
there when the CPU wants to hit memory.  Occasionally (with some rarer
instructions) the CPU will want a memory ref an odd number of cycles after
its last previous one.  In this case, the CPU will be 'stalled' for one cycle
by the memory manager in order to force it back out-of-step with the video
shifter.

Also, the CPU may occasionally get out of phase due to the fact that the CPU
and the video shifter are not tightly synchronized.  (The shifter, after all,
has to work to the sync rate required by the monitor.)  If the CPU and the
video shifter drift into phase, again the memory manager will stall the CPU
for one cycle to bring them back out of sync.  The video chip always wins.

Any other DMA devices (e.g. hard disk) steal cycles from the CPU.  (The video
chip *always* wins.)

According to the 'official rumours', the probabilistic memory access rate of
the 68000 running normal sorts of things is such that very few cycles need to
be stolen from it to keep it out of step with the video shifter.  This 'feels'
reasonable by subjective comparison with the apparent response of 68000
machines which do not have video shifters running at a 'half the references'
priority guarantee.

Ultimately, though, this is all irrelevant.  There is **NO** best machine in
an independent and objective sense.  Taking everything into account (task to
be done, price and availability of hardware, price and availabitlity of
software, 'feel' (which effects user productivity), quality of service
available from local dealers, etc...) one machine *can* be better than
another *for a particular user with a particular set of needs*.  Among other
things, this is how the 8086 machines have held on for so long.  It would
make life a lot more pleasant if everyone would keep firmly in mind that just
because machine X is the best *FOR THEM*, it doesn't therefore follow that it
is the best for everyone.  I can't think of a machine on the market which isn't
the IDEAL machine for some particular purpose...