Amiga 3000UX

[Mike "Ford" Ditto]

In article <1991Jan17.034938.9679 at zorch.SF-Bay.ORG> xanthian at zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>ford at 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 at amix.commodore.com
 - They Might be Giants,		uunet!cbmvax!ditto
   "We want a rock"			ford at kenobi.commodore.com