Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/3/85; site ukma.UUCP
Path: utzoo!watmath!clyde!cbosgd!ukma!sambo
From: sambo@ukma.UUCP (Father of micro-ln)
Newsgroups: net.micro,net.arch
Subject: Re: 386 Family Products
Message-ID: <2361@ukma.UUCP>
Date: Wed, 6-Nov-85 00:03:58 EST
Article-I.D.: ukma.2361
Posted: Wed Nov  6 00:03:58 1985
Date-Received: Thu, 7-Nov-85 05:24:43 EST
References: <129@intelca.UUCP> <392@aum.UUCP> <225@l5.uucp> <533@scirtp.UUCP> <2353@ukma.UUCP> <6112@utzoo.UUCP>
Reply-To: sambo@ukma.UUCP (Father of micro-ln)
Organization: Univ. of KY Mathematical Sciences
Lines: 22
Xref: watmath net.micro:12605 net.arch:2038

In article <6112@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>consider the awesome inefficiency of emulating things like screen updates
>one instruction at a time.  (Or does the 386 have some better hooks for
>emulating memory-mapped virtual i/o devices?)  Yes, Virginia, there are
>MSDOS programs that do their own screen updates.

I am talking about something outside my expertise (all areas are outside
my expertise), but if I understand the Intel literature correctly, you
can do paging on top of emulating the 8086 in "virtual 86 mode."  Then
you can set the page(s) where the screen is to "not present," and then do
a trap every time it is accessed.  Alternatively, you could set that page
as "read-only," so that you would do a trap only on writes.  According to
Intel, this is not as fast as one might like, but when running both 8086
code and 80386 code, the 80386 is quite fast.
--
Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY  40506-0027
ARPA: ukma!sambo<@ANL-MCS>, or sambo%ukma.uucp@anl-mcs.arpa,
      or even anlams!ukma!sambo@ucbvax.arpa
UUCP: {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!sambo,
      or cbosgd!ukma!sambo

	"Micro-ln is great, if only people would start using it."