Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!vrdxhq!bms-at!stuart
From: stuart@bms-at.UUCP (Stuart D. Gathman)
Newsgroups: comp.os.minix
Subject: Re: Minix runs on Faraday motherboard
Message-ID: <378@bms-at.UUCP>
Date: Sun, 19-Apr-87 17:45:21 EST
Article-I.D.: bms-at.378
Posted: Sun Apr 19 17:45:21 1987
Date-Received: Sun, 19-Apr-87 22:45:34 EST
References: <406@netxcom.UUCP> <9490003@hpfclp.HP.COM>
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 28
Summary: The problem with 1100+ and other clones screens


Well, I have gotten to the bottom of the problem with the screen on my 
T1100+ and Minix.  The IBM CGA has 16K of video memory that 'wraps' in
text mode.  To scroll the screen, Minix simply changes the video origin
within this 16K.  The toshiba (and other clones, evidently) do not wrap
when the video origin is near the end of the 16K.  Instead, they display
whatever their internal memory subsystem happens to return for those
addresses (usually blank and almost always repeating).  Minix, meanwhile
has been faithfully storing the data at the beginning of the 16K so that
when the video origin finally gets to 0 again, the data all reappears!

I cannot think of any solution other than to scroll the screen with
a big REP MOVSW.  Another poster has already offered this solution.
It seems a shame.  Perhaps this need only be done when the end of
video memory is reached (i.e. once every four screens for 1100+).

Interesting note - the NORTON utilities show 32K video memory for a
true blue CGA.  The second 16K is just a mirror image of the first.
SYSINFO reports only 16K for the 1100+.

Conclusion - this is a compatibility problem with the clones.

Unrelated minor complaint.  I can't stand all the val&BYTE masking
in the MINIX code for parameters passed to port_out (which is defined
to take a char anyway)!  An optimizing compiler would probably recognize
the redundancy and remove it, but I don't have one.
-- 
Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>