Xref: news2.mv.net comp.os.msdos.djgpp:4183 From: Jonathan Markland 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: NNTP-Posting-Host: cst145.york.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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.