Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!saturn!helios!ted
From: ted@helios.ucsc.edu (Ted Cantrall)
Newsgroups: comp.sys.ibm.pc
Subject: Re: 640K limit
Message-ID: <10344@saturn.ucsc.edu>
Date: 17 Jan 90 17:57:18 GMT
References: <4668.25aed7f2@uwovax.uwo.ca> <1468@blackbird.afit.af.mil> <28808@amdcad.AMD.COM> <729@jethro.Corp.Sun.COM> <4308@brazos.Rice.edu> <1990Jan17.031934.3374@esegue.segue.boston.ma.us>
Sender: usenet@saturn.ucsc.edu
Reply-To: ted@helios.ucsc.edu (Ted Cantrall)
Organization: UCO/Lick Observatory, Santa Cruz
Lines: 16

In article <1990Jan17.031934.3374@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
>In article <4308@brazos.Rice.edu> solomon@screech.rice.edu (Richard L. Solomon) writes:
>>>Simple.  IBM/MicroSoft *should* have used soft pointers to the I/O memory
>>>areas.
>>	NO....they SHOULD have mapped the I/O in the I/O ADDRESS SPACE where
--
How would things have worked out if IBM had put this 384k block at the bottom
of the memory (0-384). That would have left no constrictions on upward
expansion except the 8088. And that problem would have been remedied by
the 80286.		-ted-


-------------------------------------------------------------------------------
ted@helios.ucsc.edu         | "The opinions are mine...
(408)459-2110               |    ...the facts are public domain."
-------------------------------------------------------------------------------