Date: Tue, 26 Jan 93 14:11:38 +0200
From: Grzegorz B. Mazur <gbm AT ii DOT pw DOT edu DOT pl>
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: VESA driver development

VESA driver for DJGPP seems to be ready. I am testing it now, and
I am planning to release it soon. But first, I would like to present
some information on it to the public and wait for your answer
- acceptance or rejection.

Besides preparing a new driver, I had to change three modules in
GO32, and slightly redefine some driver flags and parameters.
Here is the summary of my work:

1. Mode 9 set interface (xres, yres, no_of_colors) is now redefined as
(xres, yres, color_info), where color_info is exactly the same as
no_of_colors for no_of_colors <= 32768. For modes with more colors
I use the value (0xc000 | bits_per_pixel), which yields 0xc010 for
64K colors and 0xc018 for 16M colors. Note that you can still arithmetically
compare numbers of colors in different modes. New symbolic constants have been
defined for identifying these color modes. By the way - constant defining
mode with 15 BPP is named with "16", so I had to use "16X" for real 16 BPP.

2. VESA mode numbers start with 100h, so "special" actions for mode
setting inside driver are now marked with 1000h, 2000h, etc. (instead
of 100h, 200h...) - this should not be visible by user.

3. Mode set routine now returns info in ax, bx, cx, dx, si, di and es.
Hopefully the compiler does not allocate si & di in mode set routine.
These values must be handled by GO32 (module graphics.c). AX contains
granularity (more on this later), ES:DI - pointer to VESA paging routine,
SI - BytesPerScanline (for truecolor modes this is usually
larger than actual line length, say 2048 bytes for 640-pixel line).
Paging routine can be (at least in theory) different for each mode,
so graphics.c now rebuilds a descriptor in gdt after each mode switch, based
on returned address. Granularity and line offset are recorded in public
variables. VESA driver, or rather the need for extra info handling,
can be recognized by checking the value of ES after calling modeset
- standard driver does not modify it during mode set.

4. I added about 10 lines to grprot.asm. Now it uses granularity variable.
Granularity is != 0 for all VESA modes requiring bank switching, so it
can be used as a flag. If it is non-zero, parameters are passed to switching
routine in VESA manner (bank # in dx), and bank number is adjusted
according to granularity.

5. There is a need to pass BytesPerScanline value to the user. I decided
to provide an extra function called by int10 with ah = 0xfd (ff is mode set,
and fe - inquiry). The function will simply return BytesPerScanline.

6. I am going to identify VESA driver with 0x000f "or" value for driver
flags, marking new driver and memory mode 7 (unused so far). This is not
necessary, so if anyone votes against it, there will be no special
marking on VESA driver.

7. The driver will be accompanied by new "grm" minigraphics library. The
library will provide mode set, parameter query, putpixel, putimage and
putchar/ putstring functions, working in all modes with >= 256 colors.
You can still use grx for modes up to 32768 colors - I use it for testing.

8. There is a need for a new definition of graphics interface. Soon we
will see VGAs with > 1MB memory - this will require the change of
addressing scheme used by DJGPP.

9. I am not planning to support linear addressing (I mean REAL linear,
without bank switching). The reason is that linear VGA memory address in these
modes must fit in first 16MB of physical address space (only 24 bits of
address appear on ISA bus), and this is the place where most of PCs will
have regular RAM by the end of this year. (Mine already has.)

10. Special VESA functions, like panning, >6 bit palette etc. will
be supported some time in the future. I think it is necessary to
redesign the driver interface first.

If I receive no protests during one week after releasing this message,
I will make the driver accessible to everyone for in-depth testing.
Meanwhile I will test it on Cirrus AVGA3 and Trident TVGA 8900.
I have neither Tsengs nor experience with them - looking for volunteer
to test the driver on Tseng ET4000 w/HiColor or TrueColor and VESA BIOS.

I am trying to force my sysadm to open anonymous ftp on our computer.
Is there any other method to distribute the software it to DJGPP people,
please let me know.

Gregory