Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ames!killer!chasm
From: chasm@killer.DALLAS.TX.US (Charles Marslett)
Newsgroups: comp.os.minix
Subject: Re: Equip Survey
Summary: Beauty is in the eye of the beholder
Keywords: Minix, PS-2, Hardware
Message-ID: <6979@killer.DALLAS.TX.US>
Date: 30 Jan 89 15:29:13 GMT
References: <2880@rtmvax.UUCP>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 58

In article <2880@rtmvax.UUCP>, johnc@rtmvax.UUCP (John Connin) writes:
> First, as a policy, I believe that Minix should NOT rely on BIOS services.
> Yes, I know it makes life easier, but my feeling is that doing so detracts
> from the beauty of Minix.
The beauty of MINIX is not in running directly over the hardware (that is
the beauty of SCO Xenix, Microport Unix, Interactive Unix, etc.) -- MINIX is
small enough to be understandable and still not a career, MINIX is large
enough to be useful, and MINIX runs on the computer I own.  To keep the
other two characteristics, MINIX will need to take full advantage of any
help the BIOS provides if it is to run on a reasonable number of (non-IBM)
computers and especially if it is to avoid being rewritten every time a new
computer box is released.  The BIOS was written to provide a cushion against
the future changes of the hardware, and if it is not performing that function
perfectly, think how hard it would be to do anything without it.  MINIX
probably has 10K of vendor specific code in it now (for PS/2s, ATs, XTs, etc.)
and if it had to boot without the BIOS we would have 10 to 50 incompatible
binarys instead of 3 (or 2?, STs, ATs and XTs).

> As to AST's question, though not comprehensive, perhaps the follow code
> fragments will help.  One determines the processor type by executing selected
> instructions.  The other determines the machine type by testing the
> 'model byte' located at 0xFFFF:000E.  Perhaps someone more knowledgeable
> than myself can contribute a comprehensive model byte list.

The model byte is almost useless as a processor type detector, since the
various clone BIOS writers have to stuff a value that works best with the
available (MSDOS) software -- V20/V30 based systems often call themselves
ATs (without extended memory), PS/2 boxes have a whole new set of ID bytes,
since they are all the same, but different, and most clone AT and 386 boxes
use either Compaq's code or the IBM AT codes . . .  I have found that the
model byte is most useful to tell if there are 1 or 2 interrupt controllers
(since lots of MSDOS software uses it for this purpose), but it tells you
very little else unless you are willing to limit your universe to the high
priced boxes.

> An additional piece of information (clone type) can be had by checking
> the BIOS 'id_string' at 0xF000:0xFFEA (eg. "IBM", "COMPAQ", "OLIVETTI",..).

Again, only if you are willing to ignore "cheap" clones.  For example, most
Phoenix BIOSes have no useful string there at all.

> As an addition thought, I believe it would be prudent to collect all
> low level "survey code" into one code module.  As envisioned, this code
> would be called by kernel/main and would place results in a "system data"
> structure which is accessable to all other OS modules.

I agree on this point, the code will have to be modified (even using all the
help we can get from any source whatsoever) fairly often, and it will be the
most likely candidate for any failure to boot on a new computer.  Localizing
it makes the task of maintaining it all that much easier.

> John L. Connin  (peora!rtmvax!johnc)

===========================================================================
Charles Marslett
STB Systems, Inc.  <== Apply all standard disclaimers
Wordmark Systems   <== No disclaimers required -- that's just me
chasm@killer.dallas.tx.us