delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/05/23/19:05:04

Xref: news2.mv.net comp.os.msdos.djgpp:4183
From: Jonathan Markland <jrm101 AT tower DOT york DOT ac DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: SVGA direct memory access: why so slow???
Date: Thu, 23 May 1996 19:50:36 +0100
Organization: The University of York, UK
Lines: 76
Message-ID: <31A4B37C.5967@tower.york.ac.uk>
References: <Pine DOT SGI DOT 3 DOT 91 DOT 960522093754 DOT 7942B-100000 AT tower DOT york DOT ac DOT uk>
NNTP-Posting-Host: cst145.york.ac.uk
Mime-Version: 1.0
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Shawn Hargreaves wrote:
> 
> On 20 May 1996, Arash wrote:

[snip]

> > Everything works just fine, the only problem is the slow paging function

You don't say which class of video card you are using. There is a tremendous
speed difference between ISA cards, compared to (even cheap) VL-Bus/PCI
versions. (Yes, I am bearing your particular application in mind. I'm not
refering to the use of any special acceleration features).

[another snip because people have read it, and won't be able to locate my
 comments easily!]

> > 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...

Mode X is a disgusting nightmare (personal opinion). Theoretically trivial graphics
algorithms are a total pain to write using it. Avoid it if you possibly can,
although I accept that it's portable between VGA cards from different manufacturers.

In mode X, something as simple as addressing a single pixel entails writes to the I/O space,
which (if you consult appropriate Intel references) are VERY slow in comparison to ordinary
memory writes. Although you'll still need I/O to select a bank, it's much easier
to write ASM/C code that optimises the I/O space references down to a minimum if you're
not using mode X. (How easy will it be to unpack your picture format into Mode X format?)

On the SVGA PROGRAMMING INFO front, I searched SIMTEL for you, and came up with:

ftp://ftp.cdrom.com/.1/simtelnet/msdos/vga/vgadoc2.zip 
ftp://ftp.cdrom.com/.13/garbo/garbo_pc/doc-hard/vgadoc4b.zip 
ftp://ftp.cdrom.com/.2/dresden/program/general/vgadoc4b.zip 
ftp://ftp.cdrom.com/.6/linux/tsx-11/ALPHA/dosemu/Development/Reference/vgadoc3.zip 

I have vgadoc2.zip and vgadoc3.zip, which give useful info on programming
lots of cards, and I've implemented 32-bit flat memory stuff from this, for my
CL-5428.

BEAR IN MIND that any code you write using this info will only work for
a particular make of video card, although some are compatible, for example
you can use old ISA Paradise stuff with the (somewhat) newer Cirrus Logic
5428/9 cards. VESA bank switching was designed to solve compatiblity issue,
although real-mode switching is nasty for speed-merchants like myself.
If you do not intend distributing your program, then just make it work
on your own machine.

[Snip some more]

> Some cards have 4k or 16k bank alignment,
> and other sizes are also possible,

Yup. On my card, there's a register to select this.

> plus on some chipsets (I think the
> early Trident cards, among others) you can address 128k of video ram
> directly, rather than just 64k. 

You certainly can, and it's admission time:

I had a Trident, and discovered this fact myself, spent three
weeks writing some program or other using the 128K mechanism to provide
two pages of 64K for the purposes of 'double buffering' only to discover
that the code didn't work AT ALL on ANY other card I tried! Don't use
this!

> 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...

'Reliable?' You mean 'portable', Shawn.


Jonathan Markland. University of York, UK.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019