Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!attctc!chasm
From: chasm@attctc.Dallas.TX.US (Charles Marslett)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Super VGA Standard
Summary: How can you write code for DOS and Unix?
Keywords: VGA
Message-ID: <9833@attctc.Dallas.TX.US>
Date: 23 Oct 89 04:34:08 GMT
References: <3458@scolex.sco.COM> <9777@attctc.Dallas.TX.US> <3464@scolex.sco.COM>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 47

In article <3464@scolex.sco.COM>, loranb@sco.COM (Loran Ball) writes:
> Besides running in protected mode, BIOS must be re-entrant for Xenix to
> use it.  Xenix doesn't use any BIOS provided on PC/AT motherboards
> or expansion boards.  We can do this because the hardware is all standardized
> at the register level.
> 
> I'm not a member of VEGA, but the only way I can envision the new BIOS
> standard supporting DOS and Xenix/Unix environments properly is to have
> two versions of it on the VGA adapter.  A non-reentrant, real mode version
> for DOS and a reentrant, protected mode version for Xenix/Unix.

There seems to be a bit of confusion here . . . DOS need not run non-reentrant
code, in fact most of the code I run under Unix also runs under DOS quite well
(most was even written originally for DOS).  The only problem we forsaw, and
the only one we tried to address is the fact that protected mode OSs have a bad
habit of disallowing (concurrent) access to the BIOS ROM area.  The routines
needed to make the I/O hardware independent are of the form:

     do a bit of register-to-register manipulation, perhaps using the stack
     OUT  DX,AL
     do a bit more
     OUT  DX,AL
     ...
     prehaps access the video memory segment (using a preloaded ES?)
     ...
     RET (far) or IRET

Such code is quite compatible with DOS and protected mode OSs.  It is a very
small subset of the IBMish ABIOS in terms of functionality and in terms of
effort required of the BIOS writer and of the OS driver writer.  So I like it.

The code can be copies into an OS code segment if desired, and the return
patched to a "near" one, or it may be executed in place (often slower, because
the ROM is on the bus, perhaps byte wide, but certainly not as convenient
or as fast as motherboard RAM).

> ===========================================================================
> Loran Ball (loranb)		uunet!sco!loranb	loranb@sco.COM
> ===========================================================================


===============================================================================
"Those who would sacrifice **  Charles Marslett
liberty for security,      **  STB Systems, Inc. <-- apply all std. disclaimers
deserve neither."          **  Wordmark Systems  <-- that's just me
  -- Benjamin Franklin     **  chasm\@attctc.dallas.tx.us
-------------------------------------------------------------------------------