delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1997/09/01/11:43:06

From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9709011542.AA17704@clio.rice.edu>
Subject: Re: _dos_ds segment limit
To: Vik DOT Heyndrickx AT rug DOT ac DOT be (Vik Heyndrickx)
Date: Mon, 1 Sep 1997 10:42:30 -0600 (CDT)
Cc: eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com
In-Reply-To: <340A90A4.5BA0@rug.ac.be> from "Vik Heyndrickx" at Sep 1, 97 11:53:40 am

> Well, no, I didn't publish the results as such. Because I didn't get any
> report from someone who had a 32-bit video access problem and I bought
> in the meantime a new computer I "forgot" all about it.
> 
> Results:
> - on very slow computers (386SX) or video hardware (slow VGA, old
> Hercules, ...), 32 bit goes as fast as 16 bit!
> - on fast computers and video hardware, results vary, from factor 1 to
> factor 2 speed up.
> Since text mode output doesn't really put high requirements on
> performance, it wouldn't be any problem at all to change it from 32 to
> 16 bits.

The ScreenUpdate call from djgpp used 32 bit writes to the text page.
32-bit writes were chosen since they were almost 2X faster for many 
machines, and it had no bad effects on thousands of machines tested.
If the bus does not support 32-bit access (ISA) the chip set is supposed
to handle it properly.

If a particular piece of hardware doesn't, it's broken and needs to be
programmed around.  Slow computers need the performance a lot - especially
when trying to do rapid screen updates.  Why punish them due to one piece
of broken hardware?  That's like forcing us all to use the 8088 instruction
set since some computers don't support the 386 instructions...

- Raw text -


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