From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Unix Roots of DOS?
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Sun, 26 Jul 1992 16:59:53 GMT

In article <1992Jul24.175242.1@cc.curtin.edu.au> zcookbruc@cc.curtin.edu.au writes:
[comments about memory definitions deleted]
>
>WOW the clarification is more confusing than the original statment.
>and almost as confusing as the "standard" documentation.
>
>...BRU

Yes, sad but true.  The PC is a kludged memory space.  IBM caused part of
it with their insistance on a ROM-based BIOS at the end of the memory
space for the 8086/8088 with no regard for expansion, and the specific
reservation of 6 times that much space for whatever might follow.  IBM
is known to have a penchant for reserving everything in sight, so this
is no real surprise.  Further, they love to have yet another place to
stick a copyright notice in.  (Note that some clone ROMs have the
phrase "NOT COPYRIGHT IBM" in them to satisfy some programs searching for
the IBM copyright notice.)

There is no built-in MS-DOS reason for a ROM, and indeed there are other
DOS machines that don't have ROMs anywhere near as confining.  The DECmate
II MS-DOS actually doesn't even have a boot ROM because it shares memory
space with another CPU that does the initial loading for it.  In theory,
this means that this 8086 MS-DOS can run in 1024K (minus some inter-CPU
overhead) which even beats the Rainbow and Victor-9000 for available
DOS memory space.  (They are tied at 896K as compared to 640K for PC's; the
memory definitions are largely complicated by kludgy attempts to get
around this by exploiting odd quirks and/or possibly present exception
cases, etc. that some PC's have.)

BTW, there have been many machine designs where the ROMs are only transiently
present.  The last thing the ROM does is deselect itself, after a RAM-based
program is about to run the show which was copied from the ROM.  In some
designs, the ROM code merely has to self-reference; as a side-effect, the
ROM contents is copied into a RAM occupying the same memory space.

From the vantage point of a ROM-free environment, the software could've
driven the memory usage, not the hardware constraints.  Thus it is hoped
that less effort towards defining kludge regions would've occured, and
software effort devoted towards features, not damage control.

Furthermore, it is unacceptable to have fixed memory locations for poke-through
video buffers and the like.  It costs almost nothing to have a video base
address register to hold the high-order bits of where the video is today, 
and has been done in the past years before IBM stumbled on Intel's notion
of how to do a micro.  A *real* OS can tell you where it needs things put
if there is need to do any direct putting, or for about 2 cents more hardware
the interface could tell you itself.

Had this been the motif for 8086 development of systems, instead of IBM's
bad kludge, memory space size would have gradually increased without problem.
8088 systems would just be treated as smaller maximum size, not as the
model for one of the modes that you have to support.  How much software
overhead is traceable to the issues of old conventions and compatibility
with all of the kludges and limitations.

cjl

Newsgroups: alt.folklore.computers