Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Dec 2001 09:00:20 -0800
From:      "Brian D. Moffet" <brianm@moffetimages.com>
To:        Bakul Shah <bakul@bitblocks.com>
Cc:        freebsd-hardware@freebsd.org
Subject:   Re: i286 
Message-ID:  <5.1.0.14.2.20011211085224.00ae07b8@orac.moffetimages.com>
In-Reply-To: <200112110552.AAA08679@valiant.cnchost.com>
References:  <Your message of "Mon, 10 Dec 2001 15:02:26 MST." <15381.12530.404008.733531@caddis.yogotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 09:52 PM 12/10/2001 -0800, you wrote:
>Not that anyone cares any more but...  i286 provides good
>enough protection -- you can have each prcoess in its own
>protected address space without any external h/w support
>(like we had to do for Moto 68000 based machines).  What it
>didn't provide was support for paging.  A company called
>Microport released a "real" unix for 286 in, I think, 1985.
>Another company called Bell Technologies used to sell PC/ATs
>bundled with Microport's Unix and their own drivers for
>various I/O devices until Intel bought them out.  Microport
>is still around but don't know if they sell Unix on PC/ATs
>anymore!

SCO, at that time "Santa Cruz Operation" also provided a "real" Unix, ie 
Xenix.  Supported paging only on the level of 64K segments.  There were 
some rather interesting problems with it.  There was a constant battle 
between Microport and SCO because of some technology that they used, which 
was claimed by SCO to be proprietary.  The ability to change console 
screens (multiscreens they were called) was one of those.  That came from 
SCO.  Of course Xenix originally came from Microsoft in the early 80's, so 
it all boils down to that large company in the beginning ;-)

The 286 version worked better than the 8086 version though.  That was able 
to support memory management by taking advantage of the fact that it was a 
16 nit machine, and used the segment register to act as a very crude memory 
management.  There was no protection as you might guess.

I remember we had what was called a "JAM" area, where the relocation 
information for libraries would be held.  When a process started, the 
kernel would write the correct offsets (since the process had to know about 
the actual address) into this area, and then start the process running.

I remember working on these two while I worked at SCO, I was in the tech 
support department.  I eventually moved to kernel engineering to work on 
the 386 port of Unix.

Too much trivia for you :-)

Brian


Brian D. Moffet
brianm@moffetimages.com -- http://www.moffetimages.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.2.20011211085224.00ae07b8>