sjk@ut-emx.UUCP (bob) (06/23/89)
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? 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? 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. FRANCE, by the way, is Brad's 32-bit memory board companion to LUCAS. Thanks for any insight you can offer! Scot Kleinman sjk@astro.as.utexas.edu Astronomy Dept. U. Texas Austin TX 78712
daveh@cbmvax.UUCP (Dave Haynie) (06/23/89)
in article <14391@ut-emx.UUCP>, sjk@ut-emx.UUCP (bob) says: > 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? Lots of interesting things can happen, depending on what you've got. 32 bit RAM never has it's own DMA controller, but it needs to have DMA kept in mind. This basically means one of two things: [a] You locate the memory somewhere that's easy to keep DMA away from. I consider this to be some place outside of the normal 68000 address space. With memory starting, say, at $1000000, it's easy to keep DMA devices away from it by specifying a Mask value in their mountlist entry, providing the device will support Mask. [b] You build a 32 bit memory system that can support 16 bit DMA. It does add to the complexity of the memory system. There are two basic approaches. The simplest is to make the memory respond like a 68000 memory board during DMA, and like a 68020/30 memory board during CPU operation. The second approach is to build a bus converter that turns 68000 signals into slow 68020/30 signals. The A2620 and A2630 use the first approach; the only thing they all DMA to access is the on-board DRAM (pretty much the only thing on-board that would be interesting to a DMA device anyhow). > 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. Ronin does indeed have a problem with DMA. They ship their memory board non-autoconfiguring but allow it to sit in expansion space. That's a bad idea. They also recommend a Mask=0x0ffffe, which restricts DMA to CHIP memory, an even worse idea. Fortunately, with the right jumper settings the Ronin memory can be moved above the 24 bit mark and the right 0xfffffe mask can be used (restrict DMA to where the hardware allows it to go in the first place). I talked with Brad on this some before, and briefly at DevCon, so I'd expect his board to make the right kind of decisions for the type of board it'll be. > Scot Kleinman > sjk@astro.as.utexas.edu > Astronomy Dept. U. Texas Austin TX 78712 -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Be careful what you wish for -- you just might get it
cmcmanis%pepper@Sun.COM (Chuck McManis) (06/24/89)
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!"
huver@amgraf.UUCP (Huver) (06/26/89)
To this query Chuck McManis and Dave Haynie had responded with info on DMA I/O with 32-bit memory for the Amiga in general. But let's look at the specific setup the original poster has: an A1000 with LUCAS. I dont' know how the DMA controller in question works, but a "fully functional" Amiga 1000 DMA controller hanging off the expansion connector must look for XRDY or *DTACK signals as memory response -- from expansion and CHIP memory, respectively. None of these signals are asserted by LUCAS. XRDY is only on the A1000 expansion connector, not available inside the machine. And LUCAS uses *DTACK from the 68000 socket as an input signal, not an output. More, Brad had said, in his FRANCES announcement mailing, that he did NOT design the memory for 16-bit DMA support (FRANCES is designed to be a fixed 32-bit prot). So all theories aside, no DMA is possible for the 32-bit RAM. Suppose we redesign LUCAS for this. It needs to recognize external bus master request (this is aready there) and shut off on-board *DTACK decoding logic, map the hi/lo-byte/word 68000 signals with address lines to proper memory address, map the 32-bit data lines to 16-bit lines, and generate *DTACK from fast memory *DSACKx. But wait... LUCAS interfaces with A1000 via the 68000 socket so it appears as a 68K to Amiga. We can't assert *DTACK because no 68000 ever asserts *DTACK. The only way is negate *DTACK and hook it direcctly to XRDY on the expansion connector. So, LUCAS must now also manage XRDY fully -- all this work just to support the slow (from LUCAS's perspective) 16-bit DMA. Most of you would agree: too much for too little gain. With 16 MHz LUCAS, a driver code sitting in 32-bit memory doing programmed I/O can run as fast as DMA -- once you step off LUCAS the speed drops to max 7 MHz trasnfer. Nothing can help. The best answer is a 32-bit capable DMA for LUCAS (same is true for the A2620 in an Amiga 2000). ------ Asking "Why can't I run UNIX on my Amiga?!" is like asking "Why can't I put wife and four kids in my Porche?!" -huver ...!uunet!amgraf!huver
daveh@cbmvax.UUCP (Dave Haynie) (06/29/89)
in article <311@amgraf.UUCP>, huver@amgraf.UUCP (Huver) says: > Summary: No DMA for LUCAS > I dont' know how the DMA controller in question works, but a "fully > functional" Amiga 1000 DMA controller hanging off the expansion connector > must look for XRDY or *DTACK signals as memory response -- from expansion > and CHIP memory, respectively. A DMA controller should only look at DTACK*. XRDY is used by a slave device to delay the automatic DTACK*, OVR* can be used by a slave to remove the automatic DTACK* and let it terminate the cycle, but the bottom line is that it's the slave's responsibility to see that DTACK* is asserted at the correct time, the master's responsible to sample DTACK* appropriately (as well as the valid data 1 cycle after DTACK*). > None of these signals are asserted by LUCAS. XRDY is only on the A1000 > expansion connector, not available inside the machine. And LUCAS uses > *DTACK from the 68000 socket as an input signal, not an output. At the very least, an "plugs in the 68000 socket" accelerator would have to use the automatic DTACK* for it's memory cycles to support DMA, since it doesn't have access to either OVR* or XRDY to modify that DTACK. This could be done on an A2000, and I suspect an A1000 (not 100% sure), but it might make the memory board design more complex. When the A2620/30 32 bit memory acts like a 16 bit slave device, it's pulling OVR* and generating it's own DTACK*. > More, Brad had said, in his FRANCES announcement mailing, that he did NOT > design the memory for 16-bit DMA support (FRANCES is designed to be a fixed > 32-bit prot). So all theories aside, no DMA is possible for the 32-bit RAM. As I suspected. > Suppose we redesign LUCAS for this. [Stuff Deleted] But wait.. > LUCAS interfaces with A1000 via the 68000 socket so it appears as a 68K to > Amiga. We can't assert *DTACK because no 68000 ever asserts *DTACK. If you could assert OVR* with an extra wire or something, I think you can drive DTACK* out of the 68000 socket. Like I said, it'll definitely work that way on an A2000, but I'm not 100% sure how DTACK* is wired on the A1000. > The only way is negate *DTACK and hook it direcctly to XRDY ... No, the other way would be to sync your memory cycles with the default DTACK*. Basically, that makes the memory completely synchronous, which means you'd always have to hide refresh, since you can't possibly wait for a cycle or two if you get caught refreshing during an intended memory cycle. It would be much more difficult to do things this way, though I think it could be done. > With 16 MHz LUCAS, a driver code sitting in 32-bit memory doing programmed > I/O can run as fast as DMA -- once you step off LUCAS the speed drops to > max 7 MHz trasnfer. Nothing can help. IF you buffer things. 16 bit DMA would still go faster than a 32 bit CPU reading an 8 bit SCSI chip or something, but if you get the SCSI section to buffer up 4 bytes and read the thing 32 bits at a time (or better, buffer up a whole block and read with the CPU a block at a time, like GVP's controller), you could go faster than 16 bit DMA. > The best answer is a 32-bit capable DMA for LUCAS (same is true for the > A2620 in an Amiga 2000). Unless you're counting on using existing DMA hardware, as we were in concert with the A2620/30. > ------ > Asking "Why can't I run UNIX on my Amiga?!" is like asking "Why can't I put > wife and four kids in my Porche?!" Great quote! > -huver ...!uunet!amgraf!huver -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Be careful what you wish for -- you just might get it
monty@sagpd1.UUCP (Monty Saine) (06/30/89)
In article <311@amgraf.UUCP> huver@amgraf.UUCP (Huver) writes: > > >More, Brad had said, in his FRANCES announcement mailing, that he did NOT >design the memory for 16-bit DMA support (FRANCES is designed to be a fixed >32-bit prot). So all theories aside, no DMA is possible for the 32-bit RAM. Which FRANCES posting are you talking about? Has the 32 bit expansion for LUCAS been completed??? If anyone has a copy of this posting please e-mail me a copy. I get very flustrated by UUCP, multiple copies of the same articles, responses to an article arriving before the orginal, never seeing an article and then watching the traffic on a subject I never got to read. Sigh.... Thanks Monty Saine