From: bmccnnll@unix1.tcd.ie (Barry McConnell)
Newsgroups: comp.sys.amiga.hardware,comp.sys.amiga.misc
Subject: DMA and Accelerators FAQ v0.9
Keywords: DMA, 32-bit RAM, PIO, GVP, CSA, MMR, SSL
Date: 12 Oct 92 09:43:19 GMT
Organization: Trinity College, Dublin

DMA and Accelerators FAQ - v0.9 - 11th Oct '92

Very regularly, there is a posting in one of the c.s.a groups from someone
who is intending on buying an accelerator, but has heard horror stories about
incompatibility with hard drives. To save having to spend a lot of time
explaining the situation each time this happens (and replying to all the
follow-ups), I have decided to write a FAQ which I can post/e-mail whenever
this question gets asked.

This whole area of accelerator/hard drive conflicts can get quite
complicated, and I don't pretend to know everything there is to know about
it. Someone who probably does is Ralph Babel (hi Ralph!), but - being GVP's
Director of System Software - he is a rather busy man. Since he has already
answered a great many of my questions about it through e-mail, and has
expressed a desire to have a FAQ written up on the topic, I thought I'd do it.

So, on with the show!


1. "Okay, so I have my hard drive, and I have my accelerator, and I have my
32-bit memory, but they all just don't seem to like each other. [Stories of
crashing, lockups, slowdowns, etc.] I know this is something to do with some
memory being DMA-able, and some not, but it's all very confusing..."

The 32-bit memory you have on your accelerator can be divided into three
types: Ordinary DMA-able memory; non-DMA-able memory; and only DMA-able via
the onboard SCSI controller. A few accelerators have the option to switch
their 32-bit memory between some of these three types.

"Ordinary DMA-able memory" is like that found on 16-bit memory cards which
unaccelerated Amigas use, except of course it's 32-bit, and (probably) can't
be used in the 68000 fallback mode. It lies within the Amiga's 24-bit
DMA-able address space, or to be more precise, it is inside a certain 8MB
memory chunk, set aside for "Fast" memory. The advantage to this is that hard
drive controllers can recognise it, and DMA to it as normal, as the memory is
in the correct region. The disadvantages are that it is limited to a maximum
of 8MB (you might think that 8MB is heaps, but if you have a fast '030 or
'040 accelerator, you often have the need for a LOT of memory), and it has to
somehow co-exist peacefully with existing memory cards (what do you do if
there is already an 8MB memory card there?).

Examples of this are the Commodore A2620/A2630 accelerator cards (they can
have a maximum of 4MB 32-bit RAM onboard, which is inside the 24-bit DMA-able
address space, and thus can be DMA-d to normally like any other RAM
expansion), and the Microbotics VXL '030 card (which has a maximum of 8MB
32-bit RAM, but if this is going to "tread on the toes" of an existing memory
card, it can move it outside the 8MB address space - see below).

"Non-DMA-able memory" means that the memory is outside this 8MB address
space. Since all ZorroII hard drive controllers can only recognise Fast
memory inside this space, they cannot DMA to it. The advantage of doing this
is that you can have - say - 32MB of RAM on the card, without having to worry
about squeezing it all into an 8MB addres space (impossible!), or interfering
with any existing memory cards. Examples of this are the SSL A5000/B5000
accelerators, and the CSA Mega-Midget Racer. The Microbotics VXL '030 (see
above) can - if you want - turn its memory into non-DMA-able memory, if you
have an existing memory card which might interfere with it.

Finally, "DMA-able via the onboard SCSI controller" means that the memory is
also outside the 8MB address space, but the onboard SCSI controller "knows"
about it, and can DMA to it as normal. These kind of accelerators are usually
only found on cards for the A2000's CPU slot, as the addition of a SCSI
controller/hard drive combination takes up a fair amount of space. :-) 
Examples are the GVP Combo ('030 and '040 - there is also a version for the
A500), the PP&S '040, and the Commodore Amiga 3000 and Amiga 4000. (Plug an
A2091 into one of these, and you will run into the DMA problem!) In a similar
manner to the Microbotics VXL '030, the GVP Combo can turn its 32-bit memory
into "ordinary" DMA-able memory, so it can be easily accessed by - say - an
A2091. (Should you have a need for two SCSI controllers in the one machine!)
Of course, you will have to ensure that you don't end up with any conflicts
involving existing memory boards in that 8MB region if you do this.


2. "I have non-DMA-able memory, with no onboard SCSI controller 'cos I
couldn't afford a Combo board (or I already had an A2091 or whatever). What
can I do about this problem?"

The fact that you have non-DMA-able memory shouldn't matter to your hard
drive controller, which should - of its own accord - find an alternative
method of getting data there. Sadly, in real life, very few controllers can
do this. Call it a bug if you like. They generally end up either crashing the
machine, or locking up, or just failing to get the data there while
pretending it really is there. (Yuk!) Many A590's/A2091's (pre-v6.6 ROMs)
cannot handle non-DMA memory correctly. Newer ones can, by falling back into
PIO mode (not DMA; rather, it uses the CPU to get the data from the HD to
memory - this is not particularly fast, but it is adequate, even if it does
chew CPU time...). The GVP Series II is the best of the bunch, and will get
fairly high transfer speeds even with non-DMA memory.

There is a thing called a "Mask" for each partition on your hard drive, and
this will - if you have a "buggy" HD controller - allow you to get around
this problem via the FileSystem (part of the operating system). Generally,
your Mask is set to 0xffffffff, which is a conveniently large number (work it
out, and is comes to just under four gigabytes, which is more than the
maximum your Amiga can ever hope to address...). The software that comes with
your HD controller should allow you to alter this value: the A590/A2091 uses
HDToolbox, and the GVP Series II uses FaaastPrep (it can also use HDToolbox
if you add the ToolType SCSI_DEVICE_NAME=gvpscsi.device to it).

You may find the Mask has an "e" and not an "f" at the end, which prevents
the controller from trying to DMA to odd locations (again, to get round a
limitation of some controllers). You may find it is only set to 0xfffffe,
which is just under 16MB, which is the top of your Fast RAM (plus Chip RAM,
plus a few "reserved" areas of the Amiga's memory map).

As you may have guessed, you set the Mask to tell the FileSystem what areas
of memory your controller cannot cope with. For the technically-minded, the
FileSystem takes the Mask as a binary number, inverts it, ANDs it with the
address you are trying to DMA to, and if that comes out as zero, it knows
that the HD controller is able to handle that region of memory.

If the Mask determines that the HD controller cannot handle a DMA request, it
attempts to do the job itself. Very, very, very badly. ;-)  It creates a
512-byte buffer down in low memory (Chip RAM or 16-bit DMA-able Fast RAM),
DMA's to that, CPU-copies to the destination in non-DMA-able 32-bit RAM, and
loops back until the entire transfer has been completed. Due to the original
request being split up into a load of very tiny requests, the whole operation
effectively slows down the transfer speed to something approaching a floppy
drive. You might get 50K/sec, which means loading DPaint could take ten
seconds, where it originally took two. The bottom line is: it's unbearable!


3. My HD controller cannot handle my non-DMA memory, so I've set my Mask to
0xfffffe, and everything is working, but: it is sloooooow. Help!

This is why I wrote DMAfix. ;-)  DMAfix patches three DOS library calls -
Read(), Write(), and LoadSeg(). It will work under both 1.3 and 2.0. It gets
in ahead of the FileSystem, and determines for itself if the memory involved
is DMA-able. If it is, then it lets the library call go ahead as normal. If
not, it allocates a chunk of Chip RAM for a temporary buffer, redirects the
call to use this buffer, and then CPU-copies afterwards (or before, if it's a
write). It works far faster than the FileSystem's DMA-plus-CPU-copy method,
since it tries to allocate a buffer large enough so the loop only has to be
executed once (if you are low on Chip RAM, it will use a 64K buffer, which is
still pretty fast). Now, you will experience some slowdown due to the
CPU-copying, but not much. Speeds of over 500K/sec are common, where before
you might have got 800K/sec.

DMAfix is Shareware, and to thank the few people who have registered, I have
sent them a modified version which - if you have 2.04 in ROM - allows you to
use a buffer in Fast RAM instead, which is considerably faster (as you might
have guessed). I have also completely re-written DMAfix, and the newest
version is what I would call a commercial product, the exclusive distributors
being Solid State Leisure in the UK (thankyou for the B5000-40!). It is a
better solution to the whole problem, a tad faster than the registered
Shareware version, and - as far as I know - the fastest solution available.
The GVP Series II uses a very similar method to handle the problem, but -
since it only uses 8K buffers - is a wee bit slower (not much though). So if
you have a flawed HD controller, and want the "ideal" solution, buy an
accelerator from SSL. :-)


4. Phew! Can you say all that again?

Okay: here's a brief summary.

- If you have an accelerator with DMA-able 32-bit memory (A2630, VXL), or an
onboard SCSI controller (GVP Combo, PP&S '040), then what are you worrying
about??

- If you have a GVP Series II, or an A590/A2091 with v6.6 ROMs, set your Mask
to 0xfffffffe and everything should work fine. (Sorry, I don't know about
other controllers.) The GVP solution will certainly be fast enough for you;
the Commodore solution may not, and you might like to try DMAfix in this case.

- If you are forced to use a Mask of 0xfffffe because of a flawed HD
controller, ask me for a copy of DMAfix, or download it from a local BBS (it
appears to have spread itself far and wide!).

Oh, one other point: the fact that the memory is AutoConfig (or not), or is
sitting in the A2000's CPU slot as opposed to the 68000 socket, has nothing
to do with this! Many people seem to think that any "proper" accelerator
sitting in the CPU slot will automatically have DMA-able 32-bit memory: not
true; mine doesn't...

--


End of FAQ. Comments, suggestions and corrections would be welcome! This
material is Copyright 1992 Barry McConnell. It may not be distributed as a
part of anything sold for profit. Noncommercial distribution is okay as long
as there are no changes made.

Barry.
bmccnnll@unix1.tcd.ie
Newsgroups: comp.sys.amiga.hardware