paulm@cbnewsj.att.com (paul.j.maioriello) (10/18/90)
Thanks to suggestions from Dave Haynie, I have gotten the 2090 with a CDC WREN st-506 drive to work fairly reliably in my a3000 (it's not perfect yet). The procedure to follow is: 1. run NoFastMem 2. run BindDrivers (Binddrivers works every time now) 3. Mount your partitions In order to get it to work, it seems you have to get the 32 bit memory out of the way. My first attempt at doing this was to use the value 2 for the BufMemType parameter in the mountlist file. What I want would like to try doing next is to re-enable the 32 bit memory after the partions are mounted. If I do this now, all the problems come back. Looking through the 3000 documentation, page 7-52 tells about all the stuff you can put in your mountlists file. It seems to me that a key value is what you put in the Mask parameter. THe description states "Address Mask to specify memory range that DMA transfers can use". It seems to me that tweaking this parameter is how you can keep DMAs into 32 bit memory from happening. THe problem is I have no idea what value to use. None of the mountlist examples I have seen even include this parameter yet it seems like it might actually be just what is needed to solve this problem. So, am I on the right track here, or what? Right now, I have to choose between my drives OR my memory. Maybe I'm greedy, but I want BOTH (simultaneously even)!!! By the way, given the continually falling costs of st-506 drives, they make great backup devices. I currently have the interface cables hanging out of the back of the 3000. When I want to make a backup of the internal SCSI, I just wheel up a 506 hook it up, mount it, and copy away. It's fairly fast, and in a pinch you can still use it for on-line storage. Thanks in advance for any help. Paul M. lzatt!pjm
peterk@cbmger.UUCP (Peter Kittel GERMANY) (10/19/90)
In article <1990Oct18.035721.2305@cbnewsj.att.com> paulm@cbnewsj.att.com (paul.j.maioriello) writes: > >Thanks to suggestions from Dave Haynie, I have gotten the 2090 with >a CDC WREN st-506 drive to work fairly reliably in my a3000 (it's not >perfect yet). >The procedure to follow is: >1. run NoFastMem There is also other software that can be saved by using NoFastMem. But in the A3000 you may lose quite an amount of memory through this. So, I can imagine a little utility software (or an addition to SetCPU, Dave?) that could do the following: Invoked after Autoconfig took place and BindDrivers, it looks which portions of the 32-bit Fast mem are already used and which portions of the lower 16 MB address area are still free. Then it uses the MMU to remap that rest of 32-bit-RAM downwards into the old 16 MB area. Well, it has also to take care of the memory chunk lists and such stuff, so it appears to me a bit tricky. If it were really cool, it also were capable to remap fragmented 32-bit memory down to one big contiguous chunk. Though, it should fail gracefully when that lower address area is already occupied by autoconfig devices. Then nobody can help. The net result of this could be that you keep nearly all your RAM (as long as it's not too big, some MB), but use it with FULL Fast RAM speed (or won't this work?), secondly avoiding many compatibility problems. Ok, it's a kludge, but perhaps a nice one :-) As I'm not such a great shot systems programmer, I have to leave this project to the world, someone volunteering? -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
DXB132@psuvm.psu.edu (10/20/90)
Unfortuntely, remapping high memory into low memory with the MMU is rather futile, because DMA transfers don't go through the MMU. Hmm, I guess non-DMA boards have at least one advantage after all. -- Dan Babcock
daveh@cbmvax.commodore.com (Dave Haynie) (10/23/90)
In article <525@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1990Oct18.035721.2305@cbnewsj.att.com> paulm@cbnewsj.att.com (paul.j.maioriello) writes: >There is also other software that can be saved by using NoFastMem. >But in the A3000 you may lose quite an amount of memory through this. However, there is absolutely no reason for other software to fail based on the A3000's 32 bit memory. The A2090 and similar devices are a rather unique problem, in that CBM never gave any guidelines for handling this potential hardware/software conflict. In all software-only situations, it is absolutely clear, and has been for some time, that only full 32 bit addressing is permitted in Amiga programs. Anyone with a program that fails should actively seek upgrades (eg, bug fixes) from the program distributer. While it might be possible to make some kind of band-aid for this, that's not a proper solution. I would really like to see the actual problem fixed. >So, I can imagine a little utility software (or an addition to >SetCPU, Dave?) that could do the following: >Invoked after Autoconfig took place and BindDrivers, it looks which >portions of the 32-bit Fast mem are already used and which portions >of the lower 16 MB address area are still free. Then it uses the MMU >to remap that rest of 32-bit-RAM downwards into the old 16 MB area. You could do that to make software that violates 32 bit addressing rules work on the 3000, within limits. That's not going to help at all in addressing the problems with hardware, which are the only things I really consider a valid problem, since they weren't really worked out in the first place. The Expansion library should have had some function call, maybe "AllocZ2DMAMem()" or some such, that would be guaranteed to return memory that was DMAable by a Zorro II card. Though, according to Amiga specs, any memory that's mapped into the 24 bit address space must be reachable by a Zorro II bus master, so proper guidelines way back when would have been almost as useful as this function. This was just a problem no one fully considered. >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
jesup@cbmvax.commodore.com (Randell Jesup) (11/13/90)
In article <1990Oct18.035721.2305@cbnewsj.att.com> paulm@cbnewsj.att.com (paul.j.maioriello) writes: >Thanks to suggestions from Dave Haynie, I have gotten the 2090 with >a CDC WREN st-506 drive to work fairly reliably in my a3000 (it's not >perfect yet). >In order to get it to work, it seems you have to get the 32 bit memory >out of the way. My first attempt at doing this was to >use the value 2 for the BufMemType parameter in the mountlist file. >What I want would like to try doing next is to >re-enable the 32 bit memory after the partions are mounted. If I do this >now, all the problems come back. Looking through the 3000 documentation, >page 7-52 tells about all the stuff you can put in your mountlists file. >It seems to me that a key value is what you put in the Mask parameter. >THe description states "Address Mask to specify memory range that DMA >transfers can use". It seems to me that tweaking this parameter is how >you can keep DMAs into 32 bit memory from happening. THe problem is I >have no idea what value to use. Use " Mask = 0x00fffffe". This restricts DMA destinations to the low 16M of memory (where the Z-II space is). That, combined with a CHIP bufmemtype (which you already figured out) should make the A2090 work on an A3000. We've added a flag to 2.0 to allow Z-II devices to get guaranteed allocations from 24-bit space, but that doesn't help older drivers. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"