pal@ariel.ucs.unimelb.edu.au (Philip Leverton) (01/11/91)
We had an Amiga 3000UX as a demo machine here for a while. It had SysV R4 beta on it (I don't remember which minor beta rev it was). Here are a few comments that I have on it: Favourable: Interfaced with our campus network ok. It was easy to install a default route and TCP/IP worked fine with it. Someone even logged into our machine from interstate using a guest account. You might want to check the password file for such accounts and turn them off or delete them if you are going to sit the Amiga on a network. System V did not seem too bad; although I don't use SysV regularly at all. troff worked well, including converting the output to PostScript with dpost. (your own personal troffcomputer :-) Could display X clients on other machines without any problems (the target machine I used was a DECstation 3100). I liked the virtual screens feature. Problems: Our system only had 5 Mb of memory which meant that using Open Look/olwm was painful since the system was limited by very frequent disk accesses. As I think the docs say, 8 or 16 Mb would be much better. The C shell has a few gliches: putting a job into the background and then killing it logs you out. Job control in the ksh seemed stable though. Filename completion in the C shell didn't work correctly; Upon typing ESC the pathname would be completed on screen but that information did not get back to the system and it would act like no text was there. As another poster mentioned, I could't find a way to get Open Look going in colour. There were some bugs evident in Fortran at higher optimisations; however a fairly large nuclear physics program from one of our main machines compiled and executed properly. Also I couldn't figure out how to authorise X programs to display on the Amiga under Open Look. I'm sure I tried looking for obvious things like xhosts or menu options but had no luck. Next week we are getting a demo of the machine running multimedia applications so I'll be able to see how it performs in that arena. Phil Leverton, Information Technology Services, Univ of Melb, Australia
mls@cbnewsm.att.com (mike.siemon) (01/12/91)
In article <388@ariel.ucs.unimelb.edu.au>, pal@ariel.ucs.unimelb.edu.au (Philip Leverton) writes (among other interesting points) > Our system only had 5 Mb of memory which meant that using Open Look/olwm > was painful since the system was limited by very frequent disk accesses. > As I think the docs say, 8 or 16 Mb would be much better. AT&T/USL recommends a minimum of 6 Megabytes for OPEN LOOK* at this stage (we're working on reducing this; it used to need 8 -- X tends in general to be a real memory hog). I would agree that doing anything serious needs 8 meg. > As another poster mentioned, I could't find a way to get Open Look > going in colour. I'm sure that's doable -- I've seen color operating at the UNIX International booth at las fall's UNIX Expo in NYC. > Also I couldn't figure out how to authorise X programs to display on > the Amiga under Open Look. I'm sure I tried looking for obvious things > like xhosts or menu options but had no luck. That seems odd; an xinit or olinit from the console *should* fire up a server and xterm or OL workspace, allowing local clients, and xhost + should allow running of clients from elsewhere; since you say you've run Amiga clients on other servers, I assume your networking is all set up OK. Dunno about the cshell, but if I fire up the server as a background task under the Korn shell it waits and has to be brought into the foreground to get going. You should have a "virtual" terminal switch at that point. All of this is generic SVR4.0 and OL, and I wouldn't expect it to differ on an Amiga. ------ * OPEN LOOK, UNIX, etc., etc. are trademarks of USL, etc. etc. -- Michael L. Siemon We must know the truth, and we must m.siemon@ATT.COM love the truth we know, and we must ...!att!attunix!mls act according to the measure of our love. standard disclaimer -- Thomas Merton
guy@auspex.auspex.com (Guy Harris) (01/13/91)
>AT&T/USL recommends a minimum of 6 Megabytes for OPEN LOOK*
Which toolkit(s), which X server, which window manager? OPEN LOOK is a
spec, not software, so it can't really be said to require any specific
amount of memory. (Yes, I know AT&T uses OPEN LOOK as the name of some
software; they should stop doing so.)mls@cbnewsm.att.com (mike.siemon) (01/14/91)
In article <5213@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > >AT&T/USL recommends a minimum of 6 Megabytes for OPEN LOOK* > Which toolkit(s), which X server, which window manager? OPEN LOOK is a > spec, not software, so it can't really be said to require any specific > amount of memory. (Yes, I know AT&T uses OPEN LOOK as the name of some > software; they should stop doing so.) I didn't think an Amiga group really needed the matter thrashed out _in extensu_; since my note specifically refered to a USL recommendation, I presume that intelligent readers will infer that I am speaking of the USL product, which is what I have seen running on Amigas at trade shows. This product offering is a USL server (modified from the MIT reference source) and the Xt-based OPEN LOOK toolkit (same as what is called OLIT in Sun's current offering.) The *source* code for UNIX SVR4.0 includes NeWS and XView (I do not know details about versions of these), but I do not know if these are offered with the Amiga -- that's an OEM decision. -- Michael L. Siemon We must know the truth, and we must m.siemon@ATT.COM love the truth we know, and we must ...!att!attunix!mls act according to the measure of our love. standard disclaimer -- Thomas Merton
ford@amix.commodore.com (Mike "Ford" Ditto) (01/16/91)
In article <388@ariel.ucs.unimelb.edu.au>, pal@ariel.ucs.unimelb.edu.au (Philip Leverton) writes: > Our system only had 5 Mb of memory In article <1991Jan12.155932.18406@cbnewsm.att.com> mls@cbnewsm.att.com (mike.siemon) writes: > AT&T/USL recommends a minimum of 6 Megabytes for OPEN LOOK 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 [=- "A just machine to make big decisions (In Real Life: Mike Ditto) programmed by fellows with compassion ford@amix.commodore.com and vision." - Donald Fagen, "IGY" uunet!cbmvax!ditto ford@kenobi.commodore.com
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/17/91)
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. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
ken@cbmvax.commodore.com (Ken Farinsky - CATS) (01/18/91)
In article <1991Jan17.034938.9679@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >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... The 2630 card does support more than 4Mb of memory through a daughter board. Currently there is no company making such a product, but the 2630 does support more 32-bit memory (up to 64Mb). -- -- Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines uucp: ken@cbmvax.commodore.com or ...{uunet,rutgers}!cbmvax!ken bix: kfarinsky
daveh@cbmvax.commodore.com (Dave Haynie) (01/18/91)
In article <1991Jan17.034938.9679@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >pal@ariel.ucs.unimelb.edu.au (Philip Leverton) writes: > The Amiga's "chip" memory, to Unix, is like the frame buffer memory > on a graphics card. .... This might change in a future software release > -=] Ford [=- >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; The A2620/30 memory can't easily be extended on-board. The A2620 is really limited to the 4 Megs of 32 bit memory, plus any 16 bit memory you could add (which isn't going to be favored by UNIX). There is a way to move the 32 bit memory of the A2620 up to $01000000, thus freeing up the expansion bus for up to 8 Megs of 16 bit RAM. Not great, and you'd lose some disk speed, but the 16 bit RAM should be faster than paging. Realize that 4 Megs of RAM seemed pretty good back in 1987 when we started the A2620 and only had to deal with a plain SVR3. I doubt UNIX is clever enough at the moment at least to handle such a mutant A2620, but you never know. The A2630, as mentioned elsewhere, can support a large add-on memory daughterboard. Though none currently exist. At one point, UNIX knew about this kind of memory, though I have no idea if it still does. >Kent, the man from xanth. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley
ford@amix.commodore.com (Mike "Ford" Ditto) (01/23/91)
In article <1991Jan17.034938.9679@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >ford@amix.commodore.com (Mike "Ford" Ditto) writes: > 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. > >Yeep, Mike! _Never_ tell a graphics person s/he "wouldn't come close to >using" _any_ resource. Well, although I'll admit that anything's possible, a little figuring leads me to believe that it'd be quite unlikely for a 4 Meg Unix system to use up 1 Meg of chip RAM. I figured (not recently or I'd post the exact figures) that 1 Meg of chip RAM gives you approximately: ten 640x400x1 virtual consoles, one on each of the 10 virtual screen sessions, plus ten 640x400x4 color screens running X or whatever, plus two 1024x800x2 A2024 screens all at once, plus enough left over for some scratch bitmaps for double buffering in some of those screens. On the machine configuration I described, (4 Meg main memory) you wouldn't want to run that many programs at once unless they were pretty trivial. That's why I think that "anyone" would prefer 5 Meg fast + 1 Meg chip over 4 Meg fast + 2 Meg chip. I'd still make it an option, of course; anything's possible. >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, Even that isn't really the problem I was addressing. It's this one: Poor starving student buys minimal A3000 configuration (1 Meg fast + 1 Meg chip). Student saves up pennies and can now afford to buy 4 Meg of RAM and Unix. The 1 Meg of DIPs now move over to become chip RAM. Student can only barely (and slowly) run X because there is only 4 Meg of main memory. And three quarters of the chip RAM is completely unused. Student wishes some of that wasted memory could be used to make X go faster. And if the fast RAM is 1 Megabit chips (not 4 Megabit), the system is sort of locked out of inexpensive fast RAM expansion. >[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.] This all sounds very complex, much more complex than things really are. The chip memory distinction is a physical memory issue, not related to virtual memory at all. The kernel has untranslated access to all of physical memory and keeps its own track of what is main memory and what is chip. The virtual address space of each process doesn't include any chip memory unless a screen has been opened and mapped into memory. (Even if software "shouldn't" address past the stack, I would never map anything there that didn't belong to that process.) If a process wants to access the bitplane memory of a screen, it maps the memory into its address space using the mmap() system call. There is no other reason for a program to access chip memory. (Back to the original issue: The particular way this would probably be implemented is simply just to allocate a big chunk of chip memory and add it to the system main memory. No special knowledge of "sharing" chip memory would be added.) -=] Ford [=- "But everybody wants a rock (In Real Life: Mike Ditto) to wind a piece of string around." ford@amix.commodore.com - They Might be Giants, uunet!cbmvax!ditto "We want a rock" ford@kenobi.commodore.com