Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: DMA controllers and 32bit RAM
Message-ID: <112085@sun.Eng.Sun.COM>
Date: 23 Jun 89 20:06:06 GMT
References: <14391@ut-emx.UUCP>
Sender: news@sun.Eng.Sun.COM
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 67

In article <14391@ut-emx.UUCP> sjk@ut-emx.UUCP (bob) writes:
> Just a question I haven't been able to get a straight answer about:
> What happens if you use a DMA hard disk controller, but have 32bit
> expansion RAM that does not have it's own DMA controller? 

First lets get the terminology consistent. A DMA controller transfers
data about on the memory bus for "someone". There is a set of DMA 
controllers standard in the Amiga, they transfer data on the Chip bus
for the Custom Chips. Some hard disk controllers also come with a DMA
controller on the interface, the 2090 and the MicroBotics HardFrame 
come to mind. These DMA controllers, transfer data for the controller
to memory on the "expansion" bus.  Memory systems don't include DMA
controllers.

> It's my understanding that there will be some problems because the 
> controller will be looking for 16 bit RAM, but will find 32 bit RAM
> in its place. So, what happens? Does it come back saying not enough 
> memory, does it revert to non-DMA transfer, does it DMA to 16 bit 
> then upload to 32 bit via the CPU, or something completely different?  

The Expansion Bus is a 16 bit bus. Anything plugged into that bus 
doesn't "look" per se for 16 bit memory, they are constrained to 
16 bit transfers by the bus itself. Some CPU cards such as the LUCAS
and A2620 have the option of memory that has a _separate_ 32 bit
memory bus between the CPU and itself. Now if that memory is also
accessible to the 16 bit expansion bus, then there won't be any
problem DMA'ing into it. The problem is given to the memory system
designer to make sure this is possible. And of course some of them
punt on it. (It is a tough problem) So how do you make 16 bit memory
available to the system without confusing it with the "regular"
16 bit RAM that is available? Well the most common way is to address
it about the 16Meg addressing limit of the original 68000. To do
this usually requires that the memory _not_ autoconfig, rather it
gets added to the memory list with an AddMem command later. To
keep DMA devices from trying to get into this memory, C/A added the
Mask parameter to 1.3 version of Mount which essentially allowed the
user to say "Any memory out of this range, is undmaable." And it 
is the filesystem that in fact decides that since the request came
from memory outside of it's available range that it would have to 
first DMA the data into a buffer available in RAM that it could
talk to, and then get the CPU to copy it up to where it's final
destination is. And infact the Floppies which uses the trackdisk
device already did this internally to some extent because of their
limitation to DMA into Chip RAM, however now they could be converted
to use this mask parameter to "know" where the Chip memory bounds were.
The only criticism of this system might be that it implies that limits
are overlapping down, meaning that you cannot easily specify that 
a device can DMA *only* into a range of memory that starts at some
non zero address and moves upward. Say $A00000 - $B00000. 

>My own system is an Amiga 1000 with LUCAS and (soon to be) FRANCES
>32 bit memory board and a Toolbox expansion chassis where my hard
>drive controller will go, but I suppose people with A2000's and 
>a third party 68020 board (ex. Ronin) will face similar problems, as
>the 2620 is the only 020 and 32 bit RAM board with its own DMA support
>routines, that I know of.

The A2620 board does this by allowing access to it's 32bit wide memory
as 16bit wide memory to devices on the expansion bus. There are no
"DMA support routines" rather it is a function of how the memory subssytem
was designed.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"A most excellent barbarian ... Genghis Kahn!"