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

[Ben Scott]

  First things first: My apologies to Tom Buskey, who I did confuse
with the other Tom (Charron) in this Gordian-knot-of-a-thread.  Sorry
to jump down your throat like that, Mr. Buskey!

On 2/19/07, Tom Buskey <tom at buskey.name> wrote:
> 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).

  Wow.  I never owned anything that weird.  :-)

  Then again, the Tandy 1000 was pretty weird for a "PC compatible".
It had DOS in a boot ROM, proprietary connectors for everything, and
funky Tandy sound and graphics hardware.  But at the heart, it was
still a plain old 8088 running plain old DOS.

>> EMS (Expanded Memory Specification) was another
> > memory windowing scheme.
>
> I remember it always being a memory card w/ a driver before QEMM 386 and the
> like.

  Extended memory (CPU-addressable memory above 1 MB) didn't see a lot
of use before the 386, mainly because of the aforementioned inability
of the 286 to switch out of protected mode once it got in.  So the
category of DOS software known as "memory managers" didn't really come
into existence until the 386.  But to the best of my knowledge,
there's nothing the 386 added that made the extended-memory-as-EMS
trick intrinsically possible.  Essentially, that treats extended
memory as just another expanded memory card.  This "card" happens to
actually be CPU-addressable, unlike all the cards that plugged into
the expansion bus and used I/O for memory access.  But DOS, still
stuck in 1 MB 8086 land, didn't know or care about that.

> It was also called LIM (Lotus Intel Microsoft).

  Right, those three got together and created the "LIM EMS" standard.
Before that happened, any program wanting to use an expanded memory
card had to have support for that specific make and model of card.
EMS was the standard API that let card makers implement an EMS driver,
and application programmers just target EMS.

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

  That's incorrect.  The A20 hack prevented DOS software from getting
all screwed up by the fact that the 286 could address more than 1 MB
of RAM.  A20 was the 21st address line, new on the 286.  A20 was
disabled by default; software had to turn it on explicitly.  That was
done independently of the CPU mode switch.  Wikipedia has a pretty
good explanation:

	http://en.wikipedia.org/wiki/A20_line

  Come to think of it, I'm not actually sure that the 286 needed to be
in protected mode to address more than 1 MB of RAM.  In real mode,
software would still be limited to 64 KB at a time and 1 MB total, but
maybe the hardware could still see it all (similar to PAE on modern
x86-32 systems).

>> 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)

  I did, in fact, mean 64 KB at a time.  Despite the fact that the
8086 had a 20-bit address bus, it was fundamentally a 16-bit chip.
Software could only work with 16 bits at a time.  That 16-bit memory
space -- 64 KB -- was called a "segment".  You could adjust the
segment offset, and thus change your window into the 1 MB address
space.  But you were still limited to 64 KB at a time.

  Compilers could do "behind the scenes" work to make it look like you
had a flat 640 KB memory space.  I don't really know how they did
that.  I suppose they turned pointers into a data structure that
contained both segment offset and in-segment address, and turned
pointer arithmetic into a multi-instruction operation.  Slow and ugly.

> Hmm, does DOSemu  have issues on 64bit linux?

  Hmmmm.  I would expect so.  According to TFM, it's just a software
emulator; it doesn't do hardware emulation.  So if your machine cannot
run DOS code, DOSemu won't help.  Since an x86-64 machine in long mode
cannot run 8086 code, I would expect DOSemu would behave the same as
it would on a SPARC or an Alpha -- i.e., useless.

  Bochs, which emulates a x86 entirely in software, should still work, though.

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

  Yah, I only used PC/GEOS (and Telemate) on my 8088-based Tandy.
Once I upgraded to a 386 (with 4 MB of RAM), I started using DESQview.

> DESQview/X .. Run a DOS program on the PC and display it back to your Unix box.

  I didn't meet Unix (and Linux) until I went to UNH.  By then I had a
486/80 with an 64 MB of RAM -- pretty high-powered for PC at the time.
 My first thoughts about Linux that I was already running OS/2, which
could multitask and run DOS and Windows programs better then their
native OSes, so why should I switch to this strange thing that
couldn't even run DOS programs?  I was a slow convert.  :)

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

  I used 4DOS, which could do all sorts of contortions to free up
memory.  Aside from loading in high memory, it could swap most itself
out to a disk file.

> TSRs were an interesting solution in the DOS era.  MacOS had DAs in the pre
> multifinder days too.

  I never used Mac's before System 7, and then only briefly.  So I
missed out on all that lore.  :)

 I bought a Mac 512K I bought for $5 at Hosstraders a year or two ago.
 I looked around for a classic Mac System floppy image to boot it, but
it turns out the PC's floppy drive (or controller) cannot write a
floppy in the original Mac format.  So I took it apart instead.  :)  I
want to stuff modern PC innards into the compact Mac chassis some day,
just for the hell of it.

-- Ben