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."