Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!apple!portal!cup.portal.com!Lee_Robert_Willis
From: Lee_Robert_Willis@cup.portal.com
Newsgroups: comp.sys.amiga
Subject: Virtual CHIP Memory
Message-ID: <32861@cup.portal.com>
Date: 16 Aug 90 03:05:33 GMT
Organization: The Portal System (TM)
Lines: 40

WHAT'S THE HOLD-UP ON THE AMIGA HI-RES GRAPHICS CARD?

Commodore has stated that the reason an improved graphics card for the Amiga
(e.g. 24 bit, 1024x1024 pixels) has been so long in coming is the problem of
maintaining compatibility with existing Amigas.

I don't understand what the problem is.  All Amiga graphics capabilities are
accessed via the Amiga run-time libraries (e.g. "layers.library", 
"intuition.library", "graphics.library", etc.) which are not compiled into 
the applications, but are dynamicly loaded at run-time.  Because of this, it
should not be necessary that a new graphics card be hardware compatible with
the existing chip set.  It should be possible to use any kind of hardware, as
long as a set of run-time libraries can be written which are software-
compatible with the existing libraries (i.e. each call has the same name and
takes the same parameters).  e.g. Why can't I hook up a TrueVision Targa 
board with a Targa graphic version of the libraries?

HOW ABOUT VIRTUAL CHIP MEMORY?

Currently the Amiga 3000 has almost unlimited (1.5 Gigabytes!) FAST memory,
but the custom chip set (Fat Agnus, et. al.) is limited to 2 Megabytes of
CHIP memory.  This limitation could be removed without modifying the 
hardware by changing the operating system to implement "virtual" CHIP memory.
In this scheme, CHIP memory would not be directly allocated by applications
at all.  Instead "VCHIP" memory would be allocated in FAST mem, which would
allow all FAST memory to be used (witht the restriction that no 1 contiguous
block can be larger than the available 2 Megs of CHIP mem).  When VCHIP 
mem is used (e.g. a graphic is drawn, a sound is played, etc.) the VCHIP
block would be DMA swapped into CHIP memory (the same way virtual memory
memory is swapped on OSs that support it) and then sent to the custom 
hardware.  A VCHIP block then remains in CHIP memory until another VCHIP 
block needs access to the custom chips.  VCHIP blocks are swapped on a
least-recently-used basis, so that memory that is used frequently will
stay in CHIP memory and not pay the performance penalty for the DMA swap.
Granted, some VCHIP mem will always be in CHIP memory (e.g. the bitmap
for the current display), but a lot of current uses for CHIP memory could
just as easily exist in FAST mem (e.g. sound files when not being played,
Brushes on the clipboard, portions of windows/screens which are occluded).

So Commodore, is this feasible?