Mail Archives: djgpp/1993/01/26/17:57:50
On Tue, 26 Jan 93 14:11:38 +0200,
B. writes:
>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.
I like these. They seem to be upward compatible with the way things
worked until now. Don't worry about SI and DI; Turbo C won't touch them
if it sees them used in just a single inline assembly statement.
>
>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.
>
The extender will have to intercept it for non-VESA drivers and return
the proper value. If we are in the middle of changing things again, let's
make sure that we are not using int 10h functions which are already
reserved in some environments. There was a recent problem with int 10h
fn 0xfe which is also used by Desqview. (I admit, it was my mistake
originally.)
>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.
>
I see no problem with it.
>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.
If I am not mistaken, the 64K color modes use the same layout as the
32K color mode. (i.e. one 16 bit word per pixel.) The only difference is
that the hardware ignores the most significant bit of the word in 32K modes
while it matters in 64K modes. If this is true then most of the GRX code
can be used for 64K modes, only the color management (colors.c) has to
be updated. I could also add the necessary low-level video RAM access
functions (there are only seven of them) for the 24BPP modes for the next
release of GRX.
>
>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.
Since you already changed the video page fault handling to accomodate
granularity values != 64K, wouldn't it be a good time to change the layout
of the video RAM mapping area at 0xd0000000 as well? Currently there is
only a 1MB gap between the read/write, read only and write only sections of
this area. We could increase it to say 8MB or even more. (there is nothing
in the way up to virtual address 0xe0000000). This would break current
libgr and libgrx programs only if they use video RAM to video RAM BitBlt-s.
Even the impact of this could be minimized with coordinated new releases of
the extender and all graphics libraries.
>
>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.)
>
No argument here.
>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
Additional stuff:
If this thing works out, we could make the VESA driver the built-in
graphics driver in GO32. This would make it possible for an ever increasing
number of people to simply omit the "driver" field from the GO32 env var.
Csaba Biegl
csaba AT vuse DOT vanderbilt DOT edu
- Raw text -