Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!panda!teddy!jpn
From: jpn@teddy.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: IBM new 'standard'
Message-ID: <3903@teddy.UUCP>
Date: Tue, 31-Mar-87 16:38:47 EST
Article-I.D.: teddy.3903
Posted: Tue Mar 31 16:38:47 1987
Date-Received: Thu, 2-Apr-87 05:50:16 EST
References: <701@imsvax.UUCP> <855@bucsb.bu.edu.UUCP> <882@mtunb.UUCP> <1353@steinmetz.steinmetz.UUCP>
Reply-To: jpn@teddy.UUCP (John P. Nelson)
Organization: GenRad, Inc., Concord, Mass.
Lines: 19

>I have often wonderd why people diddle i/o ports directly. Going
>directly to the screen memory is obviously a big performance win (as is
>using int 29h to write to the screen driver), but hopefully no one is
>changing the screen mode or the serial baudrates, etc, often enough to
>need the performance of direct i/o.

If IBM had provided a "write multiple characters to screen" entry point
in the BIOS, there would be no reason for any program to access screen
hardware directly!  Because of this strange oversight, people started
coding AROUND the bios.  The same can be said of the RS232 - since the
bios support is so minimal, any sophisticated program is FORCED to go
around it.

I'm not sure why anyone would want to write their program to diddle the
screen hardware ports directly, but I have written communications
software, and it is my opinion that it is IMPOSSIBLE to write any
reasonable communications software WITHOUT doing INs and OUTs!  The ROM
bios entry points don't give you sufficient control over the rs232, and
the standard BDOS support for STDAUX is a joke.