Early-to-middle IBM-PC history (was: End-user uses for x86-64)

[Tom Buskey]

On 2/18/07, Ben Scott <dragonhawk at gmail.com> wrote:
>
> On 2/18/07, Tom Buskey <tom at buskey.name> wrote:
>
>


  MS-DOS was, is, and always will be limited to the 1 MB address space
> of the original 8086-based IBM-PC design, in 64 KB segments at a time.
> That's further eaten into by space reserved for hardware ROM and I/O.
> On most systems, there was (up to) 640 KB for software ("conventional
> memory") and 384 KB for hardware ("high memory").  (If you had a
> Hercules monochrome graphics adapter, you could bump conventional
> memory to 700-something KB, as the Herc mapped it's hardware into
> different regions.)


I had a Zenith Z-100 before I had a PC.  It had an 8088 and an 8085, ran DOS
and had 768k ram.  It was not PC compatible though someone wrote software
that did (ZPC).


> EMS was originally a hardware spec to address more memory.
>
>   That's incorrect.  EMS (Expanded Memory Specification) was another
> memory windowing scheme.  You put RAM on an expansion card.  The CPU
> could not address it in any way.  You could, however, invoke hardware
> I/O routines that would swap a block of memory from conventional to
> EMS banks (or vice versa).  You still could only address 64 KB at a
> time, though, and no more than 1 MB total.


I remember it always being a memory card w/ a driver before QEMM 386 and the
like.  Well, it was some time ago ;-)
It was also called LIM (Lotus Intel Microsoft).



> > XMS was a software hack that didn't work on the 8088.
>
>   XMS (Extended Memory Specification) was the standard that evolved
> for accessing (from DOS) CPU-addressable memory above 1 MB.  DOS and
> DOS programs still ran in real mode, but a memory manager (an add-on
> product in the DOS world) could switch blocks of memory in and out of
> the DOS real mode memory space (similar to how EMS worked).
>
>   The 8086/8 could not address more than 1 MB.  The 80286 could -- up
> to 16 MB, as you note.  That's a huge jump, so of course DOS
> programmers wanted to access it, but were stuck in a 16-bit segment.
> Hence the need for XMS.
>
> > The 386 could do EMS (& XMS) in software ...
>
>   Not really correct.  EMS and XMS are both software interfaces.  EMS
> existed to allow the many different hardware-incompatible memory
> expansion hards to provide a consistent interface to DOS software.


As I remember it, EMS for the 8088 and 286 was a special card.
Standard RAM on the '286 could be used for XMS (I had a 1MB card that
brought my '286 up to 1.5MB)
The 386 could do EMS w/o special cards.


Yes, that's right, under DOS, even your RAM needed a device driver.
> XMS existed because even though the hardware could touch more memory,
> DOS software still couldn't.
>
>   CPU-addressable memory above 1 MB was possible with the 80286.  It
> wasn't used by most programs, because the 286 couldn't switch back to
> real mode once switched into protected mode, and a lot of DOS software


The A20 hack let the '286 swap back & forth.  That's what made XMS possible.


> isn't compatible with protected mode.  It was done by some software
> through -- typically business applications that wanted to work with
> more than 64 KB at a time.


You mean 640k of course.  64k was small memory mode but there was a large
mode that had up to 640k.  (Trying to remember my old Turbo C)


  Software emulators were available that turned used XMS to provide
> EMS (for software that was only EMS aware), but that's nothing to do
> with the i386.
>
>   The i386's major changes were that it enabled a 32-bit address
> space, it could switch back to real mode (out of protected mode), and
> it offered virtual 8086 mode.  Suddenly, you could reliably multitask
> DOS programs.  Multitasking was available before, but without memory
> protection.  Now, when one of the DOS programs went bonkers and
> trashed memory, instead of a reboot, you could just kill the "DOS
> box".
>
>   Sure the i386 was faster.  Faster is always appreciated.  But no
> matter how fast you ran a 286, you couldn't reliably multitask DOS
> programs.  That was the "killer app" for Win 3.0 for many
>
> people-doing-ordinary-tasks-like-reading-email-browsing-the-web-writing-letters-looking-at-pictures-and-calculating-their-taxes.
> Sure, it sucked like a black hole, but DOS still sucked more.  After
> swimming in sewage, even NJ looks like paradise.  ;-)
>
>   The additional address space also enables practical use of larger
> memories.  I know you're married to the idea that any Turing-complete
> design can do anything any *other* Turing-complete design can, but


Not me...

here in the real world, we actually want to get work done, and we
> don't have time to wait for the infinitely long paper tape to move
> back and forth.
>
> > I don't think Windows 95 would run on a '286 ...
>
>   Correct.
>
> > ... but I also think the DOS market was pretty much done at that point.
>
>   HAH!  One of the major complaints about '95 was that some DOS
> software wouldn't run anymore.  There was a whole "MS-DOS
> Compatibility Mode" which was essentially an automatic dual-boot: It
> would shut down the whole OS to run one DOS program.  Hell, people
> still run DOS crap *today*.  It's like System/360; it saw enough use
> that it's never going away.  People will be running DOS programs in
> DOS emulators (prolly running *those* emulators under some *other*
> emulator) long after we're all dead and buried.
>
>   This is, incidentally, one of the "limitations" of x86-64.  In long
> mode (64-bit mode), you cannot run 16-bit real mode code.  At all.
> There's no virtual mode, either.  So 64-bit Windows cannot run DOS or
> Win16 code (of which there is still a depressingly large amount).
> That's one reason most Windows systems are still 32-bit OS installs.
> Of course, it means all the cool x86-64 stuff just ends up being used
> primarily as a really, *really* fast i386.


Hmm, does DOSemu  have issues on 64bit linux?

> Remember having to quit a program completely before running another one?
>
>   Heh.  Yah.  I ended up using multi-program environments early on.
> PC/GEOS offered preemptive multitasking (without memory protection) on
> an 8086.  Then I started using DESQview... :)


DESQview was barely usable on an 8088. Tolerable on a '286.  Awesome on a
'386.  Along with QEMM.
DESQview/X was interesting.  I think there are free copies out there.  It
turned DOS into a multitasking X11 server system.   Run a DOS program on the
PC and display it back to your Unix box.  It could do most DOS programs but
not Windows.


> > As time went on, the market chased speed.
>
>   Apparently, you never had to fight to get 3 KB more out of
> conventional memory, to load just one more TSR or that much of a
> bigger program.  The ability to address more than 64 KB at a time was
> wanted by everyone else on the planet except you.


I think you're confusing me with someone else on this issue.  I implied at
the beginning that memory was an issue that EMS tried to solve.
In any event, I agree with you about RAM.
Anyone doing games then had tricks to save RAM.  DOS 5.0 had LOADHIGH to
move parts out of the 640k area.  You could set COMPSPEC= at the start of
autoexec.bat and COMSPEC=command.com at the end to eek out a few more bytes
for your environment.

TSRs were an interesting solution in the DOS era.  MacOS had DAs in the pre
multifinder days too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20070219/fdd9d455/attachment.html