www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/06/18/19:53:34

Xref: news2.mv.net comp.os.msdos.djgpp:5145
From: matt AT elite DOT powernet DOT co DOT uk (Matt Bernstein)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Why is grx20 so slow ?
Date: Tue, 18 Jun 1996 17:45:25 GMT
Organization: Power Internet
Lines: 39
Message-ID: <4q6qap$q8t@power2.powernet.co.uk>
References: <hector DOT 3 DOT 834568444 AT leei DOT enseeiht DOT fr>
NNTP-Posting-Host: elite.powernet.co.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

hector AT leei DOT enseeiht DOT fr (Jean Hector) wrote:

>With any driver, the mouse test program MOUSETST is much more slower in
>the 16 colors mode than in the 256 colors mode (not possible with stdvga).
>Is there a reason ? Is there a solution ?
>JH.

Not a very good explanation because I've never programmed 16-colour
VGA, but whereas 256 colour modes are easily written to with a byte
per pixel, VGA memory is organised in a truly hideous way (summat like
this) :-


PAGE1
	BYTE 1		BYTE 2		BYTE 3		...
	11010111	01101110	10110010

PAGE2
	BYTE 1		BYTE 2		BYTE 3		...
	01010110	10101001	00011000

PAGE3
	BYTE 1		BYTE 2		BYTE 3		...
	00100101	11100110	11011011

PAGE4
	BYTE 1		BYTE 2		BYTE 3		...
	00100111	11010101	11101111

The first pixel in this case has the value 0001, the second 0011, the
third 1100 and so on... (I hope this makes sense)

Because we have to do all this paging nonsense, 16-colour VGA is much
slower than 256-c VGA. There may be other factors which slow down the
mouse-driver, but this is the obvious one which I can think of. The
basic answer is do everything in 640x480x256 minimum...

	Matt Bernstein (matt AT elite DOT powernet DOT co DOT uk)

- Raw text -


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