Date: Sun, 6 Aug 2000 09:36:11 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: David Witbrodt <dawitbro AT alpha DOT delta DOT edu>
cc: DJGPP mailing list <djgpp AT delorie DOT com>
Subject: Re: Conflict between IOSTREAMs and VGA writes
In-Reply-To: <398CFC29.4FAF2159@alpha.delta.edu>
Message-ID: <Pine.SUN.3.91.1000806092438.13987A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Sun, 6 Aug 2000, David Witbrodt wrote:

> When wrote a program to draw 1/8 of a circle using Bresenham, the VGA
> screen started to scroll away after a number of pixels had been
> drawn!  I tried to find the bug in my routine for several days, and
> was about to give up when the thought of trying simpler CONIO routines
> occurred to me.  When I replaced the IOSTREAM functions with CONIO
> equivalents, the program worked just fine!  

I'm guessing that it scrolls after the call to cin.getline() (you 
should have told precisely where the scrolling begins).  If my guess
is right, I don't see anything surprising here, nor is it specific to 
iostreams implementation used by DJGPP: when you press [Enter], the 
normal DOS console I/O routines eventually call a BIOS function to echo 
the Newline character to the screen.  In response, that BIOS function 
scrolls the screen, assuming the cursor is on the last display line.

The conio function getch() doesn't behave like that because it calls a 
special DOS function which reads the console in raw mode.

In other words, what you saw is the difference between the raw- and 
cooked-mode I/O to the console device.