Date: Tue, 16 Mar 93 15:02:33 CST From: (csaba AT vuse DOT vanderbilt DOT edu) To: djgpp AT sun DOT soe DOT clarkson DOT edu Cc: dj AT ctron DOT ctron DOT com, se01!sjm AT gator DOT rn DOT com, gbm AT ii DOT pw DOT edu DOT pl Subject: GO32 1.10, GRX 1.03 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, -- he did the VESA extensions to GO32) and Scott (Scott Mark, -- 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