Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.unix.amiga Subject: Re: Amiga 3000UX Message-ID: <1991Jan17.034938.9679@zorch.SF-Bay.ORG> Date: 17 Jan 91 03:49:38 GMT References: <388@ariel.ucs.unimelb.edu.au> <1991Jan12.155932.18406@cbnewsm.att.com> <796@amix.commodore.com> Organization: SF-Bay Public-Access Unix Lines: 49 pal@ariel.ucs.unimelb.edu.au (Philip Leverton) writes: Our system only had 5 Mb of memory mls@cbnewsm.att.com (mike.siemon) writes: AT&T/USL recommends a minimum of 6 Megabytes for OPEN LOOK ford@amix.commodore.com (Mike "Ford" Ditto) writes: Also, remember that experienced AmigaDos users (and probably Commodore marketing types, too) think of a basic A3000 (4 Meg fast, 1 Meg chip) as a "5 Meg" system, while Unix consideres this to be a "4 Meg" system. The Amiga's "chip" memory, to Unix, is like the frame buffer memory on a graphics card. It is never used for the system's virtual memory. It is used for floppy and sound DMA, copper instructions, and (primarily) bitplane memory for the many virtual screens. This might change in a future software release, since there will be people with 4 Meg fast and 2 Meg chip, and they will need more system memory and certainly wouldn't come close to using the whole 2 Meg chip Ram. -=] Ford [=- Yeep, Mike! _Never_ tell a graphics person s/he "wouldn't come close to using" _any_ resource. The resource hunger of graphics processing is insatiable and the stuff of legends. Don't fix this "problem"; it's the wrong thing to fix. Fix the '020 and '030 add on cards so that they can support more than 4 Meg of memory, or provide a CBM 32 bit in the box expansion memory card that works with them, and let Unix continue to think chip is off limits; it will make life _so_ much simpler for all concerned, since it takes away the need to "fix" Unix to do chip right, and mend the huge existing software base to cooperate. [If it turns out to make sense, you might arrange a way for it to be still in the Unix flat virtual address space, but spoof Unix into thinking it is already allocated. This could be done by moving the start of the stack, or whatever's at the high end of virtual memory, down to make room for chip or video card memory addressing during autoconfigure time. This might work, since existing Unix software shouldn't try to address past the base of the stack.] Kent, the man from xanth.