Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!acorn!jroach
From: jroach@acorn.co.uk (Jonathan Roach)
Newsgroups: comp.sys.acorn,eunet.micro.acorn
Subject: Re: Archimedes Suggestions
Message-ID: <5345@acorn.co.uk>
Date: 22 Feb 91 17:40:58 GMT
References: <1991Feb13.161140.7781@vax1.tcd.ie>
Sender: jroach@acorn.co.uk
Distribution: comp
Organization: Acorn Computers Ltd, Cambridge, England
Lines: 46

In article <1991Feb13.161140.7781@vax1.tcd.ie> hughesmp@vax1.tcd.ie writes:
about ADFS undelete and screen update speed.

Just to clarify one or two points: when ADFS deletes a file it removes the
directory entry and returns the file's space to the disc's free space pool.
There is no record kept of what parts of the free space pool made up what
files in the past. This makes undeleteing a file very difficult. Also, I
note that saving a file is more likely to destroy that precious old version
than straight delete.

The above article also concludes:
>The best thing I think Acorn (VLSI?) could do on a hardware scale, is get this
>direct memory access thingy; it would double the speed of the Arc for a lot of
>applications, without being too costly..

Well, the Archimedes already uses DMA for screen and sound. The observed
slowdown is due to the CPU and the screen and sound contending for the
memory's time. The memory has an upper limit to the quantity of data it can
ship out in a given time - for an Archimedes this is never greater than
25600000 bytes per second. For entirely random memory accesses this rate
drops down to 16000000 bytes per second, but the Archimedes memory
controller often optimises sequential memory accesses thus improving the
memory bandwidth. For a mode 15 screen the quantity of data shipped per
second is about 8Mbytes, thus leaving about 17Mbytes per second for the CPU
- slowing the machine down to 2/3 it's old speed - the machine's CPU speed
being almost directly linked to memory bandwidth available to the CPU.
Another point to observe is that updating the higher colour and resolution
screen modes simply requires more data to be written to the screen memory to
fill a given area, thus is bound to take more time.

Earlier in the article:
>On the Amiga, you
>can have up to 5 bitplanes and 4 channels of music going, without impinging
>on the speed of the machine at all.
which is actually not true. As I understand it the Amiga has the screen and
DMA buses separated such that memory expansion beyond a certain point can't
be DMAed, but doesn't have its bandwidth swallowed by DMA either, thus
enabling the CPU to run at full speed in that area. If the CPU is running in
the DMAable area, then its speed will be significantly hit as it contends
for the memory's time with the screen and sound. Also, if the CPU is
updating the screen or sound information, then those memory accesses to the
DMA area may be delayed as the CPU waits for the screen or sound DMA to
finish. I might have got the details of the Amiga description wrong, but the
basic principles are correct.

--Jonathan