Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!easy!lron From: lron@easy.hiam (Dwight Hubbard) Newsgroups: comp.sys.amiga.hardware Subject: Re: Bank switched CHIP RAM? (Re: 24 Bit Video ..) Message-ID: Date: 15 Oct 90 23:24:41 GMT References: <1990Sep28.022138.19237@zip.eecs.umich.edu> <1990Sep30.233751.3244@zorch.SF-Bay.ORG> <1990Oct3.194556.7031@lth.se> <106878@convex.convex.com> <1990Oct8.211957.2528@lth.se> <15057@cbmvax.commodore.com> Lines: 48 >In article <15057@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article lron@easy.HIAM (Dwight Hubbard) writes: > [previous junk deleted] >That might be kind of cool. And in fact, you could write such a GFX: >filesystem, though of course that's not the same thing as pure device >independent graphics -- you don't want the overhead of a filesystem type >server to do all your graphic commands (then again, the X Windowing system >does it kind of similarly). I suppose you would want the GFX: device to >support multiple devices. A preference editor might set up the default >for GFX:, maybe as a window on Workbench. You could pick a display card >simply by name; maybe "GFX:BuiltIn" for the standard Amiga graphics, >"GFX:A2410" for that ULowell card, etc. I suppose the best thing for such >a device to do would be for it to speak in a high level graphics language >that's byte stream rather than function call based. Just like with disks, >there would be a device driver under the GraphicsSystem, and for higher >performance you could look up the particular graphics.device based on the >filing system name for the unit. Kind of weird, but interesting. Based on >the fact that it's all done in byte streams, you could do things with filters, >like: > > type pic.ilbm | ilbm_2_gfx | GFX:Builtin/640/400/4 > >Or somesuch. Similar filters could handle PHIGS, PostScript, whatever, with >enough effort. You don't want GFX: to speak ILBM as a native language, but >something much higher level, so you can send it "draw a circle", "fill this >rectangle", etc. type commands. > Very close to what I was thinking. The graphics.device itself ideally should be in a rom on the display card and autoconfig on power on. Also, it should be able to handle the same low level functions that the current graphics library handles. I like the idea of a Dos level handler because it would make it possible to access the graphics display as a device. Possibly allowing more than one system to use the same display adapter over a network, as well as the fact that it would make it more flexible. I think however it would be better to make a dos level Intuiton Device which would access all the display adapters and filters installed in the system. For example type postscriptfile.eps > INTUI:Postpic/640/400/2/2024/EPS Could be used to display an EPS file in a window with 2 colors on a 2024 monitor. (Suggestion only, your turn to poke it full of holes.) -- -Dwight Hubbard, |-Kaneohe, HI -USENET: uunet.uu.net!easy!lron |-Genie: D.Hubbard1 lron@easy.hiam |-GT-Power: 029/004