Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!uw-beaver!mit-eddie!snorkelwacker.mit.edu!usc!cs.utexas.edu!uunet!mcsun!ukc!acorn!mark
From: mark@acorn.co.uk (Mark Taunton)
Newsgroups: comp.sys.acorn
Subject: Re: MEMC and video DMA question
Message-ID: <5174@acorn.co.uk>
Date: 14 Feb 91 16:47:20 GMT
References: <1277@culhua.prg.ox.ac.uk>
Reply-To: mark@acorn.co.uk (Mark Taunton)
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 73

[Apologies to those who have seen this article already: I had some
problems trying to cancel the first attempt which went out with an
incorrect Reply-To field.]

In article <1277@culhua.prg.ox.ac.uk> as@prg.ox.ac.uk (Andrew Stevens) writes:
>
>In a basic Arch you get contention between the video-subsystem and the
>CPU - the MEMC multiplexes the two onto the same memory sub-system.  It
>even generates the video-DMA addresses as I understand it. So, what
>happends in a machine with 2 or more MEMC's?
>
>Can you fix things up so that RAM controlled by one MEMC supports video
>DMA (and runs slow), whilst a second bank with its own MEMC runs at full
>tilt.  In an A540, for example, does the machine run faster when more
>than one RAM bank is added?

No. Multiple-MEMC machines (extended A440/R140, A540/R260) still have
only one data bus and one address bus, so there is no extra data
bandwidth from the extra MEMC.  However the A540 and R260 have a
faster memory subsystem (12 MHz instead of 8 MHz) which provides a
useful increase in bandwidth and reduces the impact of high video data
rates (as does the ARM3 cache by reducing the processor's bus usage).

As you surmise, the first MEMC always handles the video (and other)
DMA traffic.  It *might* be possible in a different design to have the
other MEMCs in a complex data bus buffering scheme, allowing the
processor to get at its own data while VIDC is loaded from screen
memory.  However you should note that (a) the current multiple-MEMC
system design requires the MEMCs to be tightly synchronised at all
times, so breaking this would probably involve some quite complex
hardware glue, if it is indeed possible, and (b) I am not a hardware
designer, and haven't looked into this in any detail.

>Also, does MEMC support general-purpose DMA as well as video?
>E.g. for winchesters etc, or is all that sort of stuff (as I
>heard rumoured) done by the main CPU?
>
>The latter would at least partially explain the reputedly poor
>through-put of Rxy0 UNIX systems when paging.  A 32K page size certainly
>doesn't help, but it shouldn't impact through-put all that much. If the
>system isn't thrashing other runnable processes should happily soak up
>CPU time while a page-fault is fixed.  However, if the CPU was *busy*
>during page-faults sluggish performance during paging would be no
>suprise at all.
>

No, in current Acorn systems MEMC handle only special DMA for video
(two channels, one for main screen data, one for cursor data) and
sound.  There is no separate DMA hardware for any other data traffic.
The built-in ST506 controller in the A4x0/R140 has its own buffering,
and the processor is required to transfer the data under interrupt on
each 256-byte sector boundary, or once every 500 microseconds or so
during a multi-sector transfer.  On my last check, the RISC iX code to
handle this on an R140 takes in the region of 140 microseconds (more
in high bandwidth screen modes), so there is a definite reduction in,
but not a complete loss of, available CPU power during disc transfers.
The situation is similar on the R260 in that the data is moving in/out
via buffers on the SCSI expansion card. I have no figures for the
actual transfer rate there, but of course the memory end of the
transfer will go rather quicker than on an R140 because of increased
memory bus and processor speed, and because the transfer loop code
will be in the ARM3 cache.

>Andrew
>        Andrew Stevens                  
>      Programmming Research Group       JANET: Andrew.Stevens@uk.ac.oxford.prg         
> Oxford University Computing Laboratory INTERNET: Andrew.Stevens@prg.ox.ac.uk
>     11 Keble Road, Oxford, England     UUCP:  ...!uunet!mcvax!ukc!ox-prg!as


Mark Taunton
Acorn Computers Ltd
mark@acorn.co.uk