Mail Archives: djgpp/1993/03/16/16:32:40
Notes about the new GO32, GRX, 1MB+ video RAM and VESA compatibility
The purpose of this rather long posting is to inform the group and
especially DJ about the new features I plan to incorporate in GRX 1.03. I
expect to release GRX 1.03 at the end of March or early April. Some of the
new GRX features will require support from GO32. I would like to describe
in detail what changes I did (intend to do) to GO32 so that others
can comment on them. Depending on DJ's schedule I can either include an
"interim" GO32 (say, version 1.09b) in the GRX distribution, or just
release GRX 1.03 the same time when he releases GO32 1.10.
This post is partly based on the discussions we had with Gregory (Grzegorz B.
Mazur, <gbm AT ii DOT pw DOT edu DOT pl> -- he did the VESA extensions to GO32) and Scott
(Scott Mark, <se01!sjm AT gator DOT rn DOT com> -- he badly wants to use all the 2MB-s
of video RAM on his ATI ULTRA PRO card).
Some of the changes I am describing here are already completed in my
"working version" of GO32, others I plan to do this or next week. DJ: if
you intend to release GO32 1.10 before the anticipated GRX 1.03 release
date, I hope to be able to post (and/or send to you) all my patches by the
middle of next week.
For users who are not interested in the internal workings of GO32,
GRX, and the graphics drivers here is a short summary of the new GRX 1.03
features. They can skip the rest of this message.
- all "promised" graphics primitives (thick/dashed lines, etc..)
- page flipping/scrolling
- full support for 16BPP and 24BPP modes
- faster 256 color SVGA fill operations
- scalable fonts
- minor enhancements bug fixes
For the rest of you here are the issues I would like to solve in the
new GO32/GRX:
1. VESA support
===============
I would vote against using any VESA-specific BIOS call in the core GO32.
I have two reasons for this:
1) We would have to change GO32 any time a new VESA version comes out to
incorporate new features.
2) GRX already supports a few video adapter types for which there isn't
(and probably never will be) any VESA support. These include EGA and
8514/A cards.
What I am proposing is to extend the GO32 <=> driver interface such
that it supports all functions which can be implemented using the VESA
standard (i.e. various paging modes, large virtual screen, HW scrolling,
etc..). Additionally, I am proposing that we make the VESA driver the
"built-in" driver in GO32.
2. Paging issues
================
Gregory has already patched GO32 to use the paging granularity
reported by the VESA BIOS instead of the fixed 64K. I have incorporated
these changes in my version of GO32. On the other hand, I changed his
paging method. I intend to keep the driver paging function with the AL/AH
interface, and issue the VESA BIOS calls WITHIN the driver paging function.
Besides increased compatibility I have another reason for this: I am not
convinced that all VESA BIOS paging routines can be used in 16 bit
protected mode. I traced about ten different VESA paging routines (both
from TSR-s and ROM BIOS-es) and have seen the following three cases:
1) The VESA paging function does not use any data -- it only reads
and writes VGA registers. This can be run under 16bit PM without
any complications.
2) The paging function does something like this: (example
Diamond Stealth ROM BIOS VESA paging routine)
mov ax,40h
mov ds,ax
mov cl,[06eh] ; or something like this
I.e. the routine uses the BIOS data area.
This can be made to work in 16bit PM by providing the
(selector 0x40) => (16 bit, R/W, start address=0x400) segment
mapping in GO32.
3) The paging routine does something like this: (I have seen
this in a VESA LB S3 card in a SWAN 486/66DX2)
xor ax,ax
mov ds,ax ; 0 segment selector !!!!!!
mov cl,[046eh] ; or something similar
Tough luck! => Need to use the VESA paging function in REAL (or
at least V86) mode. Alternative: get a better replacement VESA BIOS
TSR.
The built-int VESA driver for GO32 will have TWO paging routines. Both of
them use the standard AL/AH page number interface. The first one uses the
far call version of the VESA paging routine in 16bit PM while the second
does a mode switch and calls the VESA routine in real mode. (We can
"steal" an unused int 10h function number for this.) There are two
special "driver" keywords on the GO32 environment variable recognized by
the driver init code in "graphics.c":
vesareal => use the built-in VESA driver w/ real mode paging
vesaprot => use the built-in VESA driver w/ protected mode paging
Users with well written VESA BIOS-es could use the protected mode
(faster) version, others have to use the real-mode version or
install/write a chipset specific driver. I don't plan to investigate the
possibility of running the VESA paging function in V86 mode for the 1.10
GO32 release. (It could be faster than a full mode switch.) If others want
to do this, that's fine with me, but we'd better make sure that it works
under every darn configuration imaginable (with or without VCPI, XMS,
etc..)
To support the transfer of the additional paging information
(granularity, etc..) and access to the other VESA functions (scrolling,
etc..) I propose an addition to the existing .GRN driver interface. Since
we are running out of registers usable for the GO32 <=> driver
communication I am currently using a parameter block filled out by the
driver whose address is passed to GO32 after every mode switch. The
presence of this block is indicated by a flag in the driver header meaning
"extended .GRN format". Without this flag GO32 uses only the .GRN or .GRD
services provided by the existing drivers. The extended .GRN driver
parameter block contains stuff like:
paging granularity
pixel organization for 24BPP modes
extended memory start address (see later)
virtual screen dimensions (see later)
etc..
In the absence of the parameter block GO32 uses suitable defaults, like:
64K paging granularity
no extended memory mapping
virtual screen dimensions = physical screen size
etc..
This way the new GO32 is still compatible with the existing .GRN and
.GRD drivers.
3. Support for more than 1MB of video RAM
=========================================
The basic problem with the current GO32 video RAM mapping is that
there is only a 1MB gap between the read/write read only and write only
frames at 0xd0000000, 0xd0100000 and 0xd0200000, respectively. Scott
suggested the following extension:
0xd0000000 \
0xd0100000 same as before for compatibilty with existing programs
0xd0200000 /
0xd1000000 new 16MB read/write page
0xd2000000 new 16MB read only page
0xd3000000 new 16 MB write only page
This allows pages of up to 16MB which will hopefully be big enough in
the near future [8-)]. On the other hand, programs linked with older
versions of libgr/libgrx will continue to run under the new extender. In
order to save memory currently I only map the first 4 MBytes of each new
region. At this time no card I know of uses more memory than this, so
using 48 KBytes on page tables for unused regions seems like waste to me.
What would really be nice is to allocate these page table entries upon
demand (i.e. when a page fault occurs) but this can really wait until
GO32 2.0.
GRX 1.03 will use the 0xd0?00000 ranges for modes using less than 1MB
of video RAM, and the 0xd?000000 ranges otherwise. This way programs
linked with the new GRX will run under older versions of the extender in
video modes requiring less than 1MB of video RAM.
4. Extended mapping of video RAM
================================
I agree with Gregory that extended memory mapping of video RAM causes
more chance for incompatibility than it is worth. I have run some
benchmarks with GRX in both a non-paged (320x200x256) and paged
(640x480x256) mode on a 486DX33 with a fast local-bus ET4000 card. The
performance difference was about 5%, i.e. this is how much you could gain
by eliminating the page-fault based graphics paging. On a ISA bus card the
gain would be even lower since the video RAM speed is slower while the
time for page fault handling stays essentially the same. My benchmark was
"semi-regular", consisting of random lines and rectangle fills. Drawing
pixels randomly all over the screen would probably do much worse. (But just
how typical is such a graphics application?)
Still, even though I don't plan to support extended memory mapping in
the "official" drivers, I would like to include a provisional support
mechanism for it in the GO32 <=> driver interface. Users' own custom
drivers could set whatever registers need setting on their particular card
and report the start address to GO32 in the extended driver parameter
block. GO32 would then map the reported address to the 0xd10000000 region.
5. Page flipping/hardware scrolling
===================================
The extended .GRN drivers will support a new mode:
GR_custom_graphics
This is similar to 'GR_width_height_color_graphics' but the user can
also specify the virtual screen sizes. I.e. it is possible to set up a
1024x768 256 color mode with a virtual screen size of, say, 1100x900 on a
1MB SVGA. There is a related new driver entry for setting the start
address of the displayed frame. This mechanism is suitable for both double
buffering or hardware scrolling. Using the VESA BIOS (1.2) these functions
are straightforward to implement in the driver, but with proper VGA
register operations they could also be implemented in chipset-specific
drivers.
It is the user's responsibility to check the result of the
GrSetMode(GR_custom_graphics,...) call using the GRX inquiry functions,
like:
GrScreenX()
GrScreenY()
GrCanvasX() new one: virtual X size
GrCanvasY() new one: virtual Y size
The driver's policy is to set up a mode as close to the requested
custom setup as possible. It cannot guarantee an exact match due to
memory size and other hardware limitations.
One final note on this: GO32 will optionally interface the screen
scrolling with the mouse event queue handler. Dragging the mouse on the edge
of the screen will scroll the graphics image if this feature is enabled in
the event queue interface. (This can be controlled by the application.)
Any comments?
Csaba Biegl
csaba AT vuse DOT vanderbilt DOT edu
- Raw text -