GSX-86: Graphics
for
the
APe
9-44
THE
GRAPHICS
INPUT/OUTPUT
SYSTEM
(GIOS)
The
GIOS
contains the device-dependent code in the GSX-86 system. Its
is
analo-
gous the
CP/M-86
BIOS
but
pertains to graphics devices only. The
GIOS
contains a
GIOS
file,
or
device driver,
for
each
of
the graphics devices
on
the system. Each
GIOS
file contains code to communicate with a single specific graphics device. A
major
difference between the
GIOS
and
the BIOS
is
that
while all device drivers
contained
within the BIOS are resident in memory
at
the same time, only one
graphics device driver
is
resident
at
a given time. The active device
must
be changed
by
a request from the application
program.
Creating A
GIOS
File
GSX-86 is distributed with a
number
of
device drivers
for
popular
graphics devices.
The device drivers are listed in Table 9-1.
If
your
devices
are
included in the table,
you
need only to edit the Assignment Table file to ensure
that
it reflects the logical
device numbering assignments you prefer. However, if
your
device is
not
supported,
you
must
create a driver
program
for
it. You can write a driver in
any
language,
but
at
least
part
of
it is usually implemented in assembler due to the low-level hardware
interface required.
Device driver files must
be
in
standard
CMD
format so they can be loaded by the
GDOS.
The driver must provide the functions listed as required in the
VDI
specifi-
cation
and
must
observe the
VDI
parameter
passing conventions.
If
the graphics
device itself does
not
support
all the
GDOS
operations directly, the driver must
emulate the capability in software.
For
example, if a
plotter
cannot
produce a
dashed
line, the driver
must
emulate it
by
converting a single dashed line
into
a series
of
short
vectors
and
transmitting them to the plotter.
The
CP/M-86
Program
Development Aids diskette contains a listing
of
the device
driver for the APC.
Use this as a model if you develop
your
own device driver.
Device drivers are invoked with a
"CALLF"
from GSX-86,
and
should
return
with a
"RETF".
The driver must switch to its own stack for internal use, except for
an
allowed overhead
for
a few pushes
to
save the caller's context. The following entry
procedure
is
recommended.