Xref: news2.mv.net comp.os.msdos.djgpp:4161
From: Shawn Hargreaves <slh100 AT york DOT ac DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: SVGA direct memory access: why so slow???
Date: Wed, 22 May 1996 13:20:46 +0100
Organization: The University of York, UK
Lines: 60
Message-ID: <Pine.SGI.3.91.960522093754.7942B-100000@tower.york.ac.uk>
NNTP-Posting-Host: tower.york.ac.uk
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
In-Reply-To: <4nq17c$2a2@nyheter.chalmers.se>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

On 20 May 1996, Arash wrote:

> I'm trying to copy a linear bitamp to a 640x400x256 screen.

Are you aware that 640x400x256 isn't supported by all SVGA chipsets? In 
particular a lot of cirrus cards (which are pretty common) can't handle 
it. 640x480x256 might be a better choice, plus it has the advantage of 
square pixels.

> Everything works just fine, the only problem is the slow paging function 
> which (i think) is the most time-consuming routine here since it uses an 
> external interrupt (video, int 0x10). I just get the "SVGA programmers 
> guide" 1600 pages :( but i don't think there are many PMODE-code in it...
> 
> I think i should use vga-resgister insted of an interrupt, or write to 
> all pages without page switching (like mode X 320x240), but i don't know 
> how to do it...

I think you are mistaken about where the clock cycles are being spent: 
try using the profiler. The real mode VESA bank switching functions are 
slow, but not that slow, and you are only doing four of them per page. 
The killer is the copying of data: 640x400 = 250k, which is a lot of 
bytes to be moving around. There isn't very much you can do about this: 
dosmemput() copies them in an optimal manner, so the only solution is to 
somehow cut down how much data needs moving.

If you are concerned about the bank switch time, you should investigate 
the VESA 2.0 interface. With a VBE 2.0 driver like UniVBE, on some cards 
this lets you select a linear framebuffer mode, which doesn't require 
bank switching. Even on cards that don't support linear addressing, VBE 
2.0 will provide you with a chunk of protected mode code to switch banks, 
which you can copy into your address space and call without having to 
switch to real mode. Check out my Allegro library for examples of using 
these... Using hardware registers directly is also possible, but be 
warned that every SVGA chipset does these differently, so you could be 
in for a lot of coding :-)

> void CopyBuffer(void){
>     Page(0);	dosmemput(Buffer,1L << 16, 0xa0000);
>     Page(1);	dosmemput(Buffer + (1L << 16),1L << 16, 0xa0000);
>     Page(2);	dosmemput(Buffer + (1L << 17),1L << 16, 0xa0000);
>     Page(3);	dosmemput(Buffer + (1L << 17) + (1L << 16), 59392, 0xa0000);
> }

This code is not correct. You are assumming 64k banks, aligned on 64k 
boundaries. This is true for about 90% of SVGA chipsets, but will fail 
miserably on the remaining 10%. Some cards have 4k or 16k bank alignment, 
and other sizes are also possible, plus on some chipsets (I think the 
early Trident cards, among others) you can address 128k of video ram 
directly, rather than just 64k. Information about the bank size and 
granularity is returned in the VESA mode information structure: you 
should use this, if you want your code to be reliable...


/*
 *	Shawn Hargreaves.        Why is 'phonetic' spelt with a ph?
 *	Check out Allegro and FED on http://www.york.ac.uk/~slh100/
 */