Mail Archives: djgpp/1996/05/23/03:18:58
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
|
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/
*/
- Raw text -