Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!seismo!rochester!ritcv!cci632!ccird1!rb
From: rb@ccird1.UUCP (Rex Ballard)
Newsgroups: net.micro.68k
Subject: Re: CD ROMs to use 68000 OS9
Message-ID: <419@ccird1.UUCP>
Date: Mon, 12-May-86 21:25:05 EDT
Article-I.D.: ccird1.419
Posted: Mon May 12 21:25:05 1986
Date-Received: Thu, 15-May-86 06:17:08 EDT
References: <808@ihwpt.UUCP> <1185@lsuc.UUCP> <994@amiga.amiga.UUCP>
Reply-To: rb@ccird1.UUCP (Rex Ballard)
Distribution: net
Organization: CCI Rochester Development, Rochester NY
Lines: 47
Summary: VDI vs. GKS

In article <1206@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes:
>
>     As VDI was explained to me, it is a Kernal based technology.  That
>is to say it is *position dependant*.  If this is so then it is also
>a system which makes support of one VDI device driver mutually exclusive
>of other VDI device drivers.  Have I misunderstood the point of VDI?

Yup!
There are basicly two levels of graphics interface, the GKS or graphics
kernal, which is very device specific, essentially the equivalent of
a BIOS or UNIX device drivers, and the Virtual Device Interface.
Part of the problem of course, is that the GKS isn't officially
standardized yet (but is available for OS-9).

The "graphics kernal" might be, for example, a bit mapped display,
or a driver that converts "interchange commands" to graphics processor
specific commands.  For a given "desktop", the VDI input (calls,
instructions, NAPLPS "text"... would be coverted from "device relative"
positions to "screen absolute" co-ordinates.  Also, the "kernal" would
perform any "clipping" necessary.  Ironically, VDI commands sent to,
or read from, a disk drive might actual "calls" or some other "script"
which can be directly executed or interpreted by the computer via
a simple "cat" command.  The VDI/Kernal interchange format could be
very much proprietary.  GEM's VDI commands, Mac's "Quickdraw", and
Intuition's VDI are quite different, but funtionally they are
practically identical.  OS-9 simply "interprets" VDI commands similar
to those of "Plot" on UNIX.  Unlike UNIX however, the output is sent
to a "mounted driver" rather than a "pipe" with it's blocking and
context switching overhead.  The end result, a full blown, fully 
interactive graphics system.

To give a simpler example, "curses" and "termcap" are used to convert
commands like "position curser" and "Insert lines" into "terminal
commands" found in the "/etc/termcap" file.  On OS-9, you could
just as easily mount the "VT-100 Driver" into your "environment"
and have the curses commands converted directly into curser motion.
In the case where a terminal does not have "insert line" but has
"set scrolling window" and "scroll window", these primitives could
be used instead of the driver.  If the screen were memory mapped,
the "driver" could directly manipulate the the screen as needed by
the "curses" calls.  Of course, you could still use the normal
curses/termcap technique if that was the driver installed.

Now the main point is that VDI can go both ways.  For example,
you could put NAPLPS in, and get VDI out, or vice-versa.  All
you would need to do is decide which format your computer host
wanted the "drive" to send.