Lee_Robert_Willis@cup.portal.com (08/16/90)
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?
seanc@pro-party.cts.com (Sean Cunningham) (08/18/90)
In-Reply-To: message from Lee_Robert_Willis@cup.portal.com Did you know that this is already implemented? WB2.0 has the "virtual desktop" feature allowing you to have a WB screen slightly greater than 32000 x 32000 pixels. Do you think this screen is possible with only 2Mb of chipmem? If so, go down and try it on your friendly neighborhood dealer's demo machine and see what happens... All that extra screen memory is stored in fastmem, and then shifted to chipmem when you scroll the screen...you need something like 12Mb for the full screen bitmap... Sean //////////////////////////////////////////////////////////////////////////// UUCP: ...!crash!pnet01!pro-party!seanc | ARPA: !crash!pnet01!pro-party!seanc@nosc.mil | " Fanatics have their INET: seanc@pro-party.cts.com | dreams, wherewith they | weave a paradise for RealWorld: Sean Cunningham | a sect. " Voice: (512) 994-1602 PLINK: ce3k* | -Keats | Call C.B.A.U.G. BBS (512) 883-8351 w/SkyPix | B^) VISION GRAPHICS B^) \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Lee_Robert_Willis@cup.portal.com (08/18/90)
Sean replies: >Did you know that this is already implemented? > >WB2.0 has the "virtual desktop" feature allowing you to have a WB screen >slightly greater than 32000 x 32000 pixels... No, I was not aware of the maximum size of the virtual workbench. (I'm running an A500 til I can save up more $s) But is virtual CHIP memory available only for workbench screen window graphics, or is it available for any type of CHIP mem (e.g. sound files, non-workbench screen windows)? Lee
seanc@pro-party.cts.com (Sean Cunningham) (08/20/90)
In-Reply-To: message from Lee_Robert_Willis@cup.portal.com Well...I'm not sure exactly how it works (but there is probubly a GURU around here that does), but I have, on more than one occasion, played 8SVX files greater than the 2MB of chipmem on the A3000. I beleieve the largest was 3.5Mb, and I've heard of someone playing a 6Mb soundfile (I don't have access to a machine with this kind of RAM, so I can't test it out...). It should work the same with graphics... Sean //////////////////////////////////////////////////////////////////////////// UUCP: ...!crash!pnet01!pro-party!seanc | ARPA: !crash!pnet01!pro-party!seanc@nosc.mil | " Fanatics have their INET: seanc@pro-party.cts.com | dreams, wherewith they | weave a paradise for RealWorld: Sean Cunningham | a sect. " Voice: (512) 994-1602 PLINK: ce3k* | -Keats | Call C.B.A.U.G. BBS (512) 883-8351 w/SkyPix | B^) VISION GRAPHICS B^) \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
peter@cbmvax.commodore.com (Peter Cherna) (08/21/90)
In article <3972@crash.cts.com> seanc@pro-party.cts.com (Sean Cunningham) writes: >In-Reply-To: message from Lee_Robert_Willis@cup.portal.com > >Did you know that this is already implemented? > >WB2.0 has the "virtual desktop" feature allowing you to have a WB screen >slightly greater than 32000 x 32000 pixels. Do you think this screen is >possible with only 2Mb of chipmem? If so, go down and try it on your friendly >neighborhood dealer's demo machine and see what happens... > >All that extra screen memory is stored in fastmem, and then shifted to chipmem >when you scroll the screen...you need something like 12Mb for the full screen >bitmap... The support for oversize scrollable screens in 2.0 still requires that the whole screen is kept in chip memory. The maximum size is determined by your available chip memory. If you like, you could make it 20000x400 or 640x20000, or 3000x3000, but 20000x20000 would require too much memory. If you try to ask for a screen that's too big, you won't get it. > RealWorld: Sean Cunningham | a sect. " Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com My opinions do not necessarily represent the opinions of my employer. "Very strange... the window is broken on both sides."