commit d9148dc1aebc34a2dfd984a7ee9ca2c3d7587be7
parent cf0d3336f229e12f3f664906ec9b8f9e3c15adb3
Author: Chris Bracken <chris@bracken.jp>
Date: Sat, 10 Dec 2022 17:06:21 -0800
PC Evolution: correct spelling and formatting
Diffstat:
| M | pc_evolution.md | | | 1617 | ++++++++++++++++++++++++++++++++++++++++--------------------------------------- |
1 file changed, 815 insertions(+), 802 deletions(-)
diff --git a/pc_evolution.md b/pc_evolution.md
@@ -4,6 +4,7 @@ History of the evolution of the x86 platform, from the IBM PC to the modern era
Version 01/01/2021
by Zir Blazer
+
## Table of Contents
* [0 - PROLOGUE](#chapter-0)
@@ -25,7 +26,7 @@ by Zir Blazer
* [3.1 - IBM PC/XT Motherboard changes](#chapter-3.1)
* [3.2 - IBM PC/XT HDC card and HD, PC DOS 2.0, MBR and partitioning](#chapter-3.2)
* [3.3 - The first IBM PC/XT clones and the NEC V20 CPU](#chapter-3.3)
-* [3.4 - The first Turbo XTs, Hardware requeriments and changes to Clock Generation](#chapter-3.4)
+* [3.4 - The first Turbo XTs, Hardware requirements and changes to Clock Generation](#chapter-3.4)
* [3.5 - Turbo XTs compatibility issues with IBM PC Software, Turbo function, honorable PC platform related mentions](#chapter-3.5)
* [4 - The IBM PC/AT 5170, the last common ancestor](#chapter-4)
* [4.1 - Intel 80286 CPU Overview, the MMU, Segmented Virtual Memory and Protected Mode, support chips](#chapter-4.1)
@@ -53,18 +54,18 @@ by Zir Blazer
0 - PROLOGUE
------------
-Back during 2013, I became interesed in both Hardware and Hypervisor support to
+Back during 2013, I became interested in both Hardware and Hypervisor support to
do PCI/VGA Passthrough, as I saw a lot of potential in the idea of
-passthroughing a real Video Card to a Virtual Machine with a Windows guest
-just for gaming purposes (Note that this was a few years before this type of
-setups became popular, so I consider myself a pioneer in this area). At that
-point in time, the only Hypervisor that supported doing so was Xen, which
-required a Linux host. Since I had no previous Linux experience, I had to
-learn everything from scratch, thus I began to take a large amount of notes so
-that I could perfectly reproduce step by step everything that I did to get my
-setup in working order. Eventually, those notes evolved into a full fledged
-guide so that other people could use my knowledge to install an Arch Linux
-host together with the Xen Hypervisor.
+passthroughing a real Video Card to a Virtual Machine with a Windows guest just
+for gaming purposes (Note that this was a few years before this type of setups
+became popular, so I consider myself a pioneer in this area). At that point in
+time, the only Hypervisor that supported doing so was Xen, which required a
+Linux host. Since I had no previous Linux experience, I had to learn everything
+from scratch, thus I began to take a large amount of notes so that I could
+perfectly reproduce step by step everything that I did to get my setup in
+working order. Eventually, those notes evolved into a full fledged guide so that
+other people could use my knowledge to install an Arch Linux host together with
+the Xen Hypervisor.
By 2016, I replaced Xen with the standalone version of QEMU, since it gained
important features at a much faster pace than Xen (Mainly the fact that QEMU
@@ -87,20 +88,20 @@ Soon after, my obsolete virtualization guide was morphing to provide heavy
coverage of the idiosyncrasies of recent x86 platforms. This grew out of
proportions when I decided that the easiest way to explain why modern stuff
works in a certain way is simply by starting at the very beginning, then
-introduce topics one at a time. At that point, I decided to spinoff all that
+introduce topics one at a time. At that point, I decided to spin off all that
into its own Wall of Text, as instead of virtualization, it had became a major
course of computer history that goes all the way back to the 1981 IBM PC.
If you want a recap about why I began to write all this for a virtualization
guide, consider that a Virtual Machine is an extremely complex beast that
-attempts to implement, mostly in Software, the functionality and behavior of an
+attempts to implement, mostly in software, the functionality and behavior of an
entire computer. The mix and match of emulation, virtualization and passthrough
only tells you the method that was used to reproduce the functionality of a
specific component of the VM, but not why it has to be reproduced at all. If you
want to understand the complexity of all what a VMM like QEMU has to do in order
to be able to create an usable VM, then you have to understand the underlying
-Hardware whose functionality it is attemping to reproduce. This includes the
-Processor, the Chipset, the Firmware, Buses like PCI Express and anything that
+Hardware whose functionality it is attempting to reproduce. This includes the
+Processor, the Chipset, the firmware, Buses like PCI Express and anything that
you can plug in them, and the means by which everything is interconnected or
related. As you should expect, explaining all that requires major amounts of
text.
@@ -117,9 +118,9 @@ second generation AMD ThreadRipper, for reasons you will learn when I get
there), it becomes critical to have at the very least a basic understanding of
why the platform topology is directly related to the way that the system
resources must be allocated, else, you will be left pondering why you are
-getting subpar performance.
+getting sub-par performance.
-Eventually, you will notice that all this knowledge becomes inmensely valuable
+Eventually, you will notice that all this knowledge becomes immensely valuable
to optimize any type of setup, as you will have a decent idea about what SMP and
SMT are, their relationship with the configurable Sockets-Cores-Threads Topology
of the VM Processor and why it is recommended to directly map each vCPU Thread
@@ -128,6 +129,7 @@ Dual Processors, and how to create a correct virtual PCI Bus Topology that
solves some obscure issues with passthroughed Video Cards, something that most
users seems to ignore because Windows for the most part doesn't care.
+
1 - INTRODUCTION
----------------
@@ -135,11 +137,11 @@ Our computing ecosystem as you know it today, is something that has been built
directly on top of a pile of design decisions made in the early 80's. How we got
here? Backwards compatibility. It was a great idea that a newer computer was an
improved, faster version of your previous one, so that it could run all the
-Software that you already owned better than it. However, maintaining that sacred
+software that you already owned better than it. However, maintaining that sacred
backwards compatibility eventually became a burden. It is the reason why a lot
of design mistakes made early on were dragged for ages, even influencing later
Chipset and Processor designs just to remain compatible with features only
-reelevant in the earliest generations.
+relevant in the earliest generations.
If you are using a computer that has an Intel or AMD Processor, your platform
has an IBM PC compatible heritage. The IBM PC compatibility is not a minor
@@ -156,7 +158,7 @@ While the whole history is rather long, a lot of things will be easier to digest
and make much more sense if you start from the very beginning. After all, I'm
sure that neither the original IBM PC designers, nor those that built upon it,
could have imagined that almost four decades later, many implementation details
-would still be reelevant. It also explains why from our current point of view,
+would still be relevant. It also explains why from our current point of view,
some things that looks like ugly hacks have some kind of ingenuity applied to
them.
@@ -177,26 +179,26 @@ important computer platform of the 80's. The platform itself keep continuously
evolving through the years, and by the late 90's, the descendants of the IBM PC
had killed almost all the other competing platforms.
-IBM was used to make fully propietary systems that provided a complete Hardware
-and Software solution, yet it was aware that the personal computer market had a
-totally different set of requeriments. Thus, for the IBM PC, IBM took many
-unusual design decisitions. In order to reduce the time that it would take to
+IBM was used to make fully proprietary systems that provided a complete Hardware
+and software solution, yet it was aware that the personal computer market had a
+totally different set of requirements. Thus, for the IBM PC, IBM took many
+unusual design decisions. In order to reduce the time that it would take to
design the new computer, IBM used mostly standard chips and other components
that were already available in the open market (Usually known as off-the-shelf),
and so that anyone else could buy. IBM also delegated the responsibility of
creating the main Operating System for the new computer to a third party,
-Microsoft, which keeped the right to license it to other third parties. Finally,
+Microsoft, which kept the right to license it to other third parties. Finally,
IBM deemed necessary for the success of the IBM PC that there had to be a
healthy amount of third party support in the form of expansion cards and user
-Software, so IBM opted to make the IBM PC architecture an open platform to make
-developing Hardware and Software for it as easy as possible. All these decisions
+software, so IBM opted to make the IBM PC architecture an open platform to make
+developing Hardware and software for it as easy as possible. All these decisions
made the IBM PC rather easy to clone...
The impact of making the IBM PC an open platform is something that can't be
understated. If you want to see how serious IBM was about that, you can peek by
yourself at the [IBM PC 5150 Technical Reference Manual (August 1981)][5150ref].
Besides detailed computer specifications, that document included the schematics
-of all the parts of the computer, and even included the Firmware source code in
+of all the parts of the computer, and even included the firmware source code in
printed form. I doubt that currently there are more than two or three commercial
computers (Or even single components, like a Motherboard) that could come close
to that level of openness. If anything, I'm actually absolutely impressed by how
@@ -211,21 +213,21 @@ was one of the first mass market 16 Bits desktop computers, as it had an Intel
8088 CPU running @ 4.77 MHz when the contemporary home computers used 8 Bits
Processors like the MOS Technology 6502 running @ no more than 2 MHz, making the
difference, at least on paper, appear to be rather brutal. It had a Socket ready
-for an optional Intel 8087 FPU, a massive upgrade for the rare Software that
+for an optional Intel 8087 FPU, a massive upgrade for the rare software that
could make use of floating point math. It supported up to 256 KiB system RAM
(Albeit with later expansion cards it was possible to install more than that,
this apparently was the official limit at launch), when others maxed out just at
64 KiB. It also included a long forgotten, built-in Microsoft BASIC interpreter
in ROM known as IBM Cassette BASIC, which seems to have been a rather common
feature at that point of time in other computers, with the idea being that even
-with no additional Software, they could be usable. For more addons it had 5
+with no additional software, they could be usable. For more add-ons it had 5
expansion slots, of which you required to use at least one for a mandatory Video
Card.
The video and sound capabilities of the IBM PC seems to have been rather
mediocre, which makes sense since it was aimed at business users. You could use
it with either the text specialized MDA Video Card, which was what most business
-users prefered, or the 16 colors CGA Video Card, that got somewhat more popular
+users preferred, or the 16 colors CGA Video Card, that got somewhat more popular
for home users as gaming began to grow, but was inferior for pure console text.
Sound was provided by a beeper, the PC Speaker, mounted inside the Computer
Case. For removable storage the IBM PC was a hybrid of sorts, as IBM intended to
@@ -236,7 +238,7 @@ decided to have support to interface with them built-in in the IBM PC
Motherboard, though it relied on an external Cassette Deck. Diskettes required
an extra expansion card with a FDC (Floppy Disk Controller), yet the Case had
front bays for either one or two 5.25'' Diskette Drives, so they were
-essencially internal and integrated to the computer unit.
+essentially internal and integrated to the computer unit.
During the commercial life of the IBM PC, there were two markedly different
models: One colloquially known as PC-1, which was the original model released in
@@ -268,7 +270,7 @@ was based on the same ISA (Instruction Set Architecture) than the more expensive
and better performing Intel 8086 CPU (Which is from where the x86 moniker is
derived from). What makes the Processor ISA important is Binary Compatibility,
as when a compiler creates an executable file by translating source code into
-machine code (Opcodes), it does so by targeting a specific ISA. If you were to
+machine code (opcodes), it does so by targeting a specific ISA. If you were to
change the Processor to one based on a different ISA, it would mean that, at
minimum, you would have to recompile (If not port) all the executable files
because the Binary Compatibility would not be preserved. This early Processor
@@ -283,7 +285,7 @@ multiple Threads concurrently, any form of primitive Multitasking was achieved
by an OS that did quick context switches at small time intervals, giving the
illusion that multiple applications could run simultaneously (This would hold
true for 20 years, until the apparition of SMT in the Pentium 4 around 2001, and
-Multicore around 2005 with the Athlon 64 X2). The 8088 had an external 8 Bits
+Multi-core around 2005 with the Athlon 64 X2). The 8088 had an external 8 Bits
Data Bus, while the 8086 had a 16 Bits one, which means that the later could
move twice the data though the external Data Bus at once. Both the 8088 and 8086
had a 20 Bits Address Bus, allowing them to have a Physical Memory Address Space
@@ -334,9 +336,9 @@ means that each individual address location is one Byte in size. As such, each
Byte of memory gets its own address, and this also conveniently means that the
amount of addressable slots matches the maximum amount of addressable Bytes. An
example of an Address Space format that is not Byte-level addressable is the LBA
-(Logical Block Addressing) used for modern storage drives like HDs (Hard
-Diskses) and SSDs (Solid State Diskses), where an individual address points to
-an entire block of either 512 Bytes or 4 KiB of memory.
+(Logical Block Addressing) used for modern storage drives like HDs (Hard Disks)
+and SSDs (Solid State Disks), where an individual address points to an entire
+block of either 512 Bytes or 4 KiB of memory.
Regardless of the amount or sizes of the Physical Address Spaces that a
Processor may have, there has to be something that is listening to the CPU
@@ -375,7 +377,7 @@ collectively known as Glue Logic. The glue logic acted as an intermediary that
took care of hooking the narrower chips external Address Buses to the wider CPU
Address Bus, assisting them to externally decode the missing upper Bits and
activate the Chip Select line when appropriate. Thus, from the CPU point of
-view, the narrower chips were correctly mapped with no overlapping occuring, as
+view, the narrower chips were correctly mapped with no overlapping occurring, as
if they effectively understood the full address. You can get an excellent
explanation about how the additional supporting decoding logic that helps to
listen to the CPU Address Bus works [here][quora_mmap].
@@ -406,7 +408,7 @@ the intended mapped one. This was bad for forward compatibility since sometimes
programmers could decide to use an alias instead of the real address, so if in a
later platform revision the address decoding logic was improved, the individual
address that used to be an alias would now point to a completely different
-location, causing the Software piece that used that trick to not work as
+location, causing the software piece that used that trick to not work as
intended in the new platform.
In addition to that, the Segmented Memory Model used by x86 Processors already
@@ -417,8 +419,8 @@ often to use x86 Assembler to get the most performance out of the CPU, it was a
necessity to have a very clear idea about both the x86 Segmented Memory Model
and the specific platform address decoding scheme idiosyncrasies to know what
physical address a code could be really pointing to, more so if a developer was
-intentionally trying to ofuscate its code as much as possible for things like
-making Software copy protection harder to crack.
+intentionally trying to obfuscate its code as much as possible for things like
+making software copy protection harder to crack.
There is some degree of flexibility regarding what can be mapped into the
Address Space, which in every case is some form of memory. As explained before,
@@ -444,7 +446,7 @@ remote memory, while PMIO required to use the already mentioned special
instructions IN and OUT. The drawback of MMIO is that since it takes addresses
from the Memory Address Space, you have to sacrifice how much RAM or ROM you can
address, which may not be important at first, but becomes a problem as the
-Address Space gets crowded. Nowadays MMIO is universally prefered, using a
+Address Space gets crowded. Nowadays MMIO is universally preferred, using a
single unified Address Space (At least from the point of view of the Processor).
Curiously, I never understood why Intel decided that x86 had to have two Address
@@ -457,24 +459,24 @@ Segmented Memory Model anyways. I think that it is related to the fact than the
x86 ISA is a descendant of the Intel 8085 CPU, which also had two Address
Spaces. While the 8086 is not Binary Compatible with the 8085, Intel intended
for it to be Source Compatible, as the idea was that the primitive automatic
-translations tools available at the era could easily port the Software between
+translations tools available at the era could easily port the software between
both ISAs. A single address space would have required to do complete Ports of
-8085 Software. Had Intel started the x86 ISA from scratch with no backwards
+8085 software. Had Intel started the x86 ISA from scratch with no backwards
compatibility of any sort, chances are that it would be different in this
regard.
There are two more details worth mentioning now related to the Address Space.
The first is that when the Processor is turned on, the very first thing that it
-does is to attempt to read code beginning from a hardcoded Physical Memory
+does is to attempt to read code beginning from a hard-coded Physical Memory
Address (In the 8086/8088, the location was near the end of the addressable 1024
KiB), so it is mandatory that there is some memory mapped into that location
containing executable code that can initialize the rest of the platform up to an
usable state, a procedure known as Bootstrapping. For obvious reasons, such
memory can't be volatile like RAM, so you're pretty much limited to contain the
bootstrapping executable code in a ROM type memory chip. The contents of that
-critical ROM chip are known as the Firmware. The second thing is that not all
+critical ROM chip are known as the firmware. The second thing is that not all
the memory in a system has to be directly addressable by the CPU, sometimes
-there is memory that is addressable by another Device or Coprocessor but that
+there is memory that is addressable by another Device or Co-processor but that
isn't directly visible from the main CPU point of view at all.
When it comes to interfacing with other chips, there is yet another important
@@ -505,7 +507,7 @@ that explicitly supported their particular Bus Cycle protocol and multiplexing
scheme, as for anything else, you needed at least intermediate chips to
demultiplex the Address and Data signals back into separate lines. Also, as the
Processor uses some of its transistor budget to have an extra Muxer unit plus
-the Bus Cycle has to be longer than it could actually be just to accomodate two
+the Bus Cycle has to be longer than it could actually be just to accommodate two
different signals on the same lines, multiplexing the external Bus incurs in a
measurable performance penalty compared to a similar design than didn't had
limitations due to the amount of available Pins.
@@ -538,16 +540,16 @@ some caveats, as those were intended for the older Intel 8080 and 8085 CPUs
which had only an 8 Bits Data Bus and a 16 Bits Address Bus.
A chip set not only included support chips for the main Processor, there were
-also major chips considered as a Coprocessor class, like the Intel 8087 FPU and
+also major chips considered as a Co-processor class, like the Intel 8087 FPU and
the Intel 8089 IOP. The 8088 and 8086 CPUs supported Multiprocessing (It had a
different meaning back then than what you would think about now), allowing them
to coordinate with these chips. However, Multiprocessing required a complexer
-signaling scheme than what the previously mentioned Minimum Mode could do. More
+signalling scheme than what the previously mentioned Minimum Mode could do. More
signals would require more Pins, but, as you already know, that was impossible
to do due to the 8086/8088 packaging constrains. The solution was to heavily
multiplex the Control Bus signals into only 3 Pins now known as S0, S1 and S2,
then add a specialized discrete demultiplexer, the Intel 8288 Bus Controller,
-that could interpret thet set of 3 lines as 8 different commands (2^3 makes for
+that could interpret that set of 3 lines as 8 different commands (2^3 makes for
a total of 8 different binary combinations). This Multiprocessing mode was known
as Maximum Mode, and is how IBM had set the 8088 CPU in the PC.
@@ -561,7 +563,7 @@ demultiplexers or additional circuitry other than the 8288 Bus Controller.
Moreover, the 8087 FPU was capable of autodetecting whenever the CPU was a 8088
or 8086 to automatically adjust the Data Bus width. Other chips usually required
some external glue logic, so using chips belonging to the same family was far
-more convenient than attemping to mix and match functionally equivalent chips
+more convenient than attempting to mix and match functionally equivalent chips
from other families.
The chips from the older MCS-85 family partially supported being interfaced with
@@ -585,7 +587,7 @@ The major chips from the Intel MCS-86 family, besides the 8088 and 8086 CPUs
(Central Processor Unit), were the 8087 FPU (Floating Point Unit. Also known as
NPU (Numeric Processor Unit), but FPU should be the modern term), which focused
on floating point math (It was possible to emulate floating point operations
-using standard CPU integers via Software, but the FPU was ridiculous faster),
+using standard CPU integers via software, but the FPU was ridiculous faster),
and the 8089 IOP (I/O Processor), which could be considered a glorified DMAC
with some processing capabilities added in. Both of those chips had their own
ISAs, so besides the Instruction Set of the x86 CPUs, you had the x87 FPUs and
@@ -599,8 +601,8 @@ which could generate clock signals as electrically required by all the mentioned
Intel chips.
The Intel MCS-85 family was based around the Intel 8080 or 8085 CPUs as the main
-Processor, which is not interesing for the purposes of this story. The support
-chips, however, are extremely important. The four reelevant ones are the 8259A
+Processor, which is not interesting for the purposes of this story. The support
+chips, however, are extremely important. The four relevant ones are the 8259A
PIC (Programmable Interrupt Controller), the previously mentioned 8237A DMAC
(Direct Memory Access Controller), the 8253 PIT (Programmable Interval Timer),
and the 8255 PPI (Programmable Peripheral Interface), all of which would be used
@@ -624,6 +626,7 @@ completely forgotten.
##### 2.3 - Intel 8259A PIC IRQs, Intel 8237A DMAC DMA Channels, Intel 8253 PIT Counters, and Intel 8255 PPI Ports
+
The support chips are part of the core of the IBM PC. Thanks to backwards
compatibility, with the exception of the 8255 PPI, their functionality should be
at least partially present even in modern computers. All them were mapped to the
@@ -633,7 +636,7 @@ with them.
**Intel 8259A PIC (Programmable Interrupt Controller):** The x86 Processor
architecture is Interrupt-driven (Also known as Event-driven). In an
Interrupt-driven architecture, there is a framework for external Devices to send
-to the Processor a request for inmediate attention, which is done by signaling
+to the Processor a request for immediate attention, which is done by signalling
an Interrupt Request. When the Processor receives an interrupt request, it stops
whatever it was doing, saves its state as if the current task was put on hold,
and switches control to an ISR (Interrupt Service Routine, also known as
@@ -654,17 +657,17 @@ since they wasted too much time needlessly polling the Devices status. However,
there is nothing limiting an Interrupt-driven architecture to ignore interrupts
and instead do polling only. Actually, someone tested that in x86 and found that
[it may be better in some scenarios][polling] (TODO: Broken link, found no
-replacement). I suppose that polling could be prefered for Real Time OSes as it
+replacement). I suppose that polling could be preferred for Real Time OSes as it
should provide a very constant or predictable latency, assuming you don't mind
the extra power consumption due to the Processor being always awake and working.
The 8088 CPU supported three different types of Interrupts: Exceptions, Hardware
-Interrupts, and Software Interrupts. All them relied on the same IVT (Interrupt
-Vector Table) that holded 256 entries, with each entry containing a pointer to
-the actual ISR. The Interrupts reelevant here are the external Hardware
-Interrupts, which were of two types: The standard Maskable Interrupts, and NMIs
+Interrupts, and software Interrupts. All them relied on the same IVT (Interrupt
+Vector Table) that held 256 entries, with each entry containing a pointer to the
+actual ISR. The Interrupts relevant here are the external Hardware Interrupts,
+which were of two types: The standard Maskable Interrupts, and NMIs
(Non-Maskable Interrupts). The difference between them is that Maskable
-Interrupts can be fully ignored if the Software being run configures the
+Interrupts can be fully ignored if the software being run configures the
Processor to do so, while NMIs can't be ignored at all and will always be
serviced. To manage the standard interrupts, the 8088 had a pair of dedicated
Pins, INTR (Interrupt Request) and INTA (Interrupt Acknowledged), which were
@@ -693,8 +696,8 @@ cascading, but not daisy chaining, so it seems that you can't have three or more
PICs where there is a slave PIC hooked to an IRQ of the master, then the slave
PIC has its own slave hooked to an IRQ of it in a three-level arrangement.
-When using the 8259A PIC, whenever a Device signaled an interrupt, the PIC
-received it via an IRQ line, then the PIC signaled its own interrupt to the
+When using the 8259A PIC, whenever a Device signalled an interrupt, the PIC
+received it via an IRQ line, then the PIC signalled its own interrupt to the
Processor, which received it via INTR. The Processor, in turn, used an ISR that
activated the INTA line to acknowledge the PIC request. Then, the PIC told the
Processor from which IRQ the Device interrupt was coming from, so it could
@@ -722,7 +725,7 @@ memory transactions from it.
In this primitive era, most chips were rather dull and simple, they just limited
themselves to do very specific functions. Having Devices like a Floppy Disk
Controller or a Sound Card being able to independently initiate a memory
-transaction was theorically possible, but expensive in both cost and physical
+transaction was theoretically possible, but expensive in both cost and physical
size due to the required amount of extra logic to add such a complex function.
The solution was to add a shared controller to do so on behalf of multiple
Devices, being able to provide a means to perform DMA without needing to have
@@ -807,20 +810,21 @@ concept of time. At most, what it can do is simply to count elapsed clock
cycles. Because the clock speed that a given part is running at is a known
value, it is possible to externally infer the real time elapsed based on a clock
cycle counter, at which point you have the first building block to count seconds
-(Or fractions of it). While theorically the CPU can count clock cycles, it would
-be a waste for it to do so, since it means that it wouldn't be able to do
+(Or fractions of it). While theoretically the CPU can count clock cycles, it
+would be a waste for it to do so, since it means that it wouldn't be able to do
anything else without completely desynchronizing. For this reason, there were
dedicated timers whose only purpose was to count cycles without interruptions,
as they were required to be as consistent as possible for any timing
measurements to be accurate.
-The 8253 PIT was an interesing chip due to the amount of functions than it could
-do that exceeded those of a simple timer. Actually, it had three independent
-timers, known as Counters 0, 1 and 2. All three timers could be directly usable
-by Software, as you could program every how many clock cycles they had to tick
-then just read back values. Each Counter also had both an input GATE line and an
-output OUT line, the latter which could be independently triggered by that
-Counter to allow the 8253 to directly interface with other Hardware.
+The 8253 PIT was an interesting chip due to the amount of functions than it
+could do that exceeded those of a simple timer. Actually, it had three
+independent timers, known as Counters 0, 1 and 2. All three timers could be
+directly usable by software, as you could program every how many clock cycles
+they had to tick then just read back values. Each Counter also had both an input
+GATE line and an output OUT line, the latter which could be independently
+triggered by that Counter to allow the 8253 to directly interface with other
+Hardware.
The IBM PC not only used all three 8253 Counters, it also used all their
external OUT lines, too. Counter 0 was used as the System Timer to keep track of
@@ -841,7 +845,7 @@ directly interfaced with it had to understand that protocol. Yet, when it came
to interface with external peripherals, instead of adapting them to understand
the CPU Bus protocol, designers seemed to always opt for some form of GPIO
(General Purpose I/O). GPIO can be used to make protocol agnostic interfaces
-where you can bit-bang raw data in and out, and leave Software like a Device
+where you can bit-bang raw data in and out, and leave software like a Device
Driver to interpret the raw Bits meanings. It could be considered a raw Bus with
an user-defined protocol. Obviously, there were specialized intermediary chips
that interfaced with the CPU Bus protocol to provide such GPIO.
@@ -853,13 +857,13 @@ an external connector if you wanted to do so (Albeit stretching that much a
circuit may hurt signal integrity if cables are too long or poor quality,
causing a severely limited maximum possible stable clock speed, but the point is
that it would still work). IBM itself did that with the IBM 5161 Expansion
-Chassis addon for the IBM PC 5150 and IBM PC/XT 5160, which was pretty much a
+Chassis add-on for the IBM PC 5150 and IBM PC/XT 5160, which was pretty much a
separate Computer Case that was cabled to the main computer and provided more
room for expansion slots. I assume that bit-banging though GPIO is just far
easier to implement in simple peripherals than a direct CPU Bus interface, and
it would also be completely neutral in nature thus easier to interface with
other computer platforms. Nowadays, a lot of what previously used to be done via
-GPIO interfaces is now done via USB, which is a well defined protocol.
+GPIO interfaces is now done via USB, which is a well-defined protocol.
The Intel 8255 PPI provided a total of 24 GPIO Pins arranged as 3 Ports of 8
Pins each, named Ports A, B and C. Port C could also be halved into two 4 Pin
@@ -880,11 +884,11 @@ a Keyboard Controller in the proper sense of the word, as it just provides a
generic GPIO interface. It could be said than it is as much of a Keyboard
Controller as the 8253 PIT is a Sound Card, they were not designed to do those
roles, just parts of those subsystems circuitry). While inbound data from the
-Keyboard generated interrupts on IRQ 1, the 8255 itself didn't signaled those
+Keyboard generated interrupts on IRQ 1, the 8255 itself didn't signalled those
with its built-in interrupt logic because it was not wired to the 8259A PIC at
all. Instead, the glue logic that did the serial-to-parallel conversion of the
incoming Keyboard data so that it could be feed to the 8255 was also wired to
-the PIC and signaled the interrupts. Port A also had some auxiliary glue logic
+the PIC and signalled the interrupts. Port A also had some auxiliary glue logic
that wired it to a set of DIP Switches in the Motherboard known as SW1, and
whenever Port A was getting input from the DIP Switches or the Keyboard depended
on the status of a configuration Pin on Port B.
@@ -952,13 +956,13 @@ ROMs as MMIO. These segments would be known in DOS jargon as Conventional Memory
and UMA (Upper Memory Area), respectively. This is from where the famous 640 KiB
Conventional Memory limit for DOS applications comes from.
-The contents of the Conventional Memory are pretty much Software defined, with a
+The contents of the Conventional Memory are pretty much software defined, with a
single exception: The very first KiB of the Conventional Memory is used by the
CPU IVT (Interrupt Vector Table), which has 256 Interrupt entries 4 Bytes in
size each. Each entry (Vector) was a pointer for an Interrupt ISR (Interrupt
Service Routine). From these 256 entries, Intel used only the first 8 (INT 0-7)
as 8086/8088 internal Exceptions, marked from 9-32 (INT 8-31) as reserved for
-future expansion, then let the rest available for either Hardware or Software
+future expansion, then let the rest available for either Hardware or software
Interrupts. IBM, in its infinite wisdom, decided to start mapping its ISR
pointers beginning at INT 8, which was reserved. This would obviously cause some
issues when Intel decided to expand the possible Exceptions Interrupts, causing
@@ -967,7 +971,7 @@ some overlap.
In the case of the UMA segment, the IBM defined Memory Map had several ranges
that were either used, marked as reserved or explicitly free. The sum of the
actually used ones was 68 KiB, consisting of all the Motherboard ROM plus two
-video framebuffers: 8 KiB (1016 KiB to 1023 KiB) for the Firmware ROM, that is
+video framebuffers: 8 KiB (1016 KiB to 1023 KiB) for the firmware ROM, that is
the only thing that had to be located at a mandatory address as required by the
8088 CPU, 32 KiB (984 KiB to 1015 KiB) for the IBM Cassette BASIC, made out of
four 8 KiB ROM chips, 8 KiB (976 KiB to 983 KiB) for an optional ROM chip on the
@@ -995,15 +999,14 @@ number of newly defined or otherwise reserved address ranges in the Memory Map
grew as IBM released more types of expansion cards (For example, the Technical
Reference Manual previously linked is dated from August 1981, there is a later
one from April 1984 that added a fixed address range for the ROM of the new Hard
-Disk Controller card). Sometimes, IBM could define
-two or more sets of resources if it was intending that more than one card of the
-same Device type was usable in a system, those cards had Jumpers or DIP Switches
-to select between the multiple fixed sets of resources. An example is
-[this IBM card][5150ac] that had a Serial Port with a DIP Switch to select
-between two sets of resources, which would become much more known as COM1 and
-COM2.
-
-The IBM resource hardwiring practices would become a problem for third party
+Disk Controller card). Sometimes, IBM could define two or more sets of resources
+if it was intending that more than one card of the same Device type was usable
+in a system, those cards had Jumpers or DIP Switches to select between the
+multiple fixed sets of resources. An example is [this IBM card][5150ac] that had
+a Serial Port with a DIP Switch to select between two sets of resources, which
+would become much more known as COM1 and COM2.
+
+The IBM resource hard-wiring practices would become a problem for third party
developers, as they had to make expansion cards that had a wide range of
configurable resources to guarantee compatibility in the foreseeable scenario
that IBM released a new card that used the same resources, or that another third
@@ -1012,7 +1015,7 @@ Jumpers or DIP Switches that allowed you to select at which address ranges you
wanted to map whatever memory they had, which depending on the needs of the
card, could include mapping RAM or ROM memory in different ranges of the UMA,
and different I/O Ports. Same with IRQs and DMA Channels. You also had to
-configure the Software to make sure that it knew where to look at for that card,
+configure the software to make sure that it knew where to look at for that card,
as third party Devices had common defaults but these were not guaranteed, unlike
IBM fixed resource definitions for their cards.
@@ -1035,9 +1038,9 @@ on these cards could be used as system RAM.
An important consideration was that all system RAM had to be mapped as a single
contiguous chunk, gaps were not accepted in the Conventional Memory mapping
(This seems to NOT have been true in the original IBM PC 16KB - 64KB Motherboard
-with the first Firmware version, as I have actually read about it supporting
-noncontiguous memory. Chances are than that feature was dropped because it also
-required support from user Software, which would have made Memory Management far
+with the first firmware version, as I have actually read about it supporting
+non-contiguous memory. Chances are than that feature was dropped because it also
+required support from user software, which would have made Memory Management far
more complex). As such, all Memory expansion cards supported a rather broad
selection of address ranges to make sure that you could always map their RAM
right after the Motherboard RAM, or right after the RAM from another Memory
@@ -1049,7 +1052,7 @@ single Bank populated.
A little known quirk is that while the IBM PC designers did not intend that
there was more than 640 KiB system RAM, nothing stopped you from mapping RAM
into the UMA for as long that the address decoding logic of the Memory expansion
-card supported doing so. With some hacks to the BIOS Firmware, it was possible
+card supported doing so. With some hacks to the BIOS firmware, it was possible
to get it to recognize more than 640 KiB Conventional Memory, and pass down this
data to the Operating System. PC DOS/MS-DOS supported this hack out of the box
since they relied on the BIOS to report the amount of system RAM that the
@@ -1061,16 +1064,16 @@ system RAM depended on which was the first UMA range in use.
Even in the best case scenarios, the beginning of the Video Card framebuffer was
effectively the highest limit than the hack could work: With CGA, it could go up
to 736 KiB, with MDA, up to 704 KiB, and with later Video Cards like EGA and
-VGA, you couldn't extend it at all since their UMA ranges beginned exactly at
-the 640 KiB boundary. Mapping the video framebuffer higher was possible, but it
+VGA, you couldn't extend it at all since their UMA ranges began exactly at the
+640 KiB boundary. Mapping the video framebuffer higher was possible, but it
required both a specialized Video Card that allowed you to do so, to further
-hack the Firmware, and even to patch the user Software, so that it would use the
+hack the firmware, and even to patch the user software, so that it would use the
new address range instead of blindly assuming that the video framebuffer was at
-the standard IBM defined range. Thus, while theorically possible, it should have
-been even rarer to see someone trying to move the video framebuffers to see more
-RAM as standard Conventional Memory due to the excessive complexity and
+the standard IBM defined range. Thus, while theoretically possible, it should
+have been even rarer to see someone trying to move the video framebuffers to see
+more RAM as standard Conventional Memory due to the excessive complexity and
specialized Hardware involved. These days it should be rather easy to
-demonstrate those hacks on emulated environments, then attemping them in real
+demonstrate those hacks on emulated environments, then attempting them in real
Hardware.
I don't know if later systems could work with any of these hacks (Albeit someone
@@ -1079,7 +1082,7 @@ Conventional Memory if using CGA), but as the newer types of Video Cards with
their fixed mappings beginning at 640 KiB became popular, the hacks ceased to be
useful considering how much effort they required. As such, hacks that allowed a
computer to have more than 640 KiB Conventional Memory were rather short lived.
-Overally, if you could map RAM into the UMA, it was just easier to use it for a
+Overall, if you could map RAM into the UMA, it was just easier to use it for a
small RAMDisk or something like that.
[5150ac]: http://www.minuszerodegrees.net/5150_5160/cards/5150_5160_cards.htm#ac_adapter
@@ -1093,7 +1096,7 @@ version. The IBM PC 5150 Technical Reference from August 1981 mentions that the
Motherboard dimensions are around 8.5' x 11', which in centimeters would be
around 21.5 cm x 28 cm. These should be correct for the first 16KB - 64KB
Motherboard found in the PC-1. The April 1984 Technical Reference instead
-mentions 8.5' x 12', and also gives an accurate value in milimeters, rounding
+mentions 8.5' x 12', and also gives an accurate value in millimeters, rounding
them to 21.5 cm x 30.5 cm. Given than the second Technical Reference corresponds
to the 64KB - 256KB Motherboard of the PC-2, both sizes should be true, just
that IBM didn't specifically mentioned which Motherboard they were talking about
@@ -1112,7 +1115,7 @@ more installed RAM than usable RAM already?), the 9 DRAM chips of Bank 0 always
came soldered, a bad design choice that eventually caused some maintenance
issues as it was much harder to replace one of these chips if they were to fail.
Some components like the main Intel 8088 CPU, the ROM chips with the BIOS
-Firmware and the IBM Cassette BASIC came socketed, yet these had only an
+firmware and the IBM Cassette BASIC came socketed, yet these had only an
extremely limited amount of useful replacements available that appeared later on
the IBM PC life cycle, and ironically, seems to not have failed as often as the
soldered RAM.
@@ -1138,20 +1141,20 @@ it was part of the Power Supply Unit itself, the PC Speaker had the privilege to
be the first member of the Front Panel Headers found in modern Motherboards.
The IBM PC Keyboard, known as Model F, deserves a mention. The Keyboard looks
-rather interesing the moment that you notice that inside it, there is an Intel
-8048 Microcontroller working as a Keyboard Encoder, making the Keyboard itself
+rather interesting the moment that you notice that inside it, there is an Intel
+8048 Micro-controller working as a Keyboard Encoder, making the Keyboard itself
to look as if it was a microcomputer. The 8048 is part of the Intel MCS-48
-family of Microcontrollers, and had its own integrated 8 Bits CPU, Clock
+family of micro-controllers, and had its own integrated 8 Bits CPU, Clock
Generator, Timer, 64 Bytes RAM, and 1 KiB ROM. Regarding the ROM contents,
-manufacturers of Microcontrollers had to write the customer code during the chip
-manufacturing (Some variants of the 8048 came with an empty ROM that could be
-programmed once, some even reprogrammed), which means than the 8048 that the IBM
-Model F Keyboard used had a built-in Firmware specifically made for it, so it
-was impossible to replace the Model F 8048 for another 8048 that didn't came
+manufacturers of micro-controllers had to write the customer code during the
+chip manufacturing (Some variants of the 8048 came with an empty ROM that could
+be programmed once, some even reprogrammed), which means than the 8048 that the
+IBM Model F Keyboard used had a built-in firmware specifically made for it, so
+it was impossible to replace the Model F 8048 for another 8048 that didn't came
from the same type of unit. Some people recently managed to dump the 8048
-Firmware used by the IBM Model F Keyboard, for either emulation purposes or to
+firmware used by the IBM Model F Keyboard, for either emulation purposes or to
replace faulty 8048s with working reprogrammable chips with the original Model F
-Firmware.
+firmware.
##### 2.6 - IBM PC Motherboard Buses (Local Bus, I/O Channel Bus, Memory Bus)
@@ -1166,7 +1169,7 @@ the core chips that defined the base platform.
Regarding the chip interconnects, as can be seen in the System Board Data Flow
diagram at Page 2-6 of the IBM PC 5150 Technical Reference Manual, the IBM PC
-had two well defined Buses: The first one was the parallel Local Bus, that
+had two well-defined Buses: The first one was the parallel Local Bus, that
interconnected the Intel 8088 CPU, the optional 8087 FPU, the 8288 Bus
Controller and the 8259A PIC, and the second one was called the I/O Channel Bus,
that transparently extended the Local Bus and interfaced with almost everything
@@ -1190,7 +1193,7 @@ interface them with third party chips, while the 8288 Bus Controller did the
same with the 8088 Control Bus lines. What this means is that the I/O Channel
Bus is pretty much a demultiplexed transparent extension of the Local Bus that
is behind some glue logic but has full continuity with it, it is not a separate
-entitity. As such, in the IBM PC, everything effectively sits in a single,
+entities. As such, in the IBM PC, everything effectively sits in a single,
unified system wide parallel Bus. That means that all the chips were directly
visible and accessible to each other, which made the IBM PC Motherboard to look
like a giant backplane that just happen to have some built-in Devices.
@@ -1211,7 +1214,7 @@ create their own, custom expansion slot and its composite Bus. Before IBM began
designing the IBM PC, Intel had already used for at least some of its reference
8086/8088 platforms its own external Bus and connector standard, Multibus.
Another option would have been the older, industry standard S-100 Bus. While it
-is easy to find discussions about why IBM choosed the Intel 8088 CPU over other
+is easy to find discussions about why IBM chose the Intel 8088 CPU over other
contemporary Processor alternatives, I failed to find anyone asking about why
IBM decided to create a new expansion slot type. Whenever IBM wanted to roll a
new expansion slot standard as a vendor lock-in mechanism or just do so to sell
@@ -1272,7 +1275,7 @@ actually had installed 1.125 KiB (1 + 1/8) of raw RAM. I suppose that IBM picked
straightforward to implement with the other alternatives. The Parity circuitry
was wired to both some GPIO Pins of the 8255 PPI and to the NMI Pin on the 8088
CPU, and was also exposed in the expansion slots. When a Memory Controller
-signaled an NMI, an ISR fired up that checked the involved 8255 PPI Ports Bits
+signalled an NMI, an ISR fired up that checked the involved 8255 PPI Ports Bits
as a means to identify whenever the Parity error happened on the RAM in the
Motherboard or in a Memory expansion card. Note than not all Memory expansion
cards fully implemented Parity, some cheap models may work without Parity to
@@ -1282,7 +1285,7 @@ At the time of the IBM PC, Parity was a rare feature considered unworthy of
personal computers (Ever hear about famous supercomputer designer Seymour Cray
saying "Parity is for farmers", then comically retracting a few years later of
that statement by saying "I learned that farmers used computers"?), yet IBM
-decided to include it anyways. This is the type of actitude that made IBM highly
+decided to include it anyways. This is the type of attitude that made IBM highly
renowned for the reliability of its systems. In comparison, modern Memory
Modules standards like DDR3/4 also supports 1 Bit Error Detection, but without
the need of extra raw RAM because it works on whole 64 Bits Ranks that allows
@@ -1300,7 +1303,7 @@ MinusZeroDegrees, has the unofficial name of External I/O Channel Bus (The
Technical Reference Block Diagram just calls them external Address Bus and
external Data Bus). The External I/O Channel Bus was separated from the main I/O
Channel Bus by some intermediate glue chips. Connected to this Bus, you had the
-ROM chips for the Motherboard Firmware and the IBM Cassette BASIC, and the Intel
+ROM chips for the Motherboard firmware and the IBM Cassette BASIC, and the Intel
8237A DMAC, Intel 8253 PIT, and Intel 8255 PPI support chips. An important
detail is that the External I/O Channel Bus didn't had all the 20 Address lines
available to it, it had only 13, that was just enough to address the internal
@@ -1326,8 +1329,8 @@ It was possible to mix an IBM PC with cards that did 16 Bits decoding, but you
had to be aware of all of your Hardware address decoding capabilities and the
possible configuration options, as there were high chances that the mapping
overlapped. For example, in the case of an IBM PC with a card that decoded 16
-Bits, while the card should be theorically mappeable to anywhere in the 64 KiB
-I/O Address Space, if the choosen I/O Port range was above 1 KiB, you had to
+Bits, while the card should be theoretically mappable to anywhere in the 64 KiB
+I/O Address Space, if the chosen I/O Port range was above 1 KiB, you had to
check if it overlapped with any of the aliased addresses of the existing 10 Bits
Devices, which I suppose that should have been simple to figure out if you made
a cheatsheet of the current 1 KiB I/O Port Map, then repeated it for every KiB
@@ -1383,7 +1386,7 @@ OSC Pin in the I/O Channel expansion slots. Pretty much the only card that used
the OSC line was the CGA Video Card, which included its own clock divisor that
divided the 14.31 MHz OSC line by 4 to get a 3.57 MHz TV compatible NTSC signal,
so that the CGA Video Card could be directly connected to a TV instead of a
-computer Monitor. Actually, it is said that IBM choosed the 14.31 MHz Crystal
+computer Monitor. Actually, it is said that IBM chose the 14.31 MHz Crystal
Oscillator precisely because it made easy and cheap to derive a NTSC signal from
it.
@@ -1415,9 +1418,10 @@ Microcontroller inside the Model F Keyboard has an integrated Clock Generator
that can use as clock input either a Crystal Oscillator, or a line coming
straight from an external Clock Generator. A schematic for the Model F Keyboard
claims that the 8048 uses a 5.247 MHz reference clock as input, yet I failed to
-identify a Crystal Oscillator in the photos of a dissambled Keyboard. I'm still
-not sure whenever the 8048 in the Keyboard makes direct use of the Keyboard Port
-clock Pin or not, as both options are viable to use as reference clock.
+identify a Crystal Oscillator in the photos of a disassembled Keyboard. I'm
+still not sure whenever the 8048 in the Keyboard makes direct use of the
+Keyboard Port clock Pin or not, as both options are viable to use as reference
+clock.
An important exception in the IBM PC clocking scheme were the RAM chips used as
system RAM, as their functionality was not directly bound at all to any clock
@@ -1515,7 +1519,7 @@ Drives were optional, as IBM intended Diskettes to be the high end storage
option while Cassettes took care of the low end, which is the reason why IBM
included a built-in port in the Motherboard to connect to a Cassette Deck. This
market segmentation strategy seems to have failed very early on the life of the
-IBM PC, as Cassette-only models soon dissapeared from the market. At the time of
+IBM PC, as Cassette-only models soon disappeared from the market. At the time of
the IBM PC release, the only compatible Diskettes had a 160 KB usable size after
formatting. I have no idea about how much usable capacity a Cassette had.
@@ -1600,9 +1604,9 @@ upgrade cards, but instead of replacing some of the Motherboard core components
with those sitting in the card itself, they added independent Processors and
RAM. Examples of such cards include the [Microlog BabyBlue II][babyblue], which
had a Zilog Z80 CPU along with some RAM. Cards like these could be used to run
-Software compiled for other ISAs in these addon Processors instead of x86, and
+software compiled for other ISAs in these add-on Processors instead of x86, and
is basically how emulation looked like during the 80's where you couldn't really
-do it purely in Software, actually requiring dedicated Hardware to do the heavy
+do it purely in software, actually requiring dedicated Hardware to do the heavy
lifting.
[inboard]: http://www.minuszerodegrees.net/manuals/Intel%20Inboard%20386_PC%20Manual.pdf
@@ -1612,14 +1616,14 @@ lifting.
##### 2.9 - IBM PC BIOS Firmware (BIOS Services, Option ROMs)
-Yet another major piece of the IBM PC was a Software one, the Firmware, that was
-stored in one of the Motherboard ROM chips. The IBM PC Firmware was formally
-known as the BIOS. The BIOS Firmware was the very first code that the Processor
+Yet another major piece of the IBM PC was a software one, the firmware, that was
+stored in one of the Motherboard ROM chips. The IBM PC firmware was formally
+known as the BIOS. The BIOS firmware was the very first code that the Processor
executed, and for that reason, the ROM had to be mapped to a specific location
-of the Memory Address Space so that it could satisfy the 8088 CPU hardcoded
+of the Memory Address Space so that it could satisfy the 8088 CPU hard-coded
startup behavior. The BIOS was responsible for initializing and testing most of
the computer components during POST before handing out control of the computer
-to user Software. You can [read here][postbreakdown] a detailed breakdown of all
+to user software. You can [read here][postbreakdown] a detailed breakdown of all
the things that the BIOS did during POST before getting the computer into an
usable state. Some parts of the BIOS remained always vigilant for user input,
like [the legendary routine][ctrlaltdel] that intercepted the Ctrl + Alt + Del
@@ -1627,13 +1631,13 @@ Key Combination.
The BIOS also provided a crucial component of the IBM PC that is usually
underappreciated: The BIOS Services. The BIOS Services were a sort of API
-(Application Programming Interface) that the OS and user Software could call via
-Software Interrupts as a middleware that interfaced with the platform Hardware
+(Application Programming Interface) that the OS and user software could call via
+software Interrupts as a middleware that interfaced with the platform Hardware
Devices. As such, the BIOS Services could be considered like built-in Drivers
for the computer. IBM actually expected that the BIOS Services could eventually
be used as a HAL (Hardware Abstraction Layer), so if the support chips ever
-changed, Software that relied on the BIOS Services would be forward compatible.
-Although IBM strongly recommended to Software developers to use the BIOS
+changed, software that relied on the BIOS Services would be forward compatible.
+Although IBM strongly recommended to software developers to use the BIOS
Services, it was possible for applications to include their own Drivers to
bypass them and interface with the Hardware Devices directly. Many performance
hungry applications did exactly that, as the BIOS Services were very slow.
@@ -1644,9 +1648,9 @@ Compared to later systems, there was no "BIOS Setup" that you could enter by
pressing a Key like Del during POST, nor there was any non volatile writable
memory where the BIOS could store its settings. Instead, the Motherboard was
outfitted with several DIP Switches, the most notorious ones being SW1 and SW2,
-whose positions had hardcoded meanings for the BIOS, which checked them on every
-POST. This made the BIOS configuration to be quite rudimentary in nature, as any
-change required physical access to the Motherboard.
+whose positions had hard-coded meanings for the BIOS, which checked them on
+every POST. This made the BIOS configuration to be quite rudimentary in nature,
+as any change required physical access to the Motherboard.
The BIOS pretty much did no Hardware discovery on its own, it just limited
itself to check during POST for the presence of the basic Hardware Devices that
@@ -1670,12 +1674,13 @@ ask the BIOS what Hardware it thought that the computer had installed. For
example, INT 11h was the Equipment Check, that could be used by an application
to determine if the computer was using a MDA or a CGA Video Card, among other
things. There was also INT 12h, which returned the amount of Conventional
-Memory. A rather interesing detail of INT 12h is that it was the closest thing
-to a Software visible Memory Map available during that era. Neither the BIOS,
+Memory. A rather interesting detail of INT 12h is that it was the closest thing
+to a software visible Memory Map available during that era. Neither the BIOS,
the OS nor the user applications knew how the Memory Map of the computer truly
-was, they just blindly used what they were hardcoded to know about based on both
-the IBM defined Memory Map, and any user configurable Drivers that could point
-to where in the Memory and I/O Address Spaces an expansion card was mapped to.
+was, they just blindly used what they were hard-coded to know about based on
+both the IBM defined Memory Map, and any user configurable Drivers that could
+point to where in the Memory and I/O Address Spaces an expansion card was mapped
+to.
It was possible to upgrade the BIOS of the IBM PC, but not by flashing it. You
were actually required to purchase a new ROM chip with the latest BIOS version
@@ -1697,7 +1702,7 @@ Device that was not supported by the BIOS would still work if using either an OS
Driver, or an application that included a built-in Driver for that Device, which
was the case with Sound Cards (Although these came much, much later). However,
there were scenarios where a Device had to be initialized very early for it to
-be useful. For example, the earliest HDs (Hard Diskses) and HDC (Hard Disk
+be useful. For example, the earliest HDs (Hard Disks) and HDC (Hard Disk
Controller) cards that could be used on the IBM PC were from third parties that
provided Drivers for the OS, so that it could initialize the HDC and use the HD
as a storage drive. As the BIOS had absolutely no knowledge about what these
@@ -1725,7 +1730,7 @@ get a new BIOS ROM. Moreover, such implementation would have hit a hard limit
rather soon due to the fixed Motherboard address decoding logic for the BIOS 8
KiB ROM chip, while an expansion card was free to use most of the UMA to map its
Option ROM. Considering that we are still using Option ROMs, the solution that
-IBM choosed was a very good one.
+IBM chose was a very good one.
Related to Option ROMs, an extremely obscure feature of the IBM PC 5150 is that
the previously mentioned empty ROM socket, known as U28, was already mapped in
@@ -1749,11 +1754,11 @@ Last but not least, after the BIOS finished the POST stage, it had to boot
something that allowed the computer to be useful. Without Option ROMs, the IBM
PC BIOS knew how to boot from only two types of storage media: Diskettes, via
the FDC and the first Diskette Drive, or the built-in IBM Cassette BASIC, also
-stored in ROM chips in the Motherboard like the BIOS Firmware itself.
+stored in ROM chips in the Motherboard like the BIOS firmware itself.
If your IBM PC couldn't use Diskettes because you had no FDC or Diskette Drive,
or there was no Diskette inserted in the Diskette Drive, the BIOS would boot the
-built-in IBM Cassette BASIC. This piece of Software isn't widely known because
+built-in IBM Cassette BASIC. This piece of software isn't widely known because
only genuine IBM branded computers included it. Perhaps the most severe
limitation of the IBM Cassette BASIC was that it could only read and write to
Cassettes, not Diskettes, something that should have played a big role in how
@@ -1765,10 +1770,10 @@ usefulness was very limited.
The other method to boot the IBM PC was with Diskettes. Not all Diskettes could
be used to boot the computer, only those that had a valid VBR (Volume Boot
-Record) were booteable. The VBR was located in the first Sector (512 Bytes) of
+Record) were bootable. The VBR was located in the first Sector (512 Bytes) of
the Diskette, and stored executable code that could bootstrap another stage of
-the boot process. Besides the booteable Diskettes with the OSes themselves,
-there were self contained applications and games known as PC Booters that had no
+the boot process. Besides the bootable Diskettes with the OSes themselves, there
+were self contained applications and games known as PC Booters that had no
reliance on an OS at all, these could be booted and used directly from a
Diskette, too.
@@ -1781,8 +1786,8 @@ Diskette, too.
##### 2.10 - IBM PC Operating Systems (PC DOS, PC Booters) and user experience
The last piece of the IBM PC was the Operating System. While the OS is very
-reelevant to the platform as a whole functional unit, it is not part of the
-Hardware itself (The Firmware is Software, yet it is considered part of the
+relevant to the platform as a whole functional unit, it is not part of the
+Hardware itself (The firmware is software, yet it is considered part of the
Motherboard as it comes in a built-in ROM with code that is highly customized
for the Hardware initialization of that specific Motherboard model. However, the
IBM Cassette BASIC was also in the Motherboard ROM but can actually be
@@ -1790,10 +1795,10 @@ considered some sort of built-in PC Booter). The Hardware platform is not bound
to a single OS, nor it is guaranteed that an user with a specific Hardware
platform uses or even has an OS, either.
-What made OSes important are their System Calls. System Calls are Software
+What made OSes important are their System Calls. System Calls are software
Interrupts similar in style and purpose to the BIOS Services, as both are APIs
used to abstract system functions from user applications. The major difference
-between them is that the BIOS Services relies on Firmware support, so they are
+between them is that the BIOS Services relies on firmware support, so they are
pretty much bound to the Hardware platform, while System Calls relies on the OS
itself. Since at the time of the IBM PC launch it was very common that the same
OS was ported to many Hardware platforms, an application that relied mainly on
@@ -1821,20 +1826,20 @@ could instead focus on the new Hardware (Mainly the CPU, as it was a different
ISA than the previous 8 Bits ones like the Intel 8080/8085 CPUs). However, as
far that I know, the CP/M System Calls of PC DOS were barely used, and pretty
much entirely forgotten after PC DOS took over the vast majority of OS
-marketshare.
+market share.
-Perhaps the most reelevant and exclusive feature of PC DOS was that it had its
+Perhaps the most relevant and exclusive feature of PC DOS was that it had its
own File System for Diskettes, FAT12 (File Allocation Table. Originally it was
merely named FAT, but it has been retconned). A File System is a data
organization format that with the aid of metadata defines how the actual user
data is stored onto a storage media. The DOS API provided an interface that
-Software could use to easily read and write to Diskettes formatted in FAT12,
+software could use to easily read and write to Diskettes formatted in FAT12,
greatly simplifying development of user applications that had to store files. I
have no idea if PC DOS was able to effectively use Cassettes on its own as a
Diskette alternative, it is a quite unexplored topic.
In the early days of the IBM PC, it seems that only office and productivity
-Software that had to deal with data storage in Diskettes used PC DOS, as they
+software that had to deal with data storage in Diskettes used PC DOS, as they
could rely on the DOS API to use FAT12. If the developer didn't needed
sophisticated storage services, or could do its own implementation of them
(Albeit such implementation may not necessarily be FAT12 compatible, thus not
@@ -1854,9 +1859,9 @@ selling a full fledged UNIX based OS, Xenix, for other non-x86 platforms.
One of the things that I was always curious about, is how the daily usage of an
IBM PC was like from the perspective of an early adopter. Information about the
-IBM PC 5150 user experience in 1981 is scarse, but based on what I could muster
+IBM PC 5150 user experience in 1981 is scarce, but based on what I could muster
from digital archivists blog posts and such, the limited amount of expansion
-cards and user Software means that there weren't a lot of things that you could
+cards and user software means that there weren't a lot of things that you could
do with one right at the launch date. That makes somewhat easy to hypothesize
about how the IBM PC could have been used by an average user...
@@ -1888,8 +1893,8 @@ Booting PC DOS from a Diskette should have been an experience similar to booting
a modern day Live CD in a computer with no Hard Disk, with the major difference
being that every application that you may have wanted to use was in its own
Diskette, so you had to disk swap often. Due to the fact that RAM was a very
-scarse and valuable resource, the whole PC DOS didn't stayed resident in RAM,
-only the code reelevant for the DOS API did, leaving an application able to
+scarce and valuable resource, the whole PC DOS didn't stayed resident in RAM,
+only the code relevant for the DOS API did, leaving an application able to
freely overwrite the rest. Because of this, if you executed then exited a DOS
application, typically you also had to disk swap back again to the PC DOS
Diskette to reload it, then disk swap once more to whatever other application
@@ -1932,15 +1937,15 @@ you should have already figured out yourself about all the things that the
definition of platform involves. A computer platform can be defined, roughly, as
all of the previously explained things considered as part of a whole functional
unit. There are subdivisions like the Hardware platform, that focuses only on a
-minimum fixed set of physical components, and the system Software, that includes
-Firmware and OS, the first which can be upgraded or extended, and the latter
+minimum fixed set of physical components, and the system software, that includes
+firmware and OS, the first which can be upgraded or extended, and the latter
that is not even a required component at all for the existence of standalone
-user Software, albeit it makes for it to be easier to develop.
+user software, albeit it makes for it to be easier to develop.
How much the components of a computer platform can vary while still being
-considered the same platform, is something quite constrained by the requeriments
-of the Software that will run on it. The user Software can make a lot of fixed
-assumptions about both the Hardware platform and the system Software, so if you
+considered the same platform, is something quite constrained by the requirements
+of the software that will run on it. The user software can make a lot of fixed
+assumptions about both the Hardware platform and the system software, so if you
want that these applications work as intended, the computer must provide an
environment that fully satisfies all those assumptions. In the Hardware side,
the most important part is the Processor due to the Binary Compatibility, so
@@ -1950,20 +1955,20 @@ Video Card, all of which can be directly interfaced with by applications (This
statement was true with 80's and early 90's platforms at most. In our modern
days you always go though a middleware API, like DirectX, OpenGL or Vulkan in
the case of Video Cards or some OS System Call for everything else), as they can
-be found in a fixed or at least predictable Memory Map. In the system Software
-side, you have the Firmware and the OS, both of them providing Software
-Interrupts with a well defined behavior that are intended to ease for
+be found in a fixed or at least predictable Memory Map. In the system software
+side, you have the firmware and the OS, both of them providing software
+Interrupts with a well-defined behavior that are intended to ease for
applications how to interface with the Hardware. An application could assume
that most of these things were present and behaved in the exact same way in all
the systems it would be run on, so any unexpected change could break some
function of the application or cause that it didn't work at all.
When you consider the IBM PC as a whole unit, you can think of it as a reference
-platform. As the user Software could potentially use all of the IBM PC platform
+platform. As the user software could potentially use all of the IBM PC platform
features, it was a minimum of things that had to be present in any system that
expected to be able to run applications intended for an IBM PC. There could be
optional Devices that could enhance an application functionality, but these
-weren't a problem because user Software didn't always assumed that an optional
+weren't a problem because user software didn't always assumed that an optional
Device was always available. For example, during the early 90's, not everyone
had a Sound Card, but everyone had a PC Speaker. Games typically supported both,
and albeit the PC Speaker capabilities aren't even remotely comparable to a
@@ -1972,7 +1977,7 @@ completely mute.
There were other platforms based on x86 Processors that were quite similar to
the IBM PC from a component standpoint, but barely compatible with its user
-Software. For example, in Japan, NEC released their PC-98 platform a bit more
+software. For example, in Japan, NEC released their PC-98 platform a bit more
than a year after the IBM PC, and from the core Hardware perspective, they have
a lot in common. The first PC-98 based computer, the NEC PC-9801, had an Intel
8086 CPU that required a wider Bus and a different type of expansion slots to
@@ -1987,15 +1992,15 @@ However, the NEC PC-98 platform had substantial differences with the IBM PC: The
Devices weren't wired to the 8237A DMAC and the 8259A PICs support chips in the
same way than on the IBM PC, so the standard DMA Channel and IRQ assignments for
them were different. The Video Card was completely different since it was
-designed with japanese characters in mind, thus anything from the IBM PC that
+designed with Japanese characters in mind, thus anything from the IBM PC that
wanted to use it directly, typically games, would not work. The PC-98 also had a
-Firmware that provided its own Software Interrupts, but they were not the same
+firmware that provided its own software Interrupts, but they were not the same
than those of the IBM PC BIOS, so anything that relied on the IBM PC BIOS
Services would fail to work, too. The Memory Map of the PC-98 was similar since
the Memory Address Space also was partitioned in two with the lower 640 KiB
reserved for system RAM and the upper 384 KiB for everything else, but the upper
section, which in the IBM PC was known as UMA, was almost completely different.
-In practice, the only IBM PC user Software that had any chance to work in the
+In practice, the only IBM PC user software that had any chance to work in the
PC-98 were PC DOS applications executed under PC-98 MS-DOS that relied only on
the DOS API, were console based and otherwise very light on assumptions,
anything else required to be ported.
@@ -2003,7 +2008,7 @@ anything else required to be ported.
From the platforms that were partially compatible with the IBM PC, a very
notorious one came from IBM itself: The IBM PCjr 4860, released in March 1984.
The IBM PCjr was a somewhat cut down version of the IBM PC that was targeted at
-the home user instead of the business user. While the PCjr Firmware was fully
+the home user instead of the business user. While the PCjr firmware was fully
BIOS compatible, it had some Hardware differences with the PC. The IBM PCjr
Video Card [wasn't fully CGA compatible][pcjrcga] as it had just a partial
implementation of the CGA registers, so any game that tried to directly
@@ -2016,46 +2021,46 @@ through the Processor as they couldn't be offloaded to a DMA Controller support
chip like in the IBM PC. This caused some applications to not work as expected,
since they couldn't perform some operations simultaneously. There were many more
differences, but the important point is that due to these differences, around
-half of the IBM PC Software library didn't run in the IBM PCjr, which is perhaps
+half of the IBM PC software library didn't run in the IBM PCjr, which is perhaps
the main reason why it failed in the market.
Yet another example of a platform is an IBM PC that had installed the Intel
InBoard 386/PC upgrade card mentioned a while ago. The upgrade card allowed an
IBM PC to enjoy the new Intel 80386 CPU performance and features, however, not
-all Software requiring a 386 would work with it. For example, a 386 allowed
+all software requiring a 386 would work with it. For example, a 386 allowed
Windows 3.0 to use the 386 Enhanced Mode, but Windows 3.0 assumed that if you
had a 386 Processor, you also had an IBM PC/AT compatible platform. An IBM PC
with an InBoard 386/PC is a PC class 386, which is a rather unique combination.
In order to make the upgrade card useful, Intel and Microsoft took the extra
-effort of colaborating to develop [a port][win3enhanced] of Windows 3.0 386
-Enhanced Mode for the IBM PC platform. This shortcoming essencially made the
+effort of collaborating to develop [a port][win3enhanced] of Windows 3.0 386
+Enhanced Mode for the IBM PC platform. This shortcoming essentially made the
whole Processor upgrade card concept a rather incomplete idea, it was simply too
much effort.
Among the most amazing engineering feats, I should include all the efforts made
to attempt to achieve cross compatibility between completely different computer
-platforms. Because in those days full Software emulation was not practical due
+platforms. Because in those days full software emulation was not practical due
to a lack of processing power, the only viable way to do so was to throw in
dedicated Hardware in an expansion card, which was still cheaper than a full
-secondary computer. With the help of Software similar in purpose to a Virtual
+secondary computer. With the help of software similar in purpose to a Virtual
Machine Monitor that arbitrated the shared host resources and emulated what was
-missing from the guest platform, you could execute Software intended for a
+missing from the guest platform, you could execute software intended for a
completely different one on your IBM PC. Examples include the previously
mentioned Microlog BabyBlue II, that had a Zilog Z80 CPU so that it could
natively run code from CP/M applications, or the [DCS Trackstar][trackstar] and
Quadram Quadlink, which included a MOS 6502 CPU, its own RAM, and a ROM with an
-Apple II compatible Firmware so that it could run Apple II applications.
+Apple II compatible firmware so that it could run Apple II applications.
-Some computers went dramatically further and attemped to fuse two platforms in
+Some computers went dramatically further and attempted to fuse two platforms in
one, including a very high degree of resource sharing as they were considered
-part of the same base platform instead of a simple addon expansion card. These
+part of the same base platform instead of a simple add-on expansion card. These
unique computers include the DEC Rainbow 100, that was both IBM PC compatible
and could run CP/M applications thanks to having both an Intel 8088 CPU and a
-Zilog Z80 CPU, but in a more tighly integrated relationship than an IBM PC with
+Zilog Z80 CPU, but in a more tightly integrated relationship than an IBM PC with
a BabyBlue II installed due to some specific resource sharing, or the Sega
TeraDrive, an IBM PC/AT and Sega Mega Drive (Genesis) hybrid with both an Intel
80286 CPU, Zilog Z80 CPU, and Motorola 68000 CPU. I'm even curious whenever
-someone ever attemped to emulate them due to their unique features...
+someone ever attempted to emulate them due to their unique features...
[pcjrcga]: http://nerdlypleasures.blogspot.com/2013/10/the-pcjr-and-cga-compatibility.html
[win3enhanced]: http://www.vcfed.org/forum/showthread.php?48312-Intel-Inboard-386-PC-Extremely-Rare-copy-of-Windows
@@ -2068,18 +2073,18 @@ Some of the earliest rivals that the IBM PC had to face in the personal computer
market were other computers extremely similar to the IBM PC itself, but based on
different platforms. Most of these PC-like platforms were x86 based (Some even
used the Intel 8086 CPU instead of the 8088) and also had their own ported
-versions of MS-DOS and other user Software, making them similar to the
+versions of MS-DOS and other user software, making them similar to the
previously mentioned NEC PC-98, but closer to the IBM PC than it, and thus far
more compatible.
-However, as the IBM PC popularity grew, its Software ecosystem did, too. Soon
+However, as the IBM PC popularity grew, its software ecosystem did, too. Soon
enough, it became obvious for any computer manufacturer that it would be
impossible to break into the personal computer market with yet another different
-computer platform that would require its own Software ports of almost
+computer platform that would require its own software ports of almost
everything, it was already hard enough for the partially compatible platforms
-that were already in the market to stay reelevant to keep introducing more.
-Thus, the idea of non-IBM computers that could run out of the box the same user
-Software than the IBM PC with no modifications at all, and even use the same
+that were already in the market to stay relevant to keep introducing more. Thus,
+the idea of non-IBM computers that could run out of the box the same user
+software than the IBM PC with no modifications at all, and even use the same
expansion cards, became highly popular...
The open architecture approach of the IBM PC made cloning the Hardware side of
@@ -2088,7 +2093,7 @@ while the IBM PC 5150 Technical Reference Manual had extensive diagrams
documenting how they were interconnected at the Motherboard level. Microsoft
would happily license MS-DOS and a Diskette version of Microsoft BASIC to other
computer manufacturers, too. There was a single showstopper: The IBM PC BIOS.
-While IBM openly provided the source code for it, it was propietary, making it
+While IBM openly provided the source code for it, it was proprietary, making it
the only thing that allowed IBM to keep the other computer manufacturers from
being able to fully clone the IBM PC. In fact, some of the earliest makers of
IBM PC clones got sued by IBM since they outright used the IBM PC BIOS source
@@ -2113,8 +2118,8 @@ available to other computer manufacturers at an affordable license cost (You can
caused a flood of competition from new manufacturers, as by that point, anyone
with some capital could set up a workshop to build computers with the same (Or
compatible) Hardware than that of the IBM PC, the PC DOS compatible MS-DOS from
-Microsoft, and a Firmware functionally equivalent to the IBM PC BIOS from
-Phoenix Technologies. All these clones were able to run almost all the Software
+Microsoft, and a firmware functionally equivalent to the IBM PC BIOS from
+Phoenix Technologies. All these clones were able to run almost all the software
designed for the IBM PC for a much lower price that what IBM charged for their
systems.
@@ -2136,7 +2141,7 @@ business and enterprise customers that paid for the brand (Remember the famous
ones that were directly fighting against the other partially compatible PC-like
platforms (And themselves) based on price and specifications. Clones
dramatically helped to increase the size of the installed user base of IBM PC
-compatible computers, snowballing the growth of its Software ecosystem at the
+compatible computers, snowballing the growth of its software ecosystem at the
cost of the other platforms, and consequently, driving even more sales of IBM PC
compatible computers. Is possible to say that the clones made all the PC-like
platforms go extinct.
@@ -2149,16 +2154,16 @@ platforms go extinct.
IBM, eager to continue the success of the IBM PC, released the IBM PC/XT 5160 in
March 1983. The PC/XT tackled on the main weakness of the IBM PC, which was that
-its 5 expansion slots were far from enough as the addons ecosystem began to
+its 5 expansion slots were far from enough as the add-ons ecosystem began to
grow. On top of that, it added an internal Hard Disk plus a HDC (Hard Disk
Controller) card as out-of-the-box components, albeit at the cost of a Diskette
Drive. In later models the Hard Disk would become entirely optional, being able
to run two internal Diskette Drives like the previous IBM PC did.
-From the platform perspective, the PC/XT is barely interesing as it had no core
+From the platform perspective, the PC/XT is barely interesting as it had no core
changes over the IBM PC 5150. It still had the same Processor, the same support
chips, the same Clock Generation, and the exact same performance. It had a
-slighty different Memory Map, but nothing major. In essence, the IBM PC/XT was
+slightly different Memory Map, but nothing major. In essence, the IBM PC/XT was
pretty much a wider version of the original IBM PC with some minor enhancements,
but otherwise functionally almost identical to it. In fact, most of the things
that could be added to it would also work in the previous PC. There is a single
@@ -2247,7 +2252,7 @@ About physical characteristics, as previously mentioned, there were two major
PC/XT Motherboard versions: The first one was the 64KB - 256KB, and the second
one was the 256KB - 640KB, which was released around 1986. The IBM PC/XT 5160
Technical Reference mentions that the Motherboard physical dimensions are 8.5' x
-12', which are aproximately 21.5 cm x 30.5 cm, and seems to apply to both
+12', which are approximately 21.5 cm x 30.5 cm, and seems to apply to both
Motherboards. That should make them identical in size to the second version of
the IBM PC 5150 Motherboard. However, I have seen at least one source
([Upgrading and Repairing PCs][upgradingpcs] by Scott Mueller) claiming that a
@@ -2268,11 +2273,11 @@ had the same arrangement than the 64KB - 256KB IBM PC Motherboard.
Something worth mentioning is that in the PC/XT Motherboards, all the RAM chips
are socketed, making troubleshooting a dead Motherboard easier than it was in
the IBM PC since you can swap the Bank 0 DRAM chips for other known good ones
-without having to desolder. Yet another miscellaneous but still interesing
+without having to desolder. Yet another miscellaneous but still interesting
change related to RAM is that the PC/XT, in order to determine how much system
RAM was installed in the computer, had a Conventional Memory scanning routine in
the BIOS that was executed during POST, so it pretty much autodetected it. This
-is in contrast to the IBM PC, whose Firmware just checked the position of a
+is in contrast to the IBM PC, whose firmware just checked the position of a
secondary block of DIP Switches and stopped testing the Conventional Memory when
it reached the set amount.
@@ -2280,7 +2285,7 @@ The second difference between the PC/XT Motherboards is the amount of ROM memory
in the Motherboard itself. The 64KB - 256KB Motherboard had just two ROM chips,
a 32 KiB one and a 8 KiB one, that were mapped matching their contents expected
position in the IBM PC 5150. The 32 KiB ROM chip one included the full contents
-of the 8 KiB BIOS, while the 32 KiB of the IBM Cassette BASIC were splitted and
+of the 8 KiB BIOS, while the 32 KiB of the IBM Cassette BASIC were split and
spanned the remaining 24 KiB of the 32 KiB ROM chip and the entirety of the 8
KiB ROM chip. In total that makes for 40 KiB worth of ROM, which remains
unchanged from the IBM PC 5150 (If you don't count the IBM PC obscure optional 8
@@ -2295,7 +2300,7 @@ problem since no PC/XT version had such empty ROM socket at all).
The later 256KB - 640KB Motherboard instead used two 32 KiB ROM chips with the
same basic arrangement, but it had a new BIOS version that was extended using
the extra 24 KiB ROM space in the second ROM chip (For a total of 32 KiB for the
-BIOS, that now was noncontiguously splitted among both ROM chips, and a total of
+BIOS, that now was non-contiguously split among both ROM chips, and a total of
64 KiB ROM memory, fully making use of the extended 64 KiB for Motherboard ROMs
in the PC/XT Memory Map), so those 24 KiB of the address range weren't wasted
mapping nothing anymore. The bigger BIOS included support for a few new Devices
@@ -2307,7 +2312,7 @@ two 32 KiB ROMs of the 1986 BIOS, as the second socket was compatible with both
8 KiB and certain 32 KiB ROM chips. As even more trivial info, both Motherboards
had a Jumper that allowed to disable the two ROM Sockets in case that you wanted
to have an expansion card with ROMs mapped there (As you couldn't bypass the
-8088 CPU hardcoded requeriments for bootstrapping, this means that the Firmware
+8088 CPU hard-coded requirements for bootstrapping, this means that the firmware
was external since it would be located in an expansion card).
[motherboarddiag]: http://www.minuszerodegrees.net/5160/misc/5160_motherboard_diagrams.htm
@@ -2331,23 +2336,23 @@ address range. The HDC and HD used the ST-506 interface, which became the
standard for the IBM PCs and compatibles.
The PC/XT also introduced a new version of PC DOS, 2.0. The new OS included a
-lot of new features, like native support for Hard Diskses (The FAT12 File System
+lot of new features, like native support for Hard Disks (The FAT12 File System
received some minor modifications to make it usable in them. Besides reading and
writing to a HD, PC DOS 2.0 could also be installed and booted from one), the
introduction of directories (PC DOS 1.0/1.1 had no such concept, all the files
were found in the root of the Drive. This also required changes to the way that
-FAT12 stored metadata in the disk media), a standarized interface for loadable
+FAT12 stored metadata in the disk media), a standardized interface for loadable
Device Drivers (PC DOS 1.0/1.1 had no concept of loadable Drivers, either, the
closest thing to that was to hack the OS itself to add the required
-functionality. This was the case with the pre-PC/XT third party Hard Diskses,
-they directly modified PC DOS 1.0/1.1), and support for TSR (Terminate and Stay
+functionality. This was the case with the pre-PC/XT third party Hard Disks, they
+directly modified PC DOS 1.0/1.1), and support for TSR (Terminate and Stay
Resident) applications. PC DOS 2.0 also had several major improvements to DOS
subsystems that began to make it look like a minimalistic but real OS, compared
to the ultra primitive PC DOS 1.0.
The enormous amount of space that HDs were capable of (10 MB was a lot in 1983)
required new forms of data organization. While it should have been possible to
-have a simple booteable VBR (Volume Boot Record) in the first sector of the HD
+have a simple bootable VBR (Volume Boot Record) in the first sector of the HD
like it was done with Diskettes, that would have been quite suboptimal
(Ironically, today that is often done with USB Flash Drives and external HDs.
Formatting them that way is known as Superfloppy). The problem was that at the
@@ -2369,17 +2374,17 @@ native environments.
When a HD is partitioned using the MBR scheme, the first sector (512 Bytes) of
the HD contains the MBR itself. The MBR has executable code similar in nature to
-a booteable VBR, but it also contains a Partition Table that defines the start
+a bootable VBR, but it also contains a Partition Table that defines the start
and end of up to 4 partitions (Later known as Primary Partitions). Each
partition could be formatted with a different File System, and it could also
-have its own booteable VBR in the first sector of the partition. A major
+have its own bootable VBR in the first sector of the partition. A major
limitation of the MBR is that only one of those partitions could be flagged as
-booteable (Also known as Active Partition) at a given time, and the MBR would
+bootable (Also known as Active Partition) at a given time, and the MBR would
always load only that one. In order to boot an OS installed in another
partition, you had to use disk tools that allowed you to set that partition
-booteable flag. Luckily, it was also possible to implement right after loading
-an Active Partition VBR a Boot Loader that had chain loading capabilities (Known
-as Boot Manager), so that it could load the VBR of another partition to boot
+bootable flag. Luckily, it was also possible to implement right after loading an
+Active Partition VBR a Boot Loader that had chain loading capabilities (Known as
+boot manager), so that it could load the VBR of another partition to boot
whatever OS was in it.
Booting an OS from a HD wasn't complicated, instead, it was actually absurdly
@@ -2387,11 +2392,11 @@ linear in nature. The BIOS had absolutely no knowledge of Partitions or File
Systems, the only thing it knew how to do was to read the first sector of the
HD, which is where the MBR is found. Thus, after the BIOS POSTed, it would
instinctively read the MBR, then the MBR in turn would load the VBR of the
-partition flagged as booteable, and it could either bootstrap the rest of the
-OS, or have a Boot Manager that could chain load another VBR so that you could
-boot to another OS. When there are more that one HD in the same computer, it is
+partition flagged as bootable, and it could either bootstrap the rest of the OS,
+or have a boot manager that could chain load another VBR so that you could boot
+to another OS. When there are more that one HD in the same computer, it is
possible to tell the BIOS which HD you want to read the MBR first from. This is
-essencially how booting from a Hard Disk (Including Dual Boot) worked during the
+essentially how booting from a Hard Disk (Including Dual Boot) worked during the
next 30 years.
As some anecdotal experiences, perhaps you remember that during the long Windows
@@ -2406,9 +2411,9 @@ since it didn't seem that any particular file managed that.
For example, at some point I wanted to have a Windows 95 and Windows XP Dual
Boot. The first time I tried to do it, I installed W95 to an empty, unformatted
-partition in a HD that already had a NTFS partition with a booteable WXP. The
-W95 installer formatted the empty partition with FAT16 and installed W95 there,
-but after that, I couldn't get WXP to boot again. I found no way to make the
+partition in a HD that already had a NTFS partition with a bootable WXP. The W95
+installer formatted the empty partition with FAT16 and installed W95 there, but
+after that, I couldn't get WXP to boot again. I found no way to make the
computer remember that it previously had WXP installed, it felt like its
existence went entirely ignored. I moved the HD to another computer, and found
that the WXP partition data was still there and intact (The data was not visible
@@ -2418,19 +2423,19 @@ any way of fixing things other that reinstalling Windows, I decided to start
over by installing W95 first then WXP, and that worked (At a cost of some hours
of work and a lot of lost settings). I figured out that later Windows versions
were intelligent enough to scan the other partitions looking for previous
-Windows installations, and automatically builded a Boot Manager so that you
-could choose which Windows installation you wanted to boot. However, Windows
-ignored any other unsupported OSes (Including newer Windows versions) when
-building the list of OSes for the Boot Manager, which is also why it was
-suggested to always install Linux after Windows. Not much later, I also had
-issues with computers with two HDs where a Windows installation in the second HD
-becomes unbooteable if the first HD is removed, something that made absolutely
-no sense since Windows had no reason to use the other HD at all. Just in case, I
-decided to always install Windows with only one HD plugged in the computer, then
-plugging the second one after finishing the Windows install process. Some time
-later I finally learned why that happened: Windows could write in the MBR of one
-HD to try to load a VBR found in another HD, forcing you to have both HDs unless
-you manually fix this.
+Windows installations, and automatically built a boot manager so that you could
+choose which Windows installation you wanted to boot. However, Windows ignored
+any other unsupported OSes (Including newer Windows versions) when building the
+list of OSes for the boot manager, which is also why it was suggested to always
+install Linux after Windows. Not much later, I also had issues with computers
+with two HDs where a Windows installation in the second HD becomes unbootable if
+the first HD is removed, something that made absolutely no sense since Windows
+had no reason to use the other HD at all. Just in case, I decided to always
+install Windows with only one HD plugged in the computer, then plugging the
+second one after finishing the Windows install process. Some time later I
+finally learned why that happened: Windows could write in the MBR of one HD to
+try to load a VBR found in another HD, forcing you to have both HDs unless you
+manually fix this.
All these things began to make sense after I finally understood the root cause:
There is a high amount of manipulation that the MBR and VBRs silently suffers
@@ -2440,10 +2445,10 @@ exists on the physical disk, just that it is outside of any File System
boundaries. The Windows installers always ask you in what partition you want to
install Windows, but probably in the name of user friendliness, they always hide
the low level details of what modifications they do to the MBR and VBRs of any
-connected HDs, causing unnecessary chaos with no justificable reason. With
-proper knowledge and specialized tools to repair the MBR and VBRs, fixing my
-issues should have been rather easy, but sadly, I didn't had them back then. I
-just learned about both how simple booting is and how much of a mess the Windows
+connected HDs, causing unnecessary chaos with no justifiable reason. With proper
+knowledge and specialized tools to repair the MBR and VBRs, fixing my issues
+should have been rather easy, but sadly, I didn't had them back then. I just
+learned about both how simple booting is and how much of a mess the Windows
installers can make by reading Linux distributions installation instructions.
Something similar happens when people talks about their "C" and "D" Drives when
actually the letter is just a Windows nomenclature for a mapped partition that
@@ -2458,7 +2463,7 @@ The clone manufacturers didn't stand still after being able to legally clone the
original IBM PC. As you could expect, they continued to chase from behind IBM
and its newest computer. While I'm not exactly sure about specific dates
(Someone that wants to crawl old computer magazines looking for era appropriate
-announcements or advertisements may be able to make such a list), the timeframe
+announcements or advertisements may be able to make such a list), the time frame
for the debut of the first PC/XT clones (NOT the PC-likes) should have been
around one year after the IBM PC/XT launch, which means that they should have
been available in the market just in time to meet the new IBM PC/AT. However,
@@ -2493,11 +2498,11 @@ V20 CPU, released in 1982. IBM wasn't the only major manufacturer that had
products reverse engineered, cloned, and improved upon, the Intel 8088 CPU had
become popular enough to guarantee such treatment, too. The NEC V20 was an
impressive chip: It was around 5% faster than the Intel 8088 CPU at the same
-clock speed (Theorically, with code optimized specifically for it, it could be
+clock speed (Theoretically, with code optimized specifically for it, it could be
much faster, but in practice, V20 optimized code was extremely rare), supported
the new x86 instructions introduced by the Intel 80186/80188 CPUs along with
some custom NEC ones, had a mode that emulated the old Intel 8080 CPU that could
-be used by Software emulators to run 8080 based 8 Bits CP/M applications without
+be used by software emulators to run 8080 based 8 Bits CP/M applications without
needing a dedicated card (The NEC V20 did not emulated the popular Zilog Z80
enhancements made to the Intel 8080 ISA, applications that used these didn't
work), and, best of all, remained pin compatible with the 8088. There were some
@@ -2521,7 +2526,7 @@ clone Motherboard that actually implemented the IBM PC/XT Slot 8 behavior.
[expansionreset]: https://books.google.com/books?id=25_xnJJJmvgC&lpg=PP1&pg=PA419#v=onepage&q&f=false
-##### 3.4 - The first Turbo XTs, Hardware requeriments and changes to Clock Generation
+##### 3.4 - The first Turbo XTs, Hardware requirements and changes to Clock Generation
By 1985, the PC/XT clone computers were reaching maturity level. While by that
point IBM had already greatly extended the PC platform with their latest
@@ -2548,7 +2553,7 @@ basic PC/XT designs. This new class of PC/XT clones became known as Turbo XTs.
If you were to compare the Turbo XTs with the earlier PC-like computers that
were faster than the IBM PC, the main difference is that a PC-like was at best
just partially compatible with the PC platform, whereas a Turbo XT uses it as a
-base thus compatibility is far better with both its Software and its expansion
+base thus compatibility is far better with both its software and its expansion
cards.
As the Turbo XTs were going beyond the capabilities of the system that they were
@@ -2610,9 +2615,9 @@ time, which means that the PIT would count the same amount of clock cycles at a
faster rate, or, in other words, completing a count in a shorter period of real
time. This directly translates in that anything that used the PIT to track time
would be unaware that it is actually going faster than real time. While it may
-be possible to workaround this issue at the Firmware level by enhancing the BIOS
+be possible to workaround this issue at the firmware level by enhancing the BIOS
Services to be aware that now a real time second could be worth a varying amount
-of clock cycles, Software that directly programmed the PIT would assume the
+of clock cycles, software that directly programmed the PIT would assume the
standard IBM timings and misbehave as a result. As such, the PIT input clock had
to be fixed to 1.19 MHz for compatibility reasons, and compared to the CGA
issue, this one was completely unavoidable if you were making an IBM PC
@@ -2647,7 +2652,7 @@ rated one would go up to 5 MHz and was already in use by the original IBM PC.
I'm not sure if the other manufacturers made faster ones, or if the 5 MHz parts
had to be individually tested to make sure than the overclock was stable). As
support chips were built-in in the Motherboard itself, there was no reason to
-worry too much about them as it was the responsability of the Motherboard (Or
+worry too much about them as it was the responsibility of the Motherboard (Or
computer) manufacturer to make sure than if it is selling a Turbo XT Motherboard
that officially supports running at 8 MHz, all its components can actually work
at that clock speed, so I would take as granted that everything soldered was
@@ -2677,20 +2682,20 @@ been true in 1985 when the IBM PC was still common, but after it became
obsolete, many newer cards that worked in faster platforms and were physically
compatible with the IBM PC I/O Channel Slots would not work in it at all). Some
early IBM PC cards were unable to work reliably at higher clock speeds, yet it
-should be safe to assume that era appropiated cards should have consistently
+should be safe to assume that era appropriate cards should have consistently
worked @ 8 MHz at a minimum, as otherwise, without a good source of usable
expansion cards, the Turbo XT platforms would have been completely useless.
Regardless, if you were purchasing an entire Turbo XT computer, the
-responsability to test the bundled expansion cards to make sure that they were
+responsibility to test the bundled expansion cards to make sure that they were
capable of reliably working @ 8 MHz or higher was of the system builder.
In order to have a higher degree of compatibility with expansion cards, some
-Turbo XT Motherboards had Firmwares whose BIOS Services did their expected
+Turbo XT Motherboards had firmwares whose BIOS Services did their expected
function, but also executed some redundant code that served to add extra delay
-after I/O accesses, as a sort of artificial Software based Wait State
+after I/O accesses, as a sort of artificial software based Wait State
(Basically, it was like a NOP Instruction, but done with a sort of dummy code
instead of a real NOP, apparently because the NOP added more delay than needed).
-The problem with this approach was that these Software Wait States were not
+The problem with this approach was that these software Wait States were not
universal, as applications that accessed the Hardware directly instead of using
the BIOS Services would completely bypass this workaround. An alternative that
was technically possible but that I failed to find examples of, is a Turbo XT
@@ -2699,25 +2704,25 @@ valid value), as that would have been an universal solution. You can read more
in-depth info about this topic in [this Thread][8088iodelays], so you can have a
grasp of how complex it was to deal with this.
-I'm rather clueless regarding how expansion card compatibility issues were
-dealed with back in the day. It seems that it was impossible to know ahead of
-time if a particular expansion card would work in a specific Turbo XT computer
-without testing it first, given the high amount of platform variety and that
-there was nothing standarized above the IBM PC capabilities. Moreover, 8, 10 and
-12 MHz platforms had a vastly different difficulty scale (8 was standard, 10 may
-have required stability testing, and 12 should have been on the borderline of
-the possible and thus require handpicking the cards). As even back in the day
-there were Hardware enthusiast communities, I would expect that there was a lot
-of informal knowledge regarding if a particular card model could consistently
-work at higher speeds, as if we were talking about the modern day "average
-overclock" (The clock speed that almost all chips of a given type can
-consistently get to). 12 MHz ended up being a clock speed wall for the I/O
-Channel Bus, which eventually forced the decoupling of the Processor from the
-Bus so that the CPU clock speed could be increased independently, without being
-burdened by the slower Bus and everything in it. As far that I know, no Turbo XT
-Motherboard tried to decouple them, it took until the Turbo AT platforms from
-IBM PC compatible manufacturers to begin the decoupling, and they finally became
-fully asynchronous when the I/O Channel Bus was standarized as ISA in 1988.
+I'm rather clueless regarding how expansion card compatibility issues were dealt
+with back in the day. It seems that it was impossible to know ahead of time if a
+particular expansion card would work in a specific Turbo XT computer without
+testing it first, given the high amount of platform variety and that there was
+nothing standardized above the IBM PC capabilities. Moreover, 8, 10 and 12 MHz
+platforms had a vastly different difficulty scale (8 was standard, 10 may have
+required stability testing, and 12 should have been on the borderline of the
+possible and thus require handpicking the cards). As even back in the day there
+were Hardware enthusiast communities, I would expect that there was a lot of
+informal knowledge regarding if a particular card model could consistently work
+at higher speeds, as if we were talking about the modern day "average overclock"
+(The clock speed that almost all chips of a given type can consistently get to).
+12 MHz ended up being a clock speed wall for the I/O Channel Bus, which
+eventually forced the decoupling of the Processor from the Bus so that the CPU
+clock speed could be increased independently, without being burdened by the
+slower Bus and everything in it. As far that I know, no Turbo XT Motherboard
+tried to decouple them, it took until the Turbo AT platforms from IBM PC
+compatible manufacturers to begin the decoupling, and they finally became fully
+asynchronous when the I/O Channel Bus was standardized as ISA in 1988.
[8088iodelays]: http://www.vcfed.org/forum/showthread.php?45197-IO-Delays-on-8088-class-computers
@@ -2728,13 +2733,13 @@ While everything mentioned previously was pretty much the bare minimum required
from the Hardware perspective for a functional Turbo XT computer, there were
still several compatibility issues left to deal with. A lot of applications,
mainly games, didn't followed IBM best programming practices of using the PIT
-for timming purposes, instead, they used loops. The faster the Processor was,
+for timing purposes, instead, they used loops. The faster the Processor was,
the faster the loop would complete, the faster the game would run. This was
pretty much an almost identical situation than what happened with the PIT, with
the major difference being that increasing the PIT clock speed didn't increased
system performance, so there was no real reason to clock it higher, but that
wasn't the case with the CPU. It seems like developers didn't expected that
-their Software could run in any other IBM PC compatible system with a CPU clock
+their software could run in any other IBM PC compatible system with a CPU clock
speed other than 4.77 MHz. Dealing with this compatibility issue required yet
another solution: Selectable Frequency. This feature would be known as Turbo.
Turbo is pretty much what differentiates the Turbo XTs from earlier PC-likes
@@ -2746,39 +2751,39 @@ the Computer Case known as the Turbo Button, that was plugged into a header in
the Motherboard (Technically it is the third member of the Motherboard Front
Panel Headers, albeit by the year 2000 it was already extinct). Its function was
to select between two Frequencies: The clock speed that the platform nominally
-supported, and a 4.77 MHz one that provided compatibility with Software tuned
+supported, and a 4.77 MHz one that provided compatibility with software tuned
for the speed of the IBM PC. The switch worked by selecting which would be the
reference clock source for the derived CLK line. In platforms with two Crystal
Oscillator and Clock Generator pairs, it was rather easy for the 14.31 MHz
crystal already in place for the PIT and CGA to also happily derive the 4.77 MHz
CLK line in the same way that it was done in the IBM PC, while in the simpler
design with one crystal and CG pair, the switch could be used to bypass the
-clock doubling circuit. Essencially, this means that a Turbo XT platform had two
+clock doubling circuit. Essentially, this means that a Turbo XT platform had two
operating modes: An IBM PC clone mode that should in theory behave identical to
an IBM PC or PC/XT and thus work with applications bound to the 4.77 MHz 8088
CPU speed (And even allowing to work older expansion cards), and a faster IBM PC
compatible mode for everything else.
-Other Turbo implementations allowed for Software control of the clock speed. It
-was possible to run an executable file with appropiate parameters to change the
+Other Turbo implementations allowed for software control of the clock speed. It
+was possible to run an executable file with appropriate parameters to change the
clock speed, or a DOS TSR (Terminate and Stay Resident) Driver that could do so
by pressing a Key Combination similar to Ctrl + Alt + Del to dynamically switch
clock speeds on the fly, even when an application was running. I'm not sure if
-they called a custom BIOS Service of that Motherboard Firmware, or if they
+they called a custom BIOS Service of that Motherboard firmware, or if they
interfaced with the clock source switching circuitry directly, both could be
-possible. I wouldn't be surprised either if there was a pure Firmware side
+possible. I wouldn't be surprised either if there was a pure firmware side
implementation that could do on the fly clock switching with a Key Combination
in the same way than Ctrl + Alt + Del, without wasting Conventional Memory in a
TSR Driver. I'm also aware that some platforms had higher granularity and could
select between multiple speeds, but I'm not sure what Clock Generation scheme
-they used to achieve that (It may be possible that they were entirely Software
+they used to achieve that (It may be possible that they were entirely software
Wait States, too).
-The switcheable clock scheme uncovered yet another issue: If an application was
+The switchable clock scheme uncovered yet another issue: If an application was
running when you switched the clock source, chances are that it crashed. This
typically didn't happened if you were at the DOS Command Prompt when you
switched the Turbo status, but applications like games were not happy, though
-each piece of Software had its own degree of sensitivity. As the Turbo XT
+each piece of software had its own degree of sensitivity. As the Turbo XT
platforms matured, newer designs allowed for better clock switching circuitry
that could make dynamic switching as seamless as possible, so that you could
turn on or off Turbo while applications were running without getting them to
@@ -2793,13 +2798,13 @@ switching right.
And yet another compatibility issue that was uncovered by running at high
Frequencies, is that the 8237A DMAC tended to be very problematic. This is not
surprising since they usually were 5 MHz models with a severe overclock. Some
-Turbo XT platforms had Firmwares that could dynamically switch the CLK line to
-4.77 MHz everytime that there was a DMA access going on. Assuming that the
+Turbo XT platforms had firmwares that could dynamically switch the CLK line to
+4.77 MHz every time that there was a DMA access going on. Assuming that the
platform had mastered the seamless dynamic clock speed switching, this would
have been entirely possible to do, yet it doesn't explain how it was supposed to
work with applications that programmed the DMAC directly instead of going
through the BIOS Services (Identical situation than for anything else that
-directly interfaced with the Hardware. This includes bypassing the Software I/O
+directly interfaced with the Hardware. This includes bypassing the software I/O
Wait States added by BIOS Services for expansion cards, and being the reason why
the PIT has to run at exactly 1.19 MHz). I don't really know the details or
specific platform implementations, just some comments that seems to point that
@@ -2813,11 +2818,11 @@ that automatically downclocked to 4.77 MHz were all based on Chipset designs
instead of discrete chips like the early Turbo XT platforms. However, is unfair
to directly compare those late Chipset based Turbo XT platforms against the
early ones made out of discrete support chips since they are not at the same
-maturity level, and Chipsets allowed a platform to do many tricks that would
+maturity level, and chipsets allowed a platform to do many tricks that would
require a lot of custom circuitry to implement with individual support chips.
-Very late Turbo XTs were made using Chipsets instead of discrete support chips.
-I prefer to cover Chipsets after the IBM PC/AT generation since the first ones
+Very late Turbo XTs were made using chipsets instead of discrete support chips.
+I prefer to cover chipsets after the IBM PC/AT generation since the first ones
seems to have targeted PC/AT compatibility, not PC, so chronologically speaking,
Chipset based Turbo XT platforms appeared after the PC/AT ones. Chipset based
platforms had slightly different Clock Generation schemes, since the Chipset
@@ -2844,20 +2849,20 @@ not an 8088. You could pick an 8088, make it run @ 4.77 MHz, and get a CPU with
identical compatibility and accuracy than the 8088 in the IBM PC, while an 8086
had no real chance to perform identical to an 8088 (The same applies to the NEC
V20, but you could swap it for an 8088 without needing another Motherboard). As
-such, only the 8088 based Turbo XT platforms were theorically capable of
+such, only the 8088 based Turbo XT platforms were theoretically capable of
matching the original IBM PC compatibility level while also having the
capability to offer more performance in Turbo mode. I don't know specific edge
cases where the 8086 had worse compatibility than the 8088, but chances are that
like always, games and copy protection schemes were involved. Still, it didn't
make a lot of sense to use more expensive parts to make a less compatible
-computer. Only after mainstream Software learned to properly behave regardless
+computer. Only after mainstream software learned to properly behave regardless
of the speed of the Processor there was a dramatic increase in x86 Processors
variety, but by then, the PC based platforms were almost extinct.
The last fresh breath of the PC platform would be in April 1987, when IBM
revived it for the entry level Model 25 and 30 of the PS/2 line, but I prefer to
talk about them in their own section since it will be easier to digest if going
-through the PC/AT and Chipsets first. Ironically, the mentioned PS/2 models are
+through the PC/AT and chipsets first. Ironically, the mentioned PS/2 models are
8086 based, not 8088. As amusing as it sounds, IBM own PS/2 line was less IBM PC
compatible than many of the Turbo XT ones...
@@ -2884,12 +2889,12 @@ failure of the iAPX 432.
The PC/AT is historically significant because it is the last common ancestor
that all modern x86 platforms have. In the original IBM PC era, after the
-overwhelming difference that the IBM PC huge Software ecosystem made became
+overwhelming difference that the IBM PC huge software ecosystem made became
evident, everyone ended up following IBM de facto platform leadership, which
served as a sort of unifying force. This can be clearly seen in how the first
generation of non-IBM x86 based computers, the PC-likes, that were similar to
the IBM PC but only partially compatible with it, got followed by a second
-generation of systems, known as clones, that strived to be fully compatible with
+generation of systems, known as clones, that strove to be fully compatible with
the IBM PC platform. The PC/AT era was similar, but in reverse: At first,
everyone followed IBM leadership with a first generation of computers that were
mere PC/AT clones, followed by a second generation where the top IBM PC
@@ -2903,7 +2908,7 @@ popular enough to be adopted by everyone else. Yet, the base PC/AT compatibility
was never compromised, as the new platform features were always added as a sort
of superset of the existing PC/AT platform (And, by extension, the PC),
requiring to be explicitly enabled by the OS or a Driver. Basically, until UEFI
-based Motherboard Firmwares became mainstream around 2012, x86 based computers
+based Motherboard firmwares became mainstream around 2012, x86 based computers
always booted as PC/AT compatible computers with the Processor running in Real
Mode (8086/8088 level ISA behavior and features). Everything else was built on
top of that.
@@ -2928,7 +2933,7 @@ Finally, there was a little known model, the IBM PC/XT 5162 (Model 286), that is
usually considered part of the PC/AT family, since despise being branded as a
PC/XT, it was fully based on the PC/AT platform. The PC/XT 5162 used a different
Motherboard that was smaller than the PC/AT 5170 Type 2/3 and functionally
-slighty different, but otherwise PC/AT compatible.
+slightly different, but otherwise PC/AT compatible.
[5170techref]: http://www.minuszerodegrees.net/manuals/IBM_5170_Technical_Reference_1502243_MAR84.pdf
@@ -2948,7 +2953,7 @@ and the dedicated lines.
Internally, the 80286 had a plethora of new features, the major ones being the
introduction of an integrated MMU (Memory Management Unit), and a new operating
-mode, Protected Mode, to make use of it. Lesser features included Hardware Task
+mode, protected mode, to make use of it. Lesser features included Hardware Task
Switching and some new instructions. Ironically, all of these features would be
barely used during most of the useful lifetime of the PC/AT. The saving grace of
the 80286 was simply that it had a faster execution unit than any of the
@@ -2957,11 +2962,11 @@ machine code than the 8088, making it perform much better than it even if it
were to be running at the same clock speed. This ended up being the 286 biggest,
and almost sole, selling point for the average user.
-The MMU is a dedicated Coprocessor that is used by OSes that implements Virtual
+The MMU is a dedicated Co-processor that is used by OSes that implements Virtual
Memory to offload the dynamic translation of Virtual Addresses to Physical
Addresses, dramatically reducing the overhead compared to doing so purely in
-Software (Something that was done experimentally in other platforms before the
-MMUs came into existence. I'm not entirely sure if someone tried a Software only
+software (Something that was done experimentally in other platforms before the
+MMUs came into existence. I'm not entirely sure if someone tried a software only
implementation of Virtual Memory for the original IBM PC platform, but good
candidates would be the Microsoft Xenix ports for it, which are not to be
confused with the ports for the PC/AT). I suppose that you also want to know
@@ -2972,7 +2977,7 @@ exclusive Virtual Address Space.
In a platform without support for Virtual Memory or any other type of Memory
Protection, like the original IBM PC, the OS and all applications being run sees
-and shares the same Physical Address Space. This essencially means that any code
+and shares the same Physical Address Space. This essentially means that any code
being executed can potentially read or write directly to any address. In that
environment, creating an OS with Multitasking capabilities was very hard, since
it required that all user applications were aware that not all the visible
@@ -2996,7 +3001,7 @@ themselves, the OS has full control of the Memory Management, allowing for
easier implementations of Memory Protection and thus Multitasking. It also
simplifies applications themselves, as they can all assume that all usable
memory is contiguous, completely forgetting about gaps or holes (Remember the
-first IBM PC BIOS version supporting noncontiguous memory?). Finally, Virtual
+first IBM PC BIOS version supporting non-contiguous memory?). Finally, Virtual
Memory also allows for Swap File or Page File implementations, which is when you
use a file or partition in standard storage media to hold contents of data that
an application believes to be in the system RAM, a technique that was widely
@@ -3011,7 +3016,7 @@ Segmented Memory Model scheme, which I like to call Segmented Virtual Memory.
Like the 8086/8088, the 286 was a 16 Bits Processor with a Physical Address
Space larger than what the value of a single 16 Bits GPR could address, so it
still had to use the Segment and Offset pairs to access an individual address.
-However, in order to accomodate both the larger 24 Bits Physical Address Space
+However, in order to accommodate both the larger 24 Bits Physical Address Space
and the Virtual Memory Address Space that was layered on top of it, the Segment
and Offset pair had a different meaning in the 286 compared to the way that they
worked in the 8086/8088.
@@ -3049,44 +3054,44 @@ if using adequate granularity. The whole Virtual-to-Physical translation added
extra complexity that incurred in some overhead even when having a MMU to
offload it, however.
-The other major feature of the 80286 was the introduction of Protected Mode. As
+The other major feature of the 80286 was the introduction of protected mode. As
the new meaning of the Segment and Offset pair changed a very basic behavior of
how addressing worked in the x86 ISA, all preexisting code would be pointing to
incorrect addresses. As such, in order to remain Binary Compatible with
executable code intended for the 8086/8088 and 80186/80188 CPUs addressing
style, most of the 286 new functionality required to be explicitly enabled by
-setting the CPU to operate in the new Protected Mode. The 286 itself started in
+setting the CPU to operate in the new protected mode. The 286 itself started in
a mode now known as Real Mode, where the Segment and Offset pair (And several
more things, but not all) behaved like in the previously mentioned older
-Processors. Switching the 286 to Protected Mode was a prerequisite to use both
+Processors. Switching the 286 to protected mode was a prerequisite to use both
the 16 MiB Physical Address Space and the MMU, otherwise, the 80286 would behave
-just like a faster 8086 and barely anything else. When in Protected Mode, all
+just like a faster 8086 and barely anything else. When in protected mode, all
addressing was processed by the MMU Segmentation Unit even if not using Virtual
Memory, Memory Protection or such, causing some performance overhead when
compared to Real Mode.
-Though PC DOS/MS-DOS itself didn't used Protected Mode, DOS applications had
+Though PC DOS/MS-DOS itself didn't used protected mode, DOS applications had
full control of the computer and could do so if they wanted, something that made
sense for any application that was constrained by the 640 KiB Conventional
Memory barrier. There was a problem with this approach, which is that the BIOS
Services (Including those added by expansion cards Option ROMs) and the DOS
-System Calls couldn't be used from within Protected Mode, as all existing code
+System Calls couldn't be used from within protected mode, as all existing code
assumed Real Mode addressing style. That is where a major limitation than the
-286 Protected Mode had became very noticeable: There was no way for Software to
-return to Real Mode after enabling Protected Mode. Intel idea was that a new
+286 protected mode had became very noticeable: There was no way for software to
+return to Real Mode after enabling protected mode. Intel idea was that a new
generation of OSes and applications relied exclusively on the new feature, not
for it to be used as a mere extension that a lone application could enter and
exit at will.
As the primitive PC DOS was the most common OS in use and there was no
-mainstream Protected Mode successor on the horizon, not being able to return to
+mainstream protected mode successor on the horizon, not being able to return to
Real Mode on demand to use the DOS API was a rather harsh limitation. Without
-proper OS support, any standalone application that wanted to use Protected Mode
-would have to reimplement everything on its own, massively bloating the
+proper OS support, any standalone application that wanted to use protected mode
+would have to re-implement everything on its own, massively bloating the
application and making the development process far more complex. As such, a
-commercial DOS application that used the pure form of the 286 Protected Mode
+commercial DOS application that used the pure form of the 286 protected mode
should be very rare, I'm not even aware if one existed at all. The only example
-that I know that did used in the IBM PC/AT the pure 286 Protected Mode as Intel
+that I know that did used in the IBM PC/AT the pure 286 protected mode as Intel
envisioned, is an OS and all its native applications: The UNIX-based
[IBM PC XENIX][ibmpcxenix], which IBM licensed from Microsoft and was released
less than a year after the PC/AT. However, Xenix was always aimed at the high
@@ -3096,19 +3101,19 @@ supreme among average users. One can wonder how different history would be if
IBM decided to push Xenix instead of PC DOS back when it had undisputed control
of the PC platform...
-From the minor features of the 80286, a rather interesing yet mostly unknow one
-is Hardware Task Switching, something that Intel should have included expecting
-it to be useful for Multitasking OSes. Using this feature had a few
+From the minor features of the 80286, a rather interesting yet mostly unknown
+one is Hardware Task Switching, something that Intel should have included
+expecting it to be useful for Multitasking OSes. Using this feature had a few
disadvantages, the most surprising one being that doing Task Switching using the
built-in Hardware support was usually slower than doing Context Switching fully
-in Software. As such, the Hardware Task Switching function of x86 Processors
+in software. As such, the Hardware Task Switching function of x86 Processors
ended up being a completely unused feature. Actually, while it is still
supported by modern x86 Processors for backwards compatibility purposes, it
can't be used while running in Long Mode (64 Bits), effectively making this
feature obsolete.
The other minor feature is that the 80286 added some new instructions to the x86
-ISA, albeit most of them deal with Protected Mode Segmentation thus they were
+ISA, albeit most of them deal with protected mode Segmentation thus they were
not very useful. Also, as the introduction of new instructions works mostly in a
cumulative way since a new Processor typically has all the instructions of the
previous ones based on the same ISA, the 80286 included the instructions
@@ -3117,16 +3122,16 @@ V20/V30 custom instructions, making them exclusive to NEC x86 ISA extension and
thus short lived.
Deploying the Intel 80286 CPU required a few new support chips that were
-superceding versions of the 8086 ones. The 286 was intended to use the Intel
+superseding versions of the 8086 ones. The 286 was intended to use the Intel
82288 Bus Controller instead of the 8288 (Furthermore, there was no Minimum Mode
that I'm aware of like with the 8086/8088, so you always required the Bus
Controller), and the Intel 82284 Clock Generator instead of the 8284A. On the
-Coprocessor front, the 80287 FPU succeded the 8087. However, at its core, the
+Co-processor front, the 80287 FPU succeeded the 8087. However, at its core, the
80287 was an 8087 and performed like it, Intel just upgraded the external Bus
interface to make it easy to wire to the new 286 CPU but otherwise didn't
-improve the actual FPU. Interesingly, the 80287 had pretty much no formal
+improve the actual FPU. Interestingly, the 80287 had pretty much no formal
external Address Bus, just a Data Bus. A successor to the 8089 IOP was never
-developed, making that Coprocessor ISA a dead end.
+developed, making that Co-processor ISA a dead end.
[ibmpcxenix]: http://www.os2museum.com/wp/ibm-pc-xenix/
@@ -3141,16 +3146,16 @@ IBM PC applications (Keep in mind than when the IBM PC/AT was released, there
were already a few PC-likes that were faster than the IBM PC and could run many
applications, but compatibility was usually mediocre. And the PC/AT 80286 CPU @
6 MHz was quite faster anyways). What made the 80286 perform better is that it
-took significantly less clock cycles to process the same machine code (Opcodes)
+took significantly less clock cycles to process the same machine code (opcodes)
than the 8088, making the 80286 able to execute more instructions in the same
time frame and thus perform faster even if it was running at the same clock
-speed than the 8088. This is also the case of the NEC V20, it was slighty faster
-than the 8088 because it also took less clock cycles to process the same machine
-code, but the difference was rather small and pales in comparison to how faster
-the 80286 was.
+speed than the 8088. This is also the case of the NEC V20, it was slightly
+faster than the 8088 because it also took less clock cycles to process the same
+machine code, but the difference was rather small and pales in comparison to how
+faster the 80286 was.
In general, there are only two viable ways to increase compute performance for
-existing Software: The first is to run the same Processor at faster clock
+existing software: The first is to run the same Processor at faster clock
speeds, which is what the Turbo XT platforms did with their 8088s running at 8
or 10 MHz. The other is to design a Processor that can execute the same machine
code in a more efficient manner thus making it faster, like the Intel 80286 and
@@ -3170,7 +3175,7 @@ instruction isn't an uniform fixed value, instead, it depends on the machine
code that it produces (An instruction can produce one or multiple opcodes) and
the context of the operation itself. In the old days, the execution latency of
an instruction in a specific context was pretty much
-[a known fixed contant value][pentiuminstrset], as the Processors were rather
+[a known fixed constant value][pentiuminstrset], as the Processors were rather
simple and the Memory subsystem predictable. In the case of modern Processors,
it takes a lot of work to get the exact execution latency of an instruction
because there are a ridiculous amount of variables at play (Multiple Cache
@@ -3180,9 +3185,8 @@ Fusion, resource sharing due to Simultaneous MultiThreading, variable Memory
subsystem latency, etc) that makes for an almost infinite amount of contexts, so
at most, you may get an average value that speaks more about the efficiency of
the Processor as a whole rather than of the execution unit as an isolated
-entity. As such, theorycrafting what the maximum possible performance of a
-modern Processor is can be much harder, and even more so attemping to get close
-to it.
+entity. As such, theorizing what the maximum possible performance of a modern
+Processor is can be much harder, and even more so attempting to get close to it.
Since the execution latency of each instruction and context is different,
optimizations to the execution unit does not produce uniform IPC increases,
@@ -3211,8 +3215,8 @@ perform exactly identical to the 8088. This means that the IBM PC/AT, by design,
was unable to be 100% IBM PC compatible in the most strict sense of that
definition.
-When designing a new Processor, the designers have to face decisitions about
-performance tradeoffs, since they can prioritize to improve the execution unit
+When designing a new Processor, the designers have to face decisions about
+performance trade-offs, since they can prioritize to improve the execution unit
to process the opcodes produced by certain types of instructions faster, but
maybe at the cost of not being able to do so for another type of instructions,
or worse, they could be forced to make these slower compared to its predecessor.
@@ -3224,11 +3228,11 @@ an 8088. However, the execution units of later x86 Processors like the 80386 and
80486 evolved in a radically different way, as they focused in processing as
fast as possible the most commonly used instructions, whereas the less common
ones actually tended to perform worse in each successive generation. This ended
-up causing some issues for the Software developers of the era, since they had to
+up causing some issues for the software developers of the era, since they had to
decide [which Processor they wanted to optimize for][80x86optimizations], almost
always at the detriment of another one.
-Back in the day, optimizing Software was much harder than today. The compilers
+Back in the day, optimizing software was much harder than today. The compilers
of the era were quite dumb and couldn't exploit all the potential of a CISC ISA
like that of the x86 Processors, so for anything that required speed, any
optimization relied on the use of handcrafted x86 Assembler code. At a time
@@ -3246,10 +3250,10 @@ Processors means that the Assembler programmer had to know the idiosyncrasies of
each of those, and would also have to do its job two or more times for each
target, something that was expensive in both cost and time. Moreover, including
multiple code paths (And a way to detect which Processor the computer had, at a
-time where figuring out so was not standarized) or providing different
+time where figuring out so was not standardized) or providing different
executables could increase the application size, something not desirable as
-Diskettes capacities were very small. The end result is that Software developers
-typically choosed a Processor to serve as the lowest common denominator that the
+Diskettes capacities were very small. The end result is that software developers
+typically chose a Processor to serve as the lowest common denominator that the
application was expected to run in, then optimize only for it, letting clock
speed increases handle the potentially lower relative IPC in later Processors.
For example, a programmer during the late 80's could have had two choices: To
@@ -3261,19 +3265,19 @@ cost of being just too slow to be usable enough on the older 80286.
During the next three decades, both Processors and compilers evolved a lot. The
evolution of the x86 execution units, with two notorious exceptions, ended up
-being a sort of a feedback loop: Software developers had to optimize their code
+being a sort of a feedback loop: software developers had to optimize their code
to use whatever the mainstream Processors available at a given moment did
better, then the next generation of Processors focused on doing the same thing
even better than the previous one since that accounted for the majority of code
-already found in the commercial applications reelevant during that era. As such,
+already found in the commercial applications relevant during that era. As such,
modern x86 Processors, in general, benefit roughly from most of the same
optimizations. This also caused an implied chicken-and-egg scenario: Designing a
vastly different execution unit without being able to push around the entire
-Software ecosystem to optimize for what the new Processor did better, would just
+software ecosystem to optimize for what the new Processor did better, would just
give counterproductive performance results that made such Processors look bad.
That is the case of the mentioned two exceptions, as they were Processors that
had extremely different execution units compared to other contemporaneous ones,
-and only shined in very specific circunstances. These two were the relatively
+and only shined in very specific circumstances. These two were the relatively
recent AMD Bulldozer (FX) architecture, which was quite different when compared
to the previous AMD K10/K10.5 (Phenom/Phenom II), Intel Conroe (Core 2 Duo) and
the contemporaneous Intel Nehalem (Core i7 1st generation), and a much more
@@ -3283,22 +3287,21 @@ different when compared to the Intel P6 (Pentium Pro/2/3/M) or AMD K7
Meanwhile, compilers matured enough to almost nullify the gap with handcrafted
Assembler, and also learned how to compile code optimized for each Processor
-architecture. Currently, a programmer only has to focus on writting code that
+architecture. Currently, a programmer only has to focus on writing code that
follows the general optimizations guidelines, then simply offload the Processor
-architecture optimization job to the compiler, which can produce many codepaths
+architecture optimization job to the compiler, which can produce many code paths
or different executable files optimized for each Processor. Actually, modern
compilers are so good that they can produce faster executables than what an
average ASM programmer can do, since the compiler can implement a whole bunch of
-optimizations reelevant in modern Processors that are quite complex for humans
-to do manually. It takes an expert Assembler programmer to attempt to beat a
-modern compiler, and only in very specific niches there will be substantial
-performance differences that makes the effort worth it.
+optimizations relevant in modern Processors that are quite complex for humans to
+do manually. It takes an expert Assembler programmer to attempt to beat a modern
+compiler, and only in very specific niches there will be substantial performance
+differences that makes the effort worth it.
[pentiuminstrset]: https://web.archive.org/web/20140313200414/http://www.cs.dartmouth.edu/~mckeeman/cs48/mxcom/doc/x86.html
[80x86optimizations]: http://archive.gamedev.net/archive/reference/articles/article369.html
-
##### 4.3 - Screwing up x86 forward compatibility: 286 reset hacks, A20 Gate (HMA), 286 LOADALL, the Intel 80186 CPU missing link
The previous sections covers the basic features of the Intel 80286 CPU, yet that
@@ -3306,51 +3309,50 @@ pales in comparison to the amount of custom circuitry that IBM implemented in
the PC/AT to workaround some of the 286 shortcomings. All these would forever
influence how the x86 architecture evolved, and not in a good way...
-Maybe the biggest issue with 286 Protected Mode is that you were not supposed to
+Maybe the biggest issue with 286 protected mode is that you were not supposed to
be able to return to Real Mode after enabling it, being barred from using the
BIOS Services or the DOS API. However, someone discovered a workaround that made
doing so possible. The workaround consisted in sending a reset signal to the
80286 while preserving the computer state and RAM contents by keeping everything
-powered on. When the Processor was resetted, it would restart in Real Mode,
-then, as you already know, it would begin to execute code loaded from a known
-fixed address location that is where the Firmware is mapped to. With a
-specialized Firmware, it was possible to create an interface where an
-application that wanted to use Real Mode could save to a predefined RAM address
-data about the last Processor state and the next address location where it
-wanted to continue executing code right before triggering the CPU reset. After
-the reset, the Processor would begin code execution by loading the Firmware,
-that in turn, would check very early the predefined RAM address contents to
-figure out if it was a normal boot or if instead it was an intentional CPU
-reset. If there was valid data in that predefined RAM address, it could load the
-previous state and directly resume code execution at the next specified
-location, completely bypassing the standard POST and Hardware initialization
-procedures. This way, it was possible for an application running in the 286
-Protected Mode to return to Real Mode. It was a massive hack, but it worked. The
-method required a lot of preparation to use since, as you also already know, in
-Real Mode you're limited to 1 MiB Physical Address Space, which means that the
-code that would be executed in Real Mode had to be found in that addressable
-MiB. The most fun part about this 286 reset hack is that we have a rather
-similar interface in our modern days, in the form of the
-[ACPI S3 Low Power State][acpis3lowpower], which can shut down then restart most
-of the computer after saving its state while keeping the system RAM powered to
-resume where it left.
-
-IBM seems to not have agreed with Intel strict vision of Protected Mode since it
+powered on. When the Processor was reset, it would restart in Real Mode, then,
+as you already know, it would begin to execute code loaded from a known fixed
+address location that is where the firmware is mapped to. With a specialized
+firmware, it was possible to create an interface where an application that
+wanted to use Real Mode could save to a predefined RAM address data about the
+last Processor state and the next address location where it wanted to continue
+executing code right before triggering the CPU reset. After the reset, the
+Processor would begin code execution by loading the firmware, that in turn,
+would check very early the predefined RAM address contents to figure out if it
+was a normal boot or if instead it was an intentional CPU reset. If there was
+valid data in that predefined RAM address, it could load the previous state and
+directly resume code execution at the next specified location, completely
+bypassing the standard POST and Hardware initialization procedures. This way, it
+was possible for an application running in the 286 protected mode to return to
+Real Mode. It was a massive hack, but it worked. The method required a lot of
+preparation to use since, as you also already know, in Real Mode you're limited
+to 1 MiB Physical Address Space, which means that the code that would be
+executed in Real Mode had to be found in that addressable MiB. The most fun part
+about this 286 reset hack is that we have a rather similar interface in our
+modern days, in the form of the [ACPI S3 Low Power State][acpis3lowpower], which
+can shut down then restart most of the computer after saving its state while
+keeping the system RAM powered to resume where it left.
+
+IBM seems to not have agreed with Intel strict vision of protected mode since it
implemented the described 286 reset hack in the IBM PC/AT. The way that it
-worked was by wiring a GPIO Pin from the new Intel 8042 Microcontroller (Whose
+worked was by wiring a GPIO Pin from the new Intel 8042 microcontroller (Whose
main purpose was to replace the IBM PC Intel 8255 PPI as Keyboard Controller),
known as P20, to the RESET line of the Processor. Software could then operate
-this line via an I/O Port. An application that entered Protected Mode could use
+this line via an I/O Port. An application that entered protected mode could use
the 286 reset hack to return to Real Mode, do whatever it wanted to do with the
-BIOS Services and the DOS API, then enter Protected Mode again. The PC/AT BIOS
-itself used the 286 reset hack during POST so that it could use Protected Mode
+BIOS Services and the DOS API, then enter protected mode again. The PC/AT BIOS
+itself used the 286 reset hack during POST so that it could use protected mode
to test all the physical RAM, then return to Real Mode to boot legacy OSes like
PC DOS as usual. Sadly, while the PC/AT 286 reset hack was functional, it was
rather slow. An application that had to use it often to invoke the BIOS Services
or DOS System Calls would incur in a massive performance penalty, something that
made reliance on the 286 reset hack rather undesirable. Moreover, how much
Conventional Memory was free was still important for applications that used both
-Real Mode and Protected Mode since, as mentioned before, the code and data that
+Real Mode and protected mode since, as mentioned before, the code and data that
relied on Real Mode had to fit in the first addressable MiB (Or more specific
yet, the 640 KiB of Conventional Memory). Basically, the reset hack made
possible for DOS applications to use more RAM, but via a dramatically complex
@@ -3359,7 +3361,7 @@ method.
Less than a year after the IBM PC/AT was released, a Microsoft developer
[discovered][fasterSyscallTrapRedux] and [patented][msos2patents] an alternative
way to reset the 80286 CPU that was faster than using the Intel 8042
-Microcontroller to initiate the reset hack. The new method consisted in
+microcontroller to initiate the reset hack. The new method consisted in
basically the same things that had to be done to preserve and resume the
computer state with the previously described reset hack, but instead of
resetting the Processor via external means, the reset was achieved by performing
@@ -3369,19 +3371,18 @@ the OS/2 Operating System that was jointly developed by IBM and Microsoft, and
released at the end of 1987. It was also used in some Kernel versions of Windows
intended for the 286, like Windows 3.1 running in Standard Mode.
-The CPU Triple Fault is one of the reasons why
-[it was quite hard to emulate or virtualize OS/2][os2virtualization], as not all
-the emulators or VMM/Hypervisors knew how to deal properly with such event. Due
-to the fact that a patent was involved, I doubt that there was any other major
-commercial Software that triggered a CPU Triple Fault to return to Real Mode,
-since using it may have been opening the door to a lawsuit. Moreover, any
-Software targeting the Intel 80386 or later CPUs could switch back and forth
-between Modes by simply changing a Bit, as Intel ended up making the return to
-Real Mode from Protected Mode an official feature of the x86 ISA. It can be said
-that both the reset hack via the 8042 Microcontroller and the CPU Triple Fault
-are pretty much 80286 specific, and thus, very obscure, but they should have
-been supported for compatibility purposes for a long time, and perhaps they
-still are.
+The CPU Triple Fault is one of the reasons why it was quite hard to
+[emulate or virtualize OS/2][os2virtualization], as not all the emulators or
+VMM/Hypervisors knew how to deal properly with such event. Due to the fact that
+a patent was involved, I doubt that there was any other major commercial
+software that triggered a CPU Triple Fault to return to Real Mode, since using
+it may have been opening the door to a lawsuit. Moreover, any software targeting
+the Intel 80386 or later CPUs could switch back and forth between Modes by
+simply changing a Bit, as Intel ended up making the return to Real Mode from
+protected mode an official feature of the x86 ISA. It can be said that both the
+reset hack via the 8042 microcontroller and the CPU Triple Fault are pretty much
+80286 specific, and thus, very obscure, but they should have been supported for
+compatibility purposes for a long time, and perhaps they still are.
The other major issue of the 80286 CPU involves backwards compatibility. Though
in theory the 80286 was fully backwards compatible with the previous x86
@@ -3389,9 +3390,9 @@ Processors thanks to Real Mode, its behavior wasn't 100% identical to any of
them. Both backward and forward compatibility is usually tested and guaranteed
only for properly defined and documented behavior, yet sometimes programmers
decide to exploit quirks, bugs (Formally known as erratas), or undocumented
-instructions (More on that later...) that are not part of the standarized ISA of
-a particular Processor series. As such, applications that relies on any of those
-may fail to work when executed in later Processors that doesn't behave as
+instructions (More on that later...) that are not part of the standardized ISA
+of a particular Processor series. As such, applications that relies on any of
+those may fail to work when executed in later Processors that doesn't behave as
expected, as the Processor designer is under no obligation to maintain support
for nonstandard or unintentional behavior.
@@ -3416,9 +3417,9 @@ using the newer 80286.
IBM once again stepped in with a workaround for this 286 shortcoming. The PC/AT
added some discrete logic infamously known as the A20 Gate, which managed the
80286 A20 Address line (Corresponding to Bit 21 of the CPU Address Bus). The A20
-Gate was wired to another spare Pin of the Intel 8042 Microcontroller, known as
-P21, so that Software could control it via an I/O Port like the previously
-mentioned 286 reset hack to exit Protected Mode. The default state of the A20
+Gate was wired to another spare Pin of the Intel 8042 microcontroller, known as
+P21, so that software could control it via an I/O Port like the previously
+mentioned 286 reset hack to exit protected mode. The default state of the A20
Gate was to force the 80286 A20 Address line to always return 0 so that it could
reproduce the 8086/8088 Address Wraparound quirk while in Real Mode, and it
could also be configured to let it to function as normal for when in Protected
@@ -3432,8 +3433,8 @@ was IBM PC like but not IBM PC compatible), and it isn't hard to guess that it
was for the exact same reason.
The OS/2 Museum site did a long series of articles hunting for IBM PC
-applications that relied on the 8088 Address Wraparound quirk, identifying
-the [CP/M compatible CALL 5 System Call][addressWraparound] implemented in PC
+applications that relied on the 8088 Address Wraparound quirk, identifying the
+[CP/M compatible CALL 5 System Call][addressWraparound] implemented in PC
DOS/MS-DOS and any application that used it, like
[MicroPro WordStar][witnessAgainstWordstar], and
[anything compiled with IBM Pascal 1.0][a20WasntWordstar]. There were also
@@ -3447,20 +3448,20 @@ some applications to fail with no explainable reason because not everyone was
taking the A20 Gate state into account.
A major omission of the A20 Gate hack is that IBM didn't implement a BIOS
-Service to standarize how to manage the A20 Gate for things like to enable it,
+Service to standardize how to manage the A20 Gate for things like to enable it,
disable it, or ask it about its current status (It was possible for this to be a
classic BIOS Service since it could be called from Real Mode both before
-entering and after exiting Protected Mode). This would become a problem several
+entering and after exiting protected mode). This would become a problem several
years later as all PC/AT compatibles had something that could do what the A20
Gate did, but not everyone managed it in a PC/AT compatible way, thus, with the
lack of a BIOS Service, there was no last resort HAL to manage the A20 Gate.
-Later Software Drivers whose purpose was to manage the A20 Gate, known as A20
+Later software Drivers whose purpose was to manage the A20 Gate, known as A20
Handlers, had to become unnecessarily bloated and complex because they had to
support all the different [custom implementations][a20handlers]. Even further
-adding to the complexity is that back then there was no standarized function to
+adding to the complexity is that back then there was no standardized function to
ask the system which computer model it was, so the only way for an A20 Handler
to automatically get things working was by using a sequence of tests that tried
-to find the idiosyncracies of a specific computer model before it could decide
+to find the idiosyncrasies of a specific computer model before it could decide
what code path could be used to manage the A20 Gate in that particular system
(Alternatively, an advanced user could manually configure the A20 Handler if it
allowed the user to do so).
@@ -3474,14 +3475,14 @@ include A20 Handlers that intentionally made use of the standard behavior of the
range, assuming that there was RAM mapped there for it to be useful. The 1024 to
1087 KiB Address Range would become known as the HMA (High Memory Area). The HMA
was useful because the memory there could be addressed directly from within Real
-Mode, without needing to go through Protected Mode at all. In the particular
+Mode, without needing to go through protected mode at all. In the particular
case of PC DOS/MS-DOS, if the HMA was available, they could move data from the
OS itself that traditionally used valuable Conventional Memory into it, and
since this was done in a completely transparent way as the OS took care of
-enabling and disabling the A20 Gate everytime that it had to access its own data
-located in the HMA (I suppose that at a performance penalty due to the extra
-overhead), any regular Real Mode application could benefit from the extra free
-Conventional Memory without needing to directly support the HMA or anything
+enabling and disabling the A20 Gate every time that it had to access its own
+data located in the HMA (I suppose that at a performance penalty due to the
+extra overhead), any regular Real Mode application could benefit from the extra
+free Conventional Memory without needing to directly support the HMA or anything
else.
A thing that still puzzles me, is that I don't recall ever hearing about how
@@ -3490,21 +3491,21 @@ quirk, as any 80286 or 80386 based card (Like the Intel InBoard 386/PC) should
have faced the exact same Processor related problems than the PC/AT. It was
certainly possible to include the A20 Gate functionality in the upgrade card
itself, and even to map the A20 Gate controls to the same I/O Port that in the
-IBM PC/AT for compatibility with any Software that managed it. Sadly, I don't
+IBM PC/AT for compatibility with any software that managed it. Sadly, I don't
know details about specific implementations. I would not be surprised that in
some cases, even if a manageable A20 Gate was present, the implementation was
not compatible with that of the IBM PC/AT and thus failed to run with some
-Software. In a worst case scenario, the A20 Gate could either use a Jumper or be
-completely hardwired, which would make dynamic switch via Software impossible.
+software. In a worst case scenario, the A20 Gate could either use a Jumper or be
+completely hardwired, which would make dynamic switch via software impossible.
The only thing that I'm certain, is that I doubt that the upgrade cards used an
-Intel 8042 Microcontroller to manage the A20 Gate, since it would have been
+Intel 8042 microcontroller to manage the A20 Gate, since it would have been
expensive and pointlessly overkill to include it just for that, so if upgrade
cards did include the A20 Gate hack, they likely used something else to control
it. I'm not sure either how they were supposed to deal with the 286 reset hack,
either, albeit the Triple Fault method should still be possible.
By this point, you get the idea that the story of the 80286 CPU is about an
-incomplete Processor whose shortcomings had to be workarounded with hacks. Keep
+incomplete Processor whose shortcomings had to be worked around with hacks. Keep
in mind that the 80286 was released in 1982, one year after the IBM PC and two
before the PC/AT, so it should have been designed well before Intel had any
chances to realize what its long term impact could be. The sad truth is that
@@ -3514,7 +3515,7 @@ as a filler while Intel finished what it believed to be its next flagship
product, the iAPX 432 Processor architecture. However, when the iAPX 432 finally
became available, it catastrophically failed in the market. As such, Intel
vision of the world would completely change when it became aware that it relied
-on the newfound success of its x86 Processor line to stay reelevant. Basically,
+on the newfound success of its x86 Processor line to stay relevant. Basically,
the main reason why Intel began to take x86 seriously was because at that moment
it had no other viable alternative, and it had to thank the success of the IBM
PC and PC/AT platforms for that opportunity.
@@ -3525,14 +3526,14 @@ least IBM and NEC, not sure how many other did the same) were going out of their
way to make the new 286 do things that it wasn't supposed to do, be it either to
improve backwards compatibility with the previous x86 Processors (The A20 Gate
hack), or to add features that Intel didn't cared about (The 286 reset hack to
-return to Real Mode from Protected Mode). Around that time, Intel must have
+return to Real Mode from protected mode). Around that time, Intel must have
realized that the success of the x86 architecture depended on it being able to
meet the future needs of any successors of the current platforms, and most
-important, of the Software that would run in them, which by definition included
+important, of the software that would run in them, which by definition included
all the preexisting ones. Having learned from its mistakes, Intel efforts
culminated in it doing a much better job when it designed the 80386, which fixed
most of the 286 weak points and synchronized the evolution of the x86
-architecture with the needs of the Software. The 386 would not only be an
+architecture with the needs of the software. The 386 would not only be an
absolute success as a Processor, it would also be good enough to solidify the
basics of the x86 ISA for almost two decades thanks to the much better long term
planning. However, by then, it was already too late, as the dark ages of the
@@ -3541,16 +3542,16 @@ The legacy of the 80286 CPU is the cause of both broken backwards compatibility
and also broken forward compatibility, all of which had to be taken into account
in future generations of x86 Processors.
-The issues of the 80286 were caused not only by Intel own short sightedness when
-designing it, the idiosyncrasies of the Software developers of the era had a lot
-to do with the prevalence of those issues, too. Back in the early days, Software
-developers weren't shy of using, even for commercial Software, undocumented
+The issues of the 80286 were caused not only by Intel own short-sightedness when
+designing it, the idiosyncrasies of the software developers of the era had a lot
+to do with the prevalence of those issues, too. Back in the early days, software
+developers weren't shy of using, even for commercial software, undocumented
instructions (LOADALL, more about that one soon), quirks (The already covered
8086/8088 Address Wraparound quirk, reason why the A20 Gate exist), Bits marked
as reserved in the Processor Registers or other type of data structures (The IBM
PC XENIX 1.0 made by Microsoft is a [good example][fwdCompatLandmines] of this
one), or any other function of a Processor that was not part of its standard
-ISA. How developers found about all these things is a rather interesing topic
+ISA. How developers found about all these things is a rather interesting topic
itself, yet the point is that after a particular discovery had been made public,
there were high chances that its use would proliferate. If another developer
thought that the discovered nonstandard behavior was somehow useful, it could
@@ -3560,82 +3561,83 @@ Processors. Thus, if a newer Processor didn't implement whatever non standard
behavior or quirk a previous one had, there was a high risk that as soon as
someone discovered that a popular application didn't work with the new
Processor, the selling point of backwards compatibility would go down the drain,
-with all the economic consequences associated with having a less sellable
+with all the economic consequences associated with having a less marketable
product. This was precisely the case of the 80286 and the Address Wraparound
quirk, and why IBM did its own effort to workaround it.
-Many Software developers were at fault regarding the compatibility issues, since
-abusing unstandarized behavior just because it worked fine at that point of time
-made a clean forward compatibility strategy outright impossible to implement for
-both Intel and IBM. At the time where there were only IBM branded PCs with 8088s
-or PC/ATs with 80286s and direct clones of them, being bound to their
-idiosyncrasies didn't really mattered as all the computers based on these
+Many software developers were at fault regarding the compatibility issues, since
+abusing non-standardized behavior just because it worked fine at that point of
+time made a clean forward compatibility strategy outright impossible to
+implement for both Intel and IBM. At the time where there were only IBM branded
+PCs with 8088s or PC/ATs with 80286s and direct clones of them, being bound to
+their idiosyncrasies didn't really mattered as all the computers based on these
platforms were functionally identical to each other (If it wasn't, then it was
either a bad clone or a mere PC-like), but as the parts used to build IBM PC or
PC/AT compatible computers began to massively diversify, applications that
-relied on unstandard Hardware behavior became a major compatibility problem as
-the subtle differences in "100% compatible" parts were discovered (An interesing
-example is [IBM's own CGA Video Card][8088mph], as not all CRTC chips that could
-be used for it behaved exactly the same than the Motorola MC6845). Is like if no
-developer thought that there could be newer x86 Processors that didn't include
-the undocumented functions or quirks of the older ones, thus not behaving in the
-same way that expected in an 8088, 80286, or whatever other Processor the
-unintended behavior was first seen. If this situation sounds familiar, is
-because it is. Is something pretty much identical than what happened with
-applications (Mainly games) that were tuned for the exact performance of the
-8088 @ 4.77 MHz of the IBM PC, as described in the Turbo XT section.
-
-All these issues were not exclusive to the Software ecosystem of the IBM PC and
+relied on nonstandard Hardware behavior became a major compatibility problem as
+the subtle differences in "100% compatible" parts were discovered (An
+interesting example is [IBM's own CGA Video Card][8088mph], as not all CRTC
+chips that could be used for it behaved exactly the same than the Motorola
+MC6845). Is like if no developer thought that there could be newer x86
+Processors that didn't include the undocumented functions or quirks of the older
+ones, thus not behaving in the same way that expected in an 8088, 80286, or
+whatever other Processor the unintended behavior was first seen. If this
+situation sounds familiar, is because it is. Is something pretty much identical
+than what happened with applications (Mainly games) that were tuned for the
+exact performance of the 8088 @ 4.77 MHz of the IBM PC, as described in the
+Turbo XT section.
+
+All these issues were not exclusive to the software ecosystem of the IBM PC and
PC/AT platforms, it also happened in other contemporaneous platforms. For
example, the Apple Macintosh platform had a major transition period when the
Motorola 68000 CPU line extended its addressing capabilities from 24 to 32 Bits.
-The Motorola 68000 CPU that the early Macintoshs used had Address Registers of
+The Motorola 68000 CPU that the early Macintoshes used had Address Registers of
32 Bits in size, but only 24 Bits of them were computed, as the Processor
-ignored the upper 8. Early Macintosh Software stored flags in these unused 8
+ignored the upper 8. Early Macintosh software stored flags in these unused 8
Bits (Quite similar to what IBM PC XENIX 1.0 did with the reserved Bits of the
Descriptor Tables of the 80286 MMU). The newer Motorola 68020 extended
addressing to 32 Bits by actually computing the upper 8 Bits, causing a lot of
applications that used the Address Registers the wrong way to implode when
-executed in later Macintoshs equipped with the new Processor (Note that Apple
+executed in later Macintoshes equipped with the new Processor (Note that Apple
implemented a translation layer in its OSes to maintain backwards
compatibility). At least on the x86 side, from the P5 Pentium onwards, Intel
-decided that instead of simply discouraging reserved Bits use, Software
+decided that instead of simply discouraging reserved Bits use, software
developers would be entirely sandboxed, as any attempt to write to something
that they were not supposed to access would cause a GPF (General Protection
Fault), forever fixing that sort of forward compatibility issues.
-While making patches for the affected Software was technically possible (After
+While making patches for the affected software was technically possible (After
all, it was the developer fault for using Hardware functions that it shouldn't),
it would have been a logistical nightmare to distribute them among affected
users, since the only mainstream way to do so was by mailing Diskettes,
-incurring in material and shipping costs. Is not like today that a Software
-developer can release a half broken piece of Software, then fix it via patches
+incurring in material and shipping costs. Is not like today that a software
+developer can release a half broken piece of software, then fix it via patches
that anyone can download via Internet at a negligible cost. A decade later, it
would become common for computer magazines to include CDs with a tons of
-utilitys, patches for games, applications and such, but when the PC/AT was
+utilities, patches for games, applications and such, but when the PC/AT was
released, that wasn't an option, either. The only viable way to mitigate the
compatibility issues, was to forcibly design new Hardware that was fully
-backwards compatible with the old Software. Thus, what Intel learned the hard
+backwards compatible with the old software. Thus, what Intel learned the hard
way, and a bit later than IBM (Thanks to the IBM PCjr fiasco, and perhaps also
because IBM could notice first hand how 100% IBM PC compatibility was the
supreme goal of clone manufacturers), is that backwards compatibility was much
-more than just reproducing the documented and standarized behavior of something,
-it should also reproduce the undocumented and unintentional one, too. What was
-broken in previous Processors, had to remain broken in the newer ones. As soon
-as Intel took backwards compatibility as serious as its main customers did, it
-had to make sure that the unintended behavior of any new Processor matched that
-of the old ones, just to support Software that blatantly ignored the recommended
-programming practices. But this alone was not enough, either. The workarounds
-and hacks that Intel customers implemented for its Processors quirks, like those
-that IBM included in the PC/AT due to the halfway attempt of the 80286 CPU at
-backwards compatibility, produced their own quirks, so Intel had to support
-them, too.
+more than just reproducing the documented and standardized behavior of
+something, it should also reproduce the undocumented and unintentional one, too.
+What was broken in previous Processors, had to remain broken in the newer ones.
+As soon as Intel took backwards compatibility as serious as its main customers
+did, it had to make sure that the unintended behavior of any new Processor
+matched that of the old ones, just to support software that blatantly ignored
+the recommended programming practices. But this alone was not enough, either.
+The workarounds and hacks that Intel customers implemented for its Processors
+quirks, like those that IBM included in the PC/AT due to the halfway attempt of
+the 80286 CPU at backwards compatibility, produced their own quirks, so Intel
+had to support them, too.
For example, the A20 Gate is an excellent case of a customer introduced
workaround that Intel would end up having to accept as part of its x86
architecture. Thanks to the previously mentioned HMA, Intel couldn't simply go
back and fix Real Mode in newer Processors by always using the 8086/8088 style
-Address Wraparound, as now it had to consider that there was mainstream Software
+Address Wraparound, as now it had to consider that there was mainstream software
that depended on the normal behavior of the 80286 A20 Address line while in Real
Mode to address the extra 64 KiB used for the HMA. The only way to maintain full
backwards compatibility was to support two different modes for the A20 Address
@@ -3659,23 +3661,23 @@ undocumented instruction, LOADALL, that could be used to directly write values
to the Processor Registers in a way that bypassed standard validity checks. If
used properly, LOADALL could bent the 286 own official rules to do useful things
that were otherwise impossible (Ironically, not even LOADALL could help the
-80286 to return to Real Mode from Protected Mode). While LOADALL was not
+80286 to return to Real Mode from protected mode). While LOADALL was not
officially documented, Intel did had [internal documentation][loadall] about it,
which they provided to several privileged developers in a document known as
Undocumented iAPX 286 Test Instruction. One of those developers was Digital
Research, that used it for the development of a new OS, Concurrent DOS 286, a
direct descendant of CP/M. With the help of LOADALL, Concurrent DOS 286 could
-use the 286 Protected Mode to emulate an 8088 CPU, making it able to multitask
+use the 286 protected mode to emulate an 8088 CPU, making it able to multitask
some PC DOS/MS-DOS applications.
Even if there is internal documentation about publicly not divulged features,
-their behavior may still not have been standarized and thus is subject to
-change. Sometimes, behavior changes can happen even between different Steppings
+their behavior may still not have been standardized and thus is subject to
+change. Sometimes, behavior changes can happen even between different steppings
(Minor or Major Revisions) of the same Processor design. That was precisely the
roadblock that sealed the fate of [Concurrent DOS 286][concurrentDOS]. Digital
-Research developed that OS using early Steppings of the 80286, where its 8088
+Research developed that OS using early steppings of the 80286, where its 8088
emulation trick worked as intended. For some reason, Intel decided to change
-LOADALL behavior in the production Steppings of the 80286, brokening the
+LOADALL behavior in the production steppings of the 80286, breaking the
emulation capabilities of the preview version of Concurrent DOS 286. Digital
Research delayed the widespread release of its new OS while it argued with Intel
about the LOADALL behavior change. Eventually, Intel released the E2 Stepping of
@@ -3683,22 +3685,22 @@ the 80286 with a LOADALL version that allowed Concurrent DOS 286 to perform
again the emulation trick as intended. However, the whole affair caused the
final version of Concurrent DOS 286 to be a bit too late to the OS market to
make any meaningful impact, besides that it had much more specific Hardware
-requeriments as the emulation feature relied on a particular Processor Stepping.
-I don't know if the E2 Stepping LOADALL behaves like the early Steppings that
+requirements as the emulation feature relied on a particular Processor Stepping.
+I don't know if the E2 Stepping LOADALL behaves like the early steppings that
Digital Research said that worked with Concurrent DOS 286, or if it is a
different third variation, with the second variation being the broken one. The
point is, not even something that was intentionally designed and internally
documented had its behavior set in stone, and reliance on it harmed a privileged
developer. Such is the unpredictable nature of undocumented things...
-Another privileged Software developer was Microsoft, which also got
+Another privileged software developer was Microsoft, which also got
documentation from Intel about the 80286 LOADALL instruction. Whereas Digital
Research used LOADALL to achieve 8088 emulation, Microsoft was perhaps the first
one to use LOADALL to address the entire 16 MiB Physical Address Space from
-within Real Mode, completely skipping Protected Mode (Amusingly, Intel
+within Real Mode, completely skipping protected mode (Amusingly, Intel
documented both use cases in its [LOADALL documentation][loadallRealMode]). This
trick would informally become known as Unreal Mode. As LOADALL could access the
-memory above the 1088 KiB boundary without having to enter Protected Mode nor
+memory above the 1088 KiB boundary without having to enter protected mode nor
needing to exit it by using the 286 reset hacks (The A20 Gate still had to be
enabled and disabled on demand), it was the fastest way for a Real Mode
application to use more memory. During the time period where 286 CPUs were
@@ -3720,19 +3722,19 @@ still remains even on modern x86 Processors.
While typically a newer Processor has all the instructions of a previous one,
the undocumented LOADALL would be specific to the 80286 ISA. As a lot of
-important Software used it, platforms based on later Processors had to deal with
-the removal of LOADALL by having the Firmware trap and emulate it to maintain
+important software used it, platforms based on later Processors had to deal with
+the removal of LOADALL by having the firmware trap and emulate it to maintain
backwards compatibility. Since LOADALL was extremely unique in nature, fully
emulating it was pretty much impossible, yet the emulation techniques seems to
-have been good enough for mainstream use cases. An interesing detail is that the
-Intel 80386 CPU included a different version of LOADALL that is similar in
+have been good enough for mainstream use cases. An interesting detail is that
+the Intel 80386 CPU included a different version of LOADALL that is similar in
purpose but not behavior than the 286 LOADALL. The 386 LOADALL wasn't as
-interesing as the 286 one because there weren't a lot of useful things that it
+interesting as the 286 one because there weren't a lot of useful things that it
could do that weren't possible to achieve via more standard means, including
enabling Unreal Mode. Still, something that made the 386 LOADALL useful is that
it could actually be used to [fully emulate the 286 LOADALL][loadall386], a
-method that at least Compaq used for the Firmwares of its 386 based PC/AT
-compatible platforms. Regardless, is possible than there is Software that uses
+method that at least Compaq used for the firmwares of its 386 based PC/AT
+compatible platforms. Regardless, is possible than there is software that uses
the 286 LOADALL that fails to work in any other platform that either isn't a 286
or does not use the emulation method based on the 386 LOADALL.
@@ -3742,7 +3744,7 @@ if everyone had simply opted to skip these Processors even when they were the
direct successors to the 8086 and 8088. A little known detail about them is that
they were not standalone CPUs (Nor the 80286 for that matter, since it had an
integrated MMU. In other chip set families of the era, the MMU was a discrete
-Coprocessor), instead, they were closer to a modern SoC (System-on-Chip).
+Co-processor), instead, they were closer to a modern SoC (System-on-Chip).
Besides the CPU, they also included an integrated Clock Generator, PIC, DMAC and
PIT. At first glance, this seems wonderful, but that is until you notice that
the integrated functions were not 100% compatible with the discrete parts that
@@ -3770,7 +3772,7 @@ computers had been viable, the average IPC of the 80286 wouldn't appear as
ridiculous high as it was since people wouldn't be directly comparing it to the
8088. The 80186/80188 introduced new x86 instructions that were included in all
later x86 Processors like the 80286, but also in the NEC V20/V30. They had no
-support for Protected Mode or anything related to it like the MMU and Virtual
+support for protected mode or anything related to it like the MMU and Virtual
Memory, albeit at least Siemens in its PC-like PC-X and PC-D platforms coupled
an 80186 with an external MMU precisely to use Virtual Memory (I failed to find
info about which MMU chip these used and how it was interfaced with the 80186,
@@ -3800,7 +3802,7 @@ Processor Stepping. Depending on the Processor, invalid opcodes can produce a
crash, do nothing, be an alias of other documented opcodes, or do something
actually useful that can't be done with documented opcodes (In such case, they
may be more likely undocumented opcodes than merely invalid ones). You can read
-some interesing information pertaining to invalid and
+some interesting information pertaining to invalid and
[undocumented opcodes][undocOpCodes] (Note that it mentions other Processors
besides x86).
@@ -3810,7 +3812,7 @@ doing so. Because by nature they're undefined, the only way to know what an
invalid opcode does is via trial-and-error while watching the Processor state
before and after its execution, something that someone already
[bothered to do][undocOpCodes8086]. Some of these opcodes were reused in later
-x86 Processor generations, so Software relying on them would, as you expect, not
+x86 Processor generations, so software relying on them would, as you expect, not
work in later Processors, once again breaking forward compatibility. On the same
scenario, the 80186/80188 instead triggered an Invalid Opcode Exception,
allowing an Exception Handler to take over execution and do things like
@@ -3840,6 +3842,7 @@ even give them the chance to use it at all.
[undocOpCodes]: https://retrocomputing.stackexchange.com/questions/1591/use-of-undocumented-opcodes
[undocOpCodes8086]: http://www.os2museum.com/wp/undocumented-8086-opcodes-part-i/
+
##### 4.4 - Cascading two Intel 8259A PICs and two Intel 8237A DMACs, the Intel 8254 PIT, the Motorola MC146818 RTC, and the Intel 8042 Microcontroller
The IBM PC/AT cast of support chips received a massive upgrade. It added a
@@ -3848,17 +3851,17 @@ Channels, thus now having two of each chip. The 8253 PIT was upgraded to a 8254
PIT, that has a few more functions but is otherwise backwards compatible. A
Motorola MC146818 RTC was added as a core piece of the platform, so that with
proper OS support, you didn't need to input the Date and Time on OS startup ever
-again. Finally, the 8255 PPI got replaced by a full blown Microcontroller, the
+again. Finally, the 8255 PPI got replaced by a full blown microcontroller, the
Intel 8042, whose main job was that of a Keyboard Controller, but actually did a
multitude of roles.
While none of these chips are present in their discrete physical forms any
longer, most of their functionality is still found in all modern x86 based
computers. The Chipset absorbed the functionality of all the support chips
-except the 8042 Microcontroller, which sticked around as an independent chip for
+except the 8042 microcontroller, which stuck around as an independent chip for
many more years until being replaced by a newer class of Embedded Controllers
that were later on integrated onto the Super I/Os chips (I think that a few
-Chipsets existed that included 8042 functionality, too, but was not usual).
+chipsets existed that included 8042 functionality, too, but was not usual).
Everything else would change, yet compatibility with the PC/AT support chips is
a given even now, making them the IBM PC/AT greatest legacy.
@@ -3874,8 +3877,8 @@ would be known as IRQs 8-15. If you remember correctly, IRQ 2 was directly
exposed in the PC and PC/XT I/O Channel Slots, but that wasn't possible anymore
in the PC/AT due to having been repurposed. Instead, the IRQ2 pin of the I/O
Channel Slots was wired to the second PIC, at IRQ 9. For backwards compatibility
-purposes, the PC/AT BIOS Firmware transparently rerouted Interrupt Requests from
-IRQ 9 so that they appeared Software side as if they were made from IRQ 2. Being
+purposes, the PC/AT BIOS firmware transparently rerouted Interrupt Requests from
+IRQ 9 so that they appeared software side as if they were made from IRQ 2. Being
cascaded from IRQ 2 also impacted Interrupt Priority, as from the main PIC point
of view, any incoming interrupts from the slave PIC at IRQ 2 would have higher
priority than those of IRQs 3-7. The slave PIC itself had the standard 8259A
@@ -3886,11 +3889,11 @@ balanced approach than having wired the slave PIC to IRQ 7 of the primary one.
From the new 8 IRQs, there were two that were for internal Motherboard use only,
IRQs 8 and 13. IRQ 8 was used by the new RTC, whereas IRQ 13 was used by the
-Intel 80287 FPU. The FPU case is interesing as in the IBM PC, the 8087 FPU was
+Intel 80287 FPU. The FPU case is interesting as in the IBM PC, the 8087 FPU was
wired to the 8088 NMI line (Along with the error reporting from the Memory
Parity subsystem) instead of a standard IRQ as Intel recommended. For backwards
compatibility reasons, IBM decided to give IRQ 13 the same treatment that it did
-with IRQ 9, as the Firmware rerouted Interrupt Requests from IRQ 13 as NMI.
+with IRQ 9, as the firmware rerouted Interrupt Requests from IRQ 13 as NMI.
Something that I found quite weird is that the 80287 FPU does not generate
Interrupts directly like the 8087 FPU did, instead, the 82288 Bus Controller
seems to do so in its behalf with its INTA line, which passes though some glue
@@ -3912,7 +3915,7 @@ bypassing its MMU. As such, DMA transactions involved Physical Addresses only,
as it was impossible for a Device to be aware of the new Virtual Memory scheme,
nor for the CPU to be aware of the independent DMA transactions. This wasn't
important at a time when PC DOS reigned supreme since everything used Physical
-Addresses, but eventually it would become a pain for Protected Mode OSes as they
+Addresses, but eventually it would become a pain for protected mode OSes as they
required Bounce Buffers to move data from the Physical Addresses that the DMA
would see to its final destination (This is what the IOMMU would solve 3 decades
later, not by making Devices themselves aware of Virtual Memory, but by giving
@@ -3963,7 +3966,7 @@ DMA Channel 0 to provide DRAM refresh for Memory expansion cards now exposed the
REFRESH signal from the Memory Controller dedicated refresh subsystem, so from a
Memory expansion card perspective, nothing changed.
-Having both DMA Channels 0 and 1 available theorically made possible to do the
+Having both DMA Channels 0 and 1 available theoretically made possible to do the
famed memory-to-memory transfers supported by the 8237A, albeit it was supposed
to be impractical. The master DMAC would still never be able to do them for two
reasons: First, memory-to-memory transfers required to be performed on channels
@@ -3979,14 +3982,14 @@ to ease reading the current status of the Counters compared to having to do so
with 8253 commands.
The IBM PC/AT had the 8254 PIT 3 Counters assigned to the same tasks than the
-IBM PC and PC/XT, but the wiring was slighty different due to changes in the
+IBM PC and PC/XT, but the wiring was slightly different due to changes in the
other chips and discrete circuitry. Counter 0 was used as the System Timer, with
its GATE line unused and its OUT line hooked to IRQ 0 of the master 8259A PIC.
Counter 1 took care of the DRAM refresh timer, with its GATE line unused and its
OUT line wired to the new discrete DRAM refresh circuitry (Part of the Memory
Controller circuitry). Counter 2 was used to drive the PC Speaker, with its GATE
line coming from discrete logic now managed by the new Intel 8042
-Microcontroller (As replacement for the Intel 8255 PPI) and its OUT line wired
+microcontroller (As replacement for the Intel 8255 PPI) and its OUT line wired
to the PC Speaker circuitry.
**Motorola MC146818 RTC (Real Time Clock):** A RTC is a specialized Timer that
@@ -4022,24 +4025,24 @@ The IBM PC/AT introduced the RTC as part of the base platform. The RTC circuitry
used both standard Motherboard power and also an external battery, the idea
being that the battery only supplied power when the computer was powered off.
Thanks to the battery, the RTC 64 Bytes SRAM became NVRAM (Non-Volatile RAM) in
-nature, which IBM decided to put to use to store the Motherboard Firmware
+nature, which IBM decided to put to use to store the Motherboard firmware
configuration settings. From the 50 Bytes of SRAM available to user data, IBM
used 24 to store BIOS settings (IBM even documented which address stored which
setting), and the other 28 were marked as reserved. The RTC Interrupt line was
wired to the slave PIC, at IRQ 8 (Its first IRQ).
**Intel 8042 UPI (Universal Peripheral Interface) Microcontroller:** A
-Microcontroller is pretty much a chip that is more highly integrated than a SoC
+microcontroller is pretty much a chip that is more highly integrated than a SoC
as it includes Processor, RAM, ROM, GPIO and maybe other built-in peripherals,
-yet it is minimalistic in specifications, being a sort of swiss army knife.
+yet it is minimalistic in specifications, being a sort of Swiss army knife.
Microcontrollers are used by any type of electronic or electromechanical devices
-that requires a very small embedded computer performing tasks that are essencial
+that requires a very small embedded computer performing tasks that are essential
but which don't demand a lot of computing power.
The Intel 8042 UPI was part of the same MCS-48 family than the previously
-described 8048 used in IBM Model F Keyboards. Compared to it, it had slighty
-better specifications, but also had a slighty different Instruction Set, thus it
-couldn't run all 8048 Software (Not all 8048 instructions were supported, yet
+described 8048 used in IBM Model F Keyboards. Compared to it, it had slightly
+better specifications, but also had a slightly different Instruction Set, thus
+it couldn't run all 8048 software (Not all 8048 instructions were supported, yet
8048 machine code not using those would run in the 8042). The 8042 included an 8
Bit CPU, Clock Generator, Timer, 2 KiB ROM and 256 Bytes RAM, and at least 16
GPIO Pins (I'm not really sure how many of the other Pins could be repurposed
@@ -4056,17 +4059,17 @@ MCS-85 family, just like the 8086/8088 CPUs.
Besides the 8042, there were several pin and functionally compatible variants.
The most important one is the 8742, whose main difference with the 8042 is that
-the former used EPROM instead of ROM for its internal Firmware, making it user
+the former used EPROM instead of ROM for its internal firmware, making it user
programmable, assuming that the EPROM was blank. It had two major variants, one
being OTP (One Time Programmable), useful for low volume products that only had
-to write the Firmware once in its lifetime (It would have been easier to program
+to write the firmware once in its lifetime (It would have been easier to program
small numbers of those chips than requesting a custom 8042 batch from Intel),
and the other had a crystal window so that you could erase the EPROM with
ultraviolet light and write to it again, making it reusable. There was also the
-8242 series, which had multiple models that came with commercial Firmwares in
-their ROMs. An example is the 8242BB, which had an IBM Firmware that was usable
+8242 series, which had multiple models that came with commercial firmwares in
+their ROMs. An example is the 8242BB, which had an IBM firmware that was usable
for PC/AT compatible platforms (I have no idea whenever IBM licensed a generic
-Firmware, or if it is the same than one used for its own systems. Nor I have
+firmware, or if it is the same than one used for its own systems. Nor I have
idea about why these chips existed on the first place... Maybe IBM decided to
try to get some extra cash from clone manufacturers?).
@@ -4082,12 +4085,12 @@ entirely replaced the discrete Keyboard circuitry of the IBM PC and the
associated 8255 PPI GPIO interface, as it could do the serial-to-parallel data
conversion, signal Interrupts and interface with the I/O Channel Bus all by
itself, thus the Keyboard Port could be directly wired to it. In order to keep
-backwards compatibility with IBM PC Software, the Keyboard function was mapped
+backwards compatibility with IBM PC software, the Keyboard function was mapped
to the same I/O Port than the 8255 PPI Port A was, Port 60h. However, that is
pretty much where backwards compatibility with the 8255 PPI ends.
Since the IBM PC/AT had no Cassette interface and the Motherboard had just a few
-Jumpers, its GPIO requeriments were lesser than the previous Motherboards, which
+Jumpers, its GPIO requirements were lesser than the previous Motherboards, which
is quite convenient as the 8042 had 8 less GPIO Pins than the 8255 PPI. Because
the exposed configuration Bits on the second 8042 Port were different enough,
IBM should have decided to map it somewhere else, as to not risk any conflicts
@@ -4103,7 +4106,7 @@ PC/XT specific, there is a notorious exception involving the PC Speaker, as the
PC Speaker used two Bits from Port 61h (More precisely, the one that managed
GATE 2 input on the 8254 PIT and the Speaker data). The IBM PC/AT still had the
PC Speaker and it was programmed in the same way as to remain backwards
-compatible with IBM PC Software, but I'm not sure who responds to Port 61h
+compatible with IBM PC software, but I'm not sure who responds to Port 61h
requests, as the 8042 is completely unrelated to it now. I suppose that some
discrete glue logic may be involved.
@@ -4128,6 +4131,7 @@ functions of the 8042 together, albeit it is a bit incomplete given my coverage.
[5170motherboard]: http://www.minuszerodegrees.net/5170/motherboard/5170_motherboard_diagrams.htm
+
##### 4.5 - IBM PC/AT Memory Map (Extended Memory and HMA)
As the 80286 CPU extended the Physical Address Space from 1 MiB to 16 MiB, there
@@ -4145,10 +4149,10 @@ original PC. The range reserved for Option ROMs in expansion cards has been
reduced from 192 KiB in the PC/XT to just 128 KiB (768 KiB to 895 KiB).
Meanwhile, the range for Motherboard ROMs was extended from the 64 KiB of the
PC/XT to a whopping 128 KiB (896 KiB to 1023 KiB). This range was the one that
-growed the most, as the original IBM PC had just 48 KiB (40 KiB installed plus
-the empty U28 Socket for an extra 8 KiB ROM) for Motherboard ROMs, which got
+grew the most, as the original IBM PC had just 48 KiB (40 KiB installed plus the
+empty U28 Socket for an extra 8 KiB ROM) for Motherboard ROMs, which got
extended to 64 KiB in the IBM PC/XT (Either only 40 KiB or the full 64 KiB were
-used, depending on Firmware version), then doubled on the IBM PC/AT, both times
+used, depending on firmware version), then doubled on the IBM PC/AT, both times
at the expense of Option ROMs. Note that the PC/AT actually had only 64 KiB of
ROM memory installed, but it had two empty sockets for a second pair of 32 KiB
ROM chips that were mapped and ready to use, just like the original IBM PC with
@@ -4176,7 +4180,7 @@ Area). Some years after the IBM PC/AT release, the first 64 KiB of the Extended
Memory (1024 KiB to 1087 KiB) would become known as the HMA, as it was different
from the rest of the Extended Memory since it could be accessed from within Real
Mode (Related to the 80286 not behaving like the 8088 with its Address
-Wraparound quirk, which the A20 Gate hack workarounded), but otherwise the HMA
+Wraparound quirk, which the A20 Gate hack worked around), but otherwise the HMA
was simply a subset of it.
One thing that became noticeable in the IBM PC/AT Memory Map is the concept of
@@ -4188,9 +4192,9 @@ without breaking IBM PC compatibility, any application than could use the full
was composed of two separated RAM pools, which complicates things when compared
to a single continuous unified address range. Sadly, I don't have specific
examples to quantify how messier it was, but consider than the first version of
-the IBM PC Firmware was supposed to support noncontiguous Conventional Memory,
+the IBM PC firmware was supposed to support non-contiguous Conventional Memory,
yet that feature was removed. Eventually, Virtual Memory would solve Memory Hole
-issues since it would abstract the Memory Map details from user Software and
+issues since it would abstract the Memory Map details from user software and
simply present it with a completely uniform environment, so it didn't mattered
for anyone but the OS developer how ugly the physical Memory Map of the platform
truly was.
@@ -4207,7 +4211,7 @@ contradict itself: The March 1984 version, which covers only the Type 1 PC/AT
Motherboard, says that its dimensions were 12' x 13', or 30.5 cm x 33 cm, yet
the March 1986 version specifically says than the Type 1 Motherboard size was
12' x 13.8', or 30.5 cm x 35 cm, making it 2 cm longer. This difference seems to
-be because the PC/AT Motherboards are not standard rectangles but had a slighty
+be because the PC/AT Motherboards are not standard rectangles but had a slightly
different shape, so it may be a minor correction as if the initial measurement
was made from the shortest side. Either way, it was gargantuan in size compared
to those of the PC and PC/XT. For the Type 2/3 Motherboards, the March 1986
@@ -4221,7 +4225,7 @@ mentioned two empty sockets a pair of optional 32 KiB ROM chips. Type 1
Motherboards had 36 sockets for RAM chips, of which at least half of them (A RAM
Bank) had to be populated, while Type 2/3 had only 18 sockets since they used
RAM chips with twice the capacity. The Intel 80286 CPU and the two 32 KiB ROM
-chips for the BIOS Firmware and IBM Cassette BASIC came socketed, albeit there
+chips for the BIOS firmware and IBM Cassette BASIC came socketed, albeit there
were limited replacements for them. The Motherboards also had an internal header
for the Case mounted PC Speaker, now wired to the newer Intel 8254 PIT.
@@ -4234,7 +4238,7 @@ difference between the old Keyboard protocol and the new one was that the former
was unidirectional, as the Keyboard could send data to the IBM PC but not
receive anything back, whereas the new one was bidirectional, so the Keyboard
Controller could send commands to the Keyboard if it wanted to do so. If you
-ever saw in a Firmware an option to toggle the NumPad default status as On or
+ever saw in a firmware an option to toggle the NumPad default status as On or
Off, is precisely thanks to this bidirectional protocol.
Ironically, the 8042 of the PC/AT supported an alternate mode to use the
@@ -4242,20 +4246,20 @@ Ironically, the 8042 of the PC/AT supported an alternate mode to use the
detecting a PC/AT compatible Keyboard during POST was a fatal error, the only
way to use this mode was to boot with a PC/AT Keyboard, use a command to switch
the 8042 to PC Keyboard protocol mode, disconnect the PC/AT Keyboard, then plug
-in the PC Keyboard (Actually, hotplugging the Keyboard was not supported. You
+in the PC Keyboard (Actually, hot-plugging the Keyboard was not supported. You
were not supposed to disconnect the Keyboard while the computer was on, and
there was a real risk of Hardware damage since back then, the Keyboard Port was
-not designed in a way that gracefully handled hotplugging). I have no idea why
+not designed in a way that gracefully handled hot-plugging). I have no idea why
IBM left this feature half done, as selecting the Keyboard protocol could have
been done via a Jumper on the Motherboard given than the 8042 had many unused
-GPIO Pins. Later third party Keyboards had switcheable modes to use either the
-PC or the PC/AT Keyboard protocol (Typically known as "XT mode" and "AT mode"),
-and could work in either platform. The PC/AT Keyboard protocol is still being
-used today, just that the Keyboard Port connector mutated to the smaller yet pin
+GPIO Pins. Later third party Keyboards had switchable modes to use either the PC
+or the PC/AT Keyboard protocol (Typically known as "XT mode" and "AT mode"), and
+could work in either platform. The PC/AT Keyboard protocol is still being used
+today, just that the Keyboard Port connector mutated to the smaller yet pin
compatible Mini-DIN-6 format with the IBM PS/2 (This is the reason why AT-to-PS2
and PS2-to-AT passive adapters always worked so well).
-The IBM PC/AT Computer Case is reelevant enough to deserve its own paragraph,
+The IBM PC/AT Computer Case is relevant enough to deserve its own paragraph,
compared to those of the PC and PC/XT that had pretty much absolutely nothing
worthy of mention. The new Case introduced what IBM called the Control Panel,
nowadays known as the Front Panel. There were two activity LEDs, one for
@@ -4266,18 +4270,18 @@ Power LED doesn't seem to be connected to any circuitry that controlled it, it
just received dull power to point out that the Motherboard was receiving it from
the Power Supply. The Keylock was wired to Pin P17 of the 8042 Microcontroller,
which toggled the Keyboard Inhibitor function. When the Keyboard Inhibitor was
-turned on, the 8042 didn't listened to the Keyboard (And some OSes extended
-that to the [Mouse][shellMouseMystery]), something
-that served as a primitive form of security against unauthorized users with
-physical access to the computer. Finally, the HDD LED wasn't plugged to the
-Motherboard itself, instead, its cable was plugged to a header on a new combo
-FDC/HDC expansion card that came with the PC/AT (I literally spend HOURS looking
-around for info about this one, and so far, none of the IBM documentation I
-checked that deals with disassembly and assembly of the PC/AT or of the
-particular expansion card seems to explicitly point out that the PC/AT Case HDD
-LED is plugged in the J6 header of that card. I do not know if I didn't checked
-well enough or IBM actually omitted to explicitly mention it). Also, IBM still
-didn't bothered to implement a Reset Button.
+turned on, the 8042 didn't listened to the Keyboard (And some OSes extended that
+to the [Mouse][shellMouseMystery]), something that served as a primitive form of
+security against unauthorized users with physical access to the computer.
+Finally, the HDD LED wasn't plugged to the Motherboard itself, instead, its
+cable was plugged to a header on a new combo FDC/HDC expansion card that came
+with the PC/AT (I literally spend HOURS looking around for info about this one,
+and so far, none of the IBM documentation I checked that deals with disassembly
+and assembly of the PC/AT or of the particular expansion card seems to
+explicitly point out that the PC/AT Case HDD LED is plugged in the J6 header of
+that card. I do not know if I didn't checked well enough or IBM actually omitted
+to explicitly mention it). Also, IBM still didn't bothered to implement a Reset
+Button.
As the previous Keyboards were unusable in the IBM PC/AT, IBM had to release a
revised version of the Model F Keyboard that used the new Keyboard protocol.
@@ -4298,7 +4302,7 @@ Model M. Due to the extreme amount of Keyboard submodels, even after some
googling I don't have clear enough if all Model F are Intel 8042 based and if
all Model M are Motorola 6805 based. Regardless, what matters is that the
Keyboard protocol could be implemented with either Microcontroller. Learning the
-implementation details are reelevant just because you learn to respect more the
+implementation details are relevant just because you learn to respect more the
Keyboards when you notice that they were far more complex that they initially
appear to be. As a bonus, you can read [here][pckbd5years] for the evolution of
the Keyboard Layout, covering both the original PC Model F, the PC/AT Model F,
@@ -4309,11 +4313,12 @@ and the Model M.
[shellMouseMystery]: http://www.os2museum.com/wp/the-dos-4-0-shell-mouse-mystery/
[pckbd5years]: http://www.os2museum.com/wp/pc-keyboard-the-first-five-years/
+
##### 4.7 - IBM PC/AT Motherboard Buses (Local Bus, I/O Channel Bus, Memory Bus)
As can be seen in the System Board Block Diagram in Page 1-6 of the IBM PC/AT
Technical Reference, the Buses of the IBM PC/AT had almost an identical layout
-to those of the original IBM PC, being inmediately recognizable as wider
+to those of the original IBM PC, being immediately recognizable as wider
versions of them. These Buses still were the Local Bus, the I/O Channel Bus, the
Memory Bus and the External I/O Channel Bus.
@@ -4348,17 +4353,17 @@ ROM Bank using two 8 Bits ROM chips. You can check MinusZeroDegrees BIOS ROM
chips - [Diagram 2][5170motherboard] to see how it was supposed to work.
A rarely mentioned detail is that the PC/AT actually had two ROM Banks: One had
-two 32 KiB ROM chips with the Firmware and the IBM Cassette BASIC, ocuppying the
+two 32 KiB ROM chips with the firmware and the IBM Cassette BASIC, occupying the
standard 64 KiB mapping for them (960 KiB to 1023 KiB) as defined by the PC/XT.
The other Bank had two ROM sockets, known as U17 and U37, that were mapped (896
KiB to 959 KiB) and ready to use but otherwise unpopulated. Their usefulness was
roughly the same as the empty U28 Socket in the IBM PC 5150: It was only an
extremely obscure and niche feature that was rarely, if ever, used. As far as I
know, it could be used for an optional Option ROM, and it was possible to insert
-some type of writeable ROMs and program them without the need of an external
+some type of writable ROMs and program them without the need of an external
programmer (Albeit you had to open the Computer Case). I'm not sure if it was
possible to only install and use a single ROM chip, but assuming ht was
-possible, doing so would have required some type of parser Software to write or
+possible, doing so would have required some type of parser software to write or
read it correctly. Either way, good luck trying to find someone that actually
used these ROM sockets.
@@ -4371,8 +4376,8 @@ IBM implemented Parity for RAM memory error detection, which took two more DRAM
chips. Thus, there were 18 1-Bit DRAM chips per RAM Bank (Twice that of the 9
DRAM chips per Bank in the PC and PC/XT), effectively making the Data Bus part
of the Memory Bus 18 Bits wide. Additionally, while the Memory Controller was
-still made out of discrete logic, it was complexer than the PC and PC/XT one as
-it could refresh the DRAM by itself without needing to waste a DMA Channel,
+still made out of discrete logic, it was more complex than the PC and PC/XT one
+as it could refresh the DRAM by itself without needing to waste a DMA Channel,
albeit it still used an 8254 PIT Counter and its OUT line.
Depending on the PC/AT Motherboard version (Type 1 or Type 2/3, respectively),
@@ -4411,7 +4416,7 @@ As the IBM PC/AT made significant chances to the support chips, the External I/O
Channel Bus also had a rearrange of denizens. Now you've got 2 8237A DMACs, 2
8259A PICs, the upgraded 8254 PIT, the MC146818 RTC, and the 8042
Microcontroller, and some discrete logic that managed the now orphaned I/O Port
-of the PC Speaker. The ROM chips with the Firmware and IBM Cassette BASIC were
+of the PC Speaker. The ROM chips with the firmware and IBM Cassette BASIC were
moved to the main I/O Channel Bus.
@@ -4468,7 +4473,7 @@ PCLK line is not something I know.
The second Clock Domain involved a secondary Intel 8284A Clock Generator and a
14.31 MHz Crystal Oscillator. As explained in the Turbo XT sections, some chips
like the 8253/8254 PIT had to run at a specific Frequency as to not screw up the
-timming for applications that relied on these. The PC/AT was among the first IBM
+timing for applications that relied on these. The PC/AT was among the first IBM
PC compatible computers that had to deal with this issue, and IBM solution,
later adopted by everyone else, was to decouple the system wide clock into two
clock domains. Since the 8284A CG is the same one used in the IBM PC, it also
@@ -4574,7 +4579,7 @@ there actually exist cards that could have issues when plugged in the PC/AT due
to the different behavior of that Pin (The cards that supported Slot 8 typically
did so as an alternate mode selectable via a Jumper). It could also be possible
that there were 8 Bits cards intended for the PC/AT that misbehaved in the PC/XT
-because they were expecting the 0WS line, but this seems a rare occurence since
+because they were expecting the 0WS line, but this seems a rare occurrence since
anyone making a card that could fit in either the original IBM PC or PC/XT
should have thought about the possibility than that card was used in those
computers, too. I don't really know if there were demonstrable compatibility
@@ -4610,14 +4615,14 @@ shorter 8 Bits Slots had extra solder pads like if at some point it was intended
for those to be full fledged 16 Bits Slots. As far that I know, 8 Bits and 16
Bits Devices could be freely mixed for as long that their MMIO address ranges
were not mapped into the same 128 KiB address block (In the UMA, this means
-three 128 KiB blocks: 640 to 767 KiB, 768 to 895 KiB, and 896 to 1023 KiB. Each
+three 128 KiB blocks: 640 to 767 KiB, 768 to 895 KiB, and 896 to 1023 KiB. Each
block had to be either all 8 Bits or all 16 Bits). I'm not entirely sure if this
also means that it is possible to use older 8 Bits Conventional Memory expansion
cards for the IBM PC in the 512 to 639 KiB range.
-There was a huge varity of expansion cards for the IBM PC/AT, some of them
+There was a huge variety of expansion cards for the IBM PC/AT, some of them
[made by IBM itself][5170cards] and eventually adopted by others. The most
-prominent one was the new 16 Bits multifunction FDC + HDC card, which used the
+prominent one was the new 16 Bits multi-function FDC + HDC card, which used the
ST-506 interface for HDs like the previous PC/XT HDC. I'm not entirely sure if
this card came with all PC/ATs or only those that came with a HD, but the latter
seems improbable cause I couldn't find a FDC only card for the PC/AT. The FDC +
@@ -4639,7 +4644,7 @@ The other major type of expansion cards were obviously the Video Cards.
Initially, Video Cards included only MDA and CGA, as they were the only ones
available at the release date of the PC/AT. Some months later, IBM released the
EGA (Enhanced Graphics Adapter) and PGC (Professional Graphics Controller) Video
-Cards. EGA prevailed for a while before VGA superceded it 4 years later, yet it
+Cards. EGA prevailed for a while before VGA superseded it 4 years later, yet it
left an important legacy due to its allocation in the Memory Map and the
specialized type of Option ROM that it introduced, the VBIOS. To pitch EGA, IBM
even developed an obscure tech demo known as [Fantasy Land][fantasyLand] to
@@ -4653,10 +4658,10 @@ geared). However, there was a major problem: A framebuffer of that size was far
bigger than the 128 KiB range that IBM reserved in the UMA for such purpose.
Extending the range to 256 KiB was impossible as it would leave pretty much no
room for Option ROMs, and relying on the 286 16 MiB Physical Address Space would
-make EGA totally incompatible with Real Mode Software and the still reelevant
-PC, so it wasn't a viable option, either. To access all of the EGA framebuffer,
-IBM had to resort to map it indirectly via Bank Switching, as getting those 256
-KiB as straightforward MMIO was not possible.
+make EGA totally incompatible with Real Mode software and the still relevant PC,
+so it wasn't a viable option, either. To access all of the EGA framebuffer, IBM
+had to resort to map it indirectly via Bank Switching, as getting those 256 KiB
+as straightforward MMIO was not possible.
Bank Switching is a means to indirectly map more memory than the Physical
Address Space would allow if done directly, at the cost of not being able to
@@ -4682,10 +4687,10 @@ the fixed location of the previous Video Cards framebuffers, a mode that should
have been useful in case that you wanted to use dual displays with EGA + MDA or
EGA + CGA.
-Is notorious than the PC/AT had no built-in Firmware support for the EGA Video
+Is notorious than the PC/AT had no built-in firmware support for the EGA Video
Card like it had for MDA and CGA, instead, the EGA card had its own 16 KiB
Option ROM that the BIOS could load to initialize it. This Option ROM with the
-Video Card Firmware would become known as the VBIOS. Is quite important to
+Video Card firmware would become known as the VBIOS. Is quite important to
mention that the VBIOS is a special type of Option ROM, as it is mapped to a
specific location (The EGA VBIOS was mapped to the 768 KiB to 783 KiB range)
than the BIOS would check very early in the POST process, as it was extremely
@@ -4700,12 +4705,12 @@ Regarding the PGC, the card itself was [really, really complex][pgcCard], and
priced accordingly. The PGC was made out of three PCBs sandwiched that took two
adjacent slots with PC/XT spacing (Actually, it couldn't fit in the original IBM
PC because the slot spacing was different), had an Intel 8088 CPU all for
-itself, a ROM with Firmware, 320 KiB DRAM to use as framebuffer, and 2 KiB SRAM
+itself, a ROM with firmware, 320 KiB DRAM to use as framebuffer, and 2 KiB SRAM
that was simultaneously mapped in the host UMA (792 KiB to 793 KiB) and in the
PGC 8088 so that it could be used as a buffer to pass data between both the host
CPU and the card CPU. It also had CGA emulation capabilities. To use the PGC
full capabilities you were expected to use a specialized IBM Monitor. Due to the
-extremely scarse info about the PGC is hard to say anything else, albeit the few
+extremely scarce info about the PGC is hard to say anything else, albeit the few
comments of users and programmers that had to deal with it seems to point that
it was extremely powerful at the time.
@@ -4720,7 +4725,7 @@ Technically, both Conventional Memory and Extended Memory are system RAM, just
that the former is mapped to a range that can be accessed in Real Mode and works
exactly as expected by applications intended for an IBM PC with an 8088, while
the latter requires dealing with all the issues described in the section
-explaining the 80286 Protected Mode (Or any other alternative like using the 64
+explaining the 80286 protected mode (Or any other alternative like using the 64
KiB HMA, or LOADALL. All them are reliant on proper management of the A20 Gate,
too), so they are treated in two completely different ways.
@@ -4756,9 +4761,10 @@ nightmare that was DOS Memory Management...
[fantasyLand]: https://www.pcjs.org/blog/2018/04/23/
[pgcCard]: http://www.seasip.info/VintagePC/pgc.html
+
##### 4.10 - IBM PC/AT BIOS Firmware, BIOS Setup and RTC SRAM, early overclocking, PC DOS 3.0
-There isn't much to say about the functionality of the PC/AT Firmware itself,
+There isn't much to say about the functionality of the PC/AT firmware itself,
the BIOS did the same basic things that it used to do, and added a few more BIOS
Services on top of the previous ones to support the new PC/AT platform Hardware
changes. The most important change was in how the BIOS was configured. Compared
@@ -4766,7 +4772,7 @@ to the PC and PC/XT, the PC/AT Motherboards had a dramatically reduced amount of
configurable stuff that required physical interaction, with just a Jumper to set
the main Video Card type, and, in Type 1 Motherboards only, a Jumper to select
between 256 or 512 KiB RAM installed on the Motherboard. Nearly everything else
-became a Software configurable setting that the BIOS would read during POST. The
+became a software configurable setting that the BIOS would read during POST. The
PC/AT took advantage of the fact that the Motorola MC146818 RTC had 50 Bytes
free of SRAM that thanks to being battery backed could be used as an NVRAM (Non
Volatile RAM) to store the BIOS Settings. This also gave birth to the Clear CMOS
@@ -4777,13 +4783,13 @@ the battery power for the RTC, so that the SRAM would lose its contents
The PC/AT also introduced the BIOS Setup so that you could change the BIOS
Settings stored in the RTC SRAM, but it was not accessed in the way that you
know it. Instead of being stored in the Motherboard ROM itself, the BIOS Setup
-was a traditional application that came in a booteable Diskette known as
+was a traditional application that came in a bootable Diskette known as
Diagnostics for the IBM Personal Computer AT, so you had to boot with it in
order to change the BIOS Settings. As a last resort, it was possible to use the
built-in IBM Cassette BASIC to edit the BIOS Settings, but you had to know
-exactly what you were doing. Some years later, third party Firmware vendors
+exactly what you were doing. Some years later, third party firmware vendors
released [customs BIOSes][5170bios] for the PC/AT delivered as a pair of ROM
-chips so that you could replace the IBM ones with the standard Firmware. These
+chips so that you could replace the IBM ones with the standard firmware. These
had a built-in BIOS Setup accessed via a Key Combination during POST, something
that may sound familiar to you.
@@ -4798,20 +4804,21 @@ overclocked, in a later PC/AT BIOS version, IBM added a speed loop test during
POST that failed if the 286 was running above 6 MHz. The Type 3 Motherboard had
another BIOS version that revised the speed loop test to support 8 MHz
operation. If you were overclocking, avoiding these speed loops was a good
-reason to use a third party Firmware.
+reason to use a third party firmware.
The PC/AT also included a new version of its main OS, PC DOS 3.0, which could
use some of the new computer capabilities (Mainly the RTC for time keeping) and
introduced the FAT16 File System. The convenience of having a built-in battery
backed RTC was enormous, as in the PC and PC/XT, you had to type in the Date and
-Time everytime you turned on the computer (Unless you had an expansion card with
-a RTC and OS Drivers for it. RTC cards were a popular addon for the original IBM
-PC), whereas in a PC/AT with PC DOS 3.0, the RTC worked out of the box. You
-could also use older versions of PC DOS, assuming you didn't mind their
+Time every time you turned on the computer (Unless you had an expansion card
+with a RTC and OS Drivers for it. RTC cards were a popular add-on for the
+original IBM PC), whereas in a PC/AT with PC DOS 3.0, the RTC worked out of the
+box. You could also use older versions of PC DOS, assuming you didn't mind their
limitations.
[5170bios]: http://www.minuszerodegrees.net/bios/bios.htm#5170
+
##### 4.11 - The IBM PC/XT 5162 Model 286
Besides the three PC/AT Motherboards types and the multiple PC/AT computer
@@ -4819,15 +4826,15 @@ models based on them, there was another computer that is usually considered part
of the IBM PC/AT series. In 1986, IBM launched the IBM PC/XT 5162 Model 286,
which has a misleading name since it is actually based on the PC/AT platform.
While the computer was fully PC/AT compatible, it had both minor and major
-differences that are reelevant to the PC/AT section.
+differences that are relevant to the PC/AT section.
The PC/XT 5162 Motherboard was completely new. It had 8 I/O Channel Slots, 5
were for 16 Bits cards and 3 for 8 Bits ones, a slight downgrade from the PC/AT
(One of the 8 Bits slots had extra solder pads, as if it could have been a 16
-Bits slot). It measured 8.5' x 13.2', or 22 cm x 33.8 cm, making it slighty
+Bits slot). It measured 8.5' x 13.2', or 22 cm x 33.8 cm, making it slightly
smaller than the PC/AT Type 2/3 Motherboard. This size is highly important
because it would eventually become the basis for the Baby AT Motherboard Form
-Factor, making the PC/XT 5162 quite reelevant in the history of the PC platform
+Factor, making the PC/XT 5162 quite relevant in the history of the PC platform
evolution.
The clock generation scheme of the PC/XT 5162 was very similar to the Type 1/2
@@ -4872,7 +4879,7 @@ chips sockets, yet there wasn't any actual functional difference.
The two empty ROM sockets for the optional ROM Bank than the PC/AT Motherboards
had isn't present on the PC/XT 5162 Motherboard. I'm not sure if the 64 KiB
range in the PC/AT Memory Map reserved for those are free in the PC/XT 5162
-Memory Map or not. At least a source I recall said that the Firmware and IBM
+Memory Map or not. At least a source I recall said that the firmware and IBM
Cassette BASIC are mirrored there (Perhaps unintentionally caused by partial
address decoding...), so that range may not be free at all.
@@ -4880,7 +4887,7 @@ The IBM PC/XT 5162 used an actual PC/XT 5160 Case, so it had no Control Panel
(The two LEDs and the Keylock). I'm not sure if the Motherboard had a leftover
header for the Power LED or if it was removed since it wasn't going to be used
anyway. However, the PC/XT 5162 came by default with the same HDC + FDC
-multifunction card that was used by the IBM PC/ATs, so the header for the HDD
+multi-function card that was used by the IBM PC/ATs, so the header for the HDD
LED should still be there, but unused.
@@ -4896,42 +4903,42 @@ techniques would remain necessary even by the late 90's, as people still used
DOS for applications and games that weren't Windows 9x friendly (Or simply due
to better performance, since executing them from within a Windows environment
added a not insignificant overhead). It took until Windows XP became the most
-common mainstream OS for this topic to stop being reelevant, after which it
-would be almost completely forgotten.
+common mainstream OS for this topic to stop being relevant, after which it would
+be almost completely forgotten.
The issues with 286 DOS Memory Management are directly related to the unusual
-requeriments of the 80286 CPU to be able to use its entire Physical Address
+requirements of the 80286 CPU to be able to use its entire Physical Address
Space combined with the PC/AT platform idiosyncrasies, like its Memory Map. As
you already know, the 80286 CPU used in the IBM PC/AT had a 16 MiB Physical
Memory Address Space, a significant upgrade over the 1 MiB one of the 8088 CPU
used in the IBM PC. While the extra 15 MiB that the IBM PC/AT could address
should have been good enough for several years, in order to use them as Intel
-intended when it designed the 80286, Software had to be running within Protected
+intended when it designed the 80286, software had to be running within Protected
Mode, whose usage had a multitude of cons that were already detailed.
-To recap Protected Mode cons, first of all, Software that relied on it couldn't
+To recap protected mode cons, first of all, software that relied on it couldn't
run on the IBM PC 8088 at all, significantly reducing the amount of potential
customers of such products unless the developer also provided a dedicated IBM PC
port of its application, something that would require more developing resources
than just making a single Real Mode version that could easily run in both
-platforms. Moreover, the mainstream Software ecosystem made use of the DOS API
+platforms. Moreover, the mainstream software ecosystem made use of the DOS API
from PC DOS to read and write to the FAT File System, and the BIOS Services from
-the BIOS Firmware to do the role of a Hardware Driver, both of which were usable
-only from within Real Mode. A developer that wanted to make a Protected Mode
-application without getting support from a Protected Mode environment would have
+the BIOS firmware to do the role of a Hardware Driver, both of which were usable
+only from within Real Mode. A developer that wanted to make a protected mode
+application without getting support from a protected mode environment would have
had to reimplement absolutely everything from scratch, similar to a PC Booter
for the IBM PC but worse, since those could at least rely on the BIOS Services
-to deal with the Hardware. Albeit it was still possible to make a Protected Mode
+to deal with the Hardware. Albeit it was still possible to make a protected mode
DOS application that could use the DOS API and the BIOS Services by using the
286 reset hack to return to Real Mode, it was slow and cumbersome to do so (Keep
in mind that while Hardware support for both Unreal Mode and resetting the 80286
CPU via a Triple Fault was present in the IBM PC/AT since Day One, the
-techniques to use them were not discovered or massified until much later.
-Unreal Mode required knowledge about how to use LOADALL, something that only
-privileged developers had access to during the 80's, making it effectively
-unavailable. The 286 Triple Fault technique was discovered and patented early on
-by Microsoft, so even if public it was risky to use, yet chances are that most
-developers didn't knew about it back then, either).
+techniques to use them were not discovered or mastered until much later. Unreal
+Mode required knowledge about how to use LOADALL, something that only privileged
+developers had access to during the 80's, making it effectively unavailable. The
+286 Triple Fault technique was discovered and patented early on by Microsoft, so
+even if public it was risky to use, yet chances are that most developers didn't
+knew about it back then, either).
On top of the Physical Memory Address Space you have the Memory Map, which
defines how that address space is intended to be assigned to try to cover all
@@ -4944,7 +4951,7 @@ MiB Physical Address Space into two segments: A 640 KiB range between 0 to 639
KiB known as Conventional Memory, intended to be used exclusively for system
RAM, and a 384 KiB range between 640 KiB to 1023 KiB known as UMA (Upper Memory
Area), intended for everything else, including ROMs like the Motherboard BIOS
-Firmware, Option ROMs in expansion cards, and MMIO, like the Video Card
+firmware, Option ROMs in expansion cards, and MMIO, like the Video Card
framebuffer. For the IBM PC/AT Memory Map, in addition to keeping what was in
the IBM PC one, IBM defined that the new address space above 1024 KiB and up to
15 MiB would be known as Extended Memory, intended to be used for more system
@@ -4953,7 +4960,7 @@ RAM (The last 128 KiB were used to mirror the Motherboard ROM, and the remaining
mirror were left undefined. But these are not important). An issue caused by
this arrangement is that the system RAM was no longer a single continuous chunk,
since the presence of the UMA between the Conventional Memory and the Extended
-Memory left a memory hole, so Software that directly interacted with the
+Memory left a memory hole, so software that directly interacted with the
physical memory had to be aware of that (This is something that Virtual Memory
greatly simplifies, as it abstracts these details from user applications).
@@ -4961,21 +4968,21 @@ Some years after the IBM PC/AT release, the first 64 KiB of the Extended Memory
(1024 KiB to 1087 KiB) would become known as the HMA (High Memory Area), as it
was different from the rest of it since the HMA could be accessed from within
Real Mode (Related to the 80286 not behaving like the 8088 with its Address
-Wraparound quirk, which the A20 Gate hack workarounded), but otherwise it was
+Wraparound quirk, which the A20 Gate hack worked around), but otherwise it was
simply a subset of the Extended Memory. So far, so good, as this covers the
basic IBM PC/AT Memory Map.
Due to the complexity of actually putting the extra address space to use, for a
few years after the IBM PC/AT release, only niche high end applications that
-really required more memory took care of all the mandatory hazzle to use the RAM
+really required more memory took care of all the mandatory hassle to use the RAM
mapped into the Extended Memory address range, the vast majority of mainstream
-Software just keep using pure Real Mode and PC DOS as the lowest common
+software just keep using pure Real Mode and PC DOS as the lowest common
denominators, both for full IBM PC compatibility and to ease development. This
means that in a PC/AT, while mainstream applications could execute faster, they
were still constrained by the 640 KiB RAM limit of the Conventional Memory,
which would quickly become a severe limitation. I think that during the years
-that the IBM PC/AT was top of the line, the only popular mainstream DOS Software
-that used Extended Memory were RAMDiskses, as the virtual disk contents could be
+that the IBM PC/AT was top of the line, the only popular mainstream DOS software
+that used Extended Memory were RAMDisks, as the virtual disk contents could be
stored into the Extended Memory with little risk than it would get thrashed by
PC DOS or another application since these were mostly Real Mode only (Remember
that there was effectively no Memory Protection). The RAMDisk Driver resided in
@@ -4983,11 +4990,11 @@ Conventional Memory and took care of switching Processor modes to access the
Extended Memory when requested to do so, then restored the Processor state.
Perhaps one of IBM most notorious shortsightedness events was precisely that it
-didn't took seriously enough the importance of pushing for a Protected Mode OS
-for the IBM PC/AT as soon as possible, as transitioning to a Protected Mode
-Software ecosystem early on could have saved us from the chaos that was DOS
+didn't took seriously enough the importance of pushing for a protected mode OS
+for the IBM PC/AT as soon as possible, as transitioning to a protected mode
+software ecosystem early on could have saved us from the chaos that was DOS
Memory Management during the 90's. The big irony is that just a few months after
-the IBM PC/AT release, a viable Protected Mode OS appeared in the form of IBM PC
+the IBM PC/AT release, a viable protected mode OS appeared in the form of IBM PC
XENIX, a Xenix port for the IBM PC/AT that had FAT File System support, fully
replacing any need for the DOS API, the BIOS Services, or Real Mode itself for
any new applications that targeted it. However, since Xenix was aimed at serious
@@ -5000,22 +5007,22 @@ higher OS overhead for no tangible benefit.
I believe that such transition could have been done anyways since during the
middle of the 80's, IBM was powerful enough that it should have been possible
-for it to force the entire PC/AT Software ecosystem to adopt either Xenix or
-another new Protected Mode OS even if it was at the cost of compatibility, like
+for it to force the entire PC/AT software ecosystem to adopt either Xenix or
+another new protected mode OS even if it was at the cost of compatibility, like
Microsoft did when it pushed Windows XP, which during the early days had a lot
-of compatibility issues with Windows 9x and DOS Software. As even at the 1984
+of compatibility issues with Windows 9x and DOS software. As even at the 1984
release date of the IBM PC/AT you could partition a HD to install multiple OSes,
power users could have survived the transition perhaps with no compatibility
loss, as they could have been able to Dual Boot both PC DOS when requiring an
-IBM PC compatible environment and a Protected Mode OS for PC/AT applications.
-Sadly, IBM didn't made any serious attempt to transition the Software ecosystem
-to Protected Mode until 1987 with OS/2, but by then, it was already too late.
-With application memory requeriments increasing yet no mainstream Protected Mode
+IBM PC compatible environment and a protected mode OS for PC/AT applications.
+Sadly, IBM didn't made any serious attempt to transition the software ecosystem
+to protected mode until 1987 with OS/2, but by then, it was already too late.
+With application memory requirements increasing yet no mainstream protected mode
OS in the horizon to use the enhanced 80286 addressing capabilities, it seems
logical to expect that such situation created the need for stopgap measures that
allowed applications to use more memory from within PC DOS. The problem relies
on the fact that those stopgap measures lasted for far longer than expected, and
-directly increased PC DOS longetivity at the detriment of better thought
+directly increased PC DOS longevity at the detriment of better thought
alternatives that fixed the issue directly from its root...
In 1985, Lotus, Intel and Microsoft teamed up to create a hack that allowed for
@@ -5045,7 +5052,7 @@ future PC and PC/AT Memory Maps, as it became ubiquitous enough.
Since in order to properly do Bank Switching the Memory Controller had to be
managed, the Expanded Memory cards always required Drivers. To hide this from
the application developers, an API was defined, the previously mentioned EMS,
-which allowed the Software developer to rely on it to access the Expanded Memory
+which allowed the software developer to rely on it to access the Expanded Memory
instead of having to manually program the Memory Controllers themselves. This
was quite important, as there were multiple Expanded Memory cards manufacturers
whose Hardware implementations were different, so using the EMS API provided a
@@ -5058,14 +5065,14 @@ was conceptually different than EMS since it didn't required to be paired with
new Hardware, instead, it focused on managing the existing Extended Memory via a
new Driver known as the XMM (Extended Memory Manager).
-What the XMS API did was merely to standarized how a Real Mode DOS application
-could use the Extended Memory by delegating the responsability of switching
+What the XMS API did was merely to standardized how a Real Mode DOS application
+could use the Extended Memory by delegating the responsibility of switching
Processor modes, exchange data between the Conventional Memory and the Extended
Memory, then restoring the Processor state, to the XMM Driver. Basically, an
application that supported XMS just had to use its API to ask the XMM Driver to
move data to or from the Extended Memory, then let it take care of everything
else, significantly easing application development since the developer had no
-need to meddle with all the mandatory hazzles required to access the Extended
+need to meddle with all the mandatory hassles required to access the Extended
Memory from within a mostly Real Mode environment. Executable code was expected
to remain in the Conventional Memory since the XMS API just moved RAM contents
around, leaving the Extended Memory as a sort of secondary storage just for
@@ -5076,37 +5083,38 @@ A20 Handler. The first version of HIMEM.SYS that was distributed should have
been the one included in Windows 2.1 (Windows/286), released around the middle
of 1988. In 1991, a newer version of HIMEM.SYS was included in PC DOS/MS-DOS
5.0, so that XMS was usable in a pure DOS environment (Keep in mind that while
-it worked on the original 1984 IBM PC/AT, it isn't really era appropiated, as by
-then, these early 286s were rather ancient). A very interesing detail is that
+it worked on the original 1984 IBM PC/AT, it isn't really era appropriate, as by
+then, these early 286s were rather ancient). A very interesting detail is that
the Microsoft XMM Driver was much faster than it should have been under normal
-circunstances, and that is because Microsoft used all its knowledge about the
+circumstances, and that is because Microsoft used all its knowledge about the
Intel Processors undocumented functions to cheat. Many versions of HIMEM.SYS
relied on [LOADALL and its Unreal Mode][unrealMode] to access the Extended
Memory, completely bypassing the standard way of doing things that included
-entering Protected Mode then resetting the Processor. Basically, any application
+entering protected mode then resetting the Processor. Basically, any application
that used XMS under DOS in a 286 based computer transparently benefited from the
performance hacks involving Unreal Mode.
[unrealMode]:(http://www.os2museum.com/wp/himem-sys-unreal-mode-and-loadall/)
+
5 - The Turbo ATs and the first Chipsets
----------------------------------------
To surprise of no one, clone manufacturers didn't rest in their laurels. Right
after mastering how to clone the PC, they began to work on how to clone the
-PC/AT. The early PC/AT clones should either slighty predate or be contemporaries
-of the earliest Turbo XTs (Not PC-likes), and be both faster and more expensive
-than them. The PC/AT clones would almost inmediately evolve into Turbo ATs (A
-term that is rarely used), which were faster than the system that they were to
-be compatible with.
+PC/AT. The early PC/AT clones should either slightly predate or be
+contemporaries of the earliest Turbo XTs (Not PC-likes), and be both faster and
+more expensive than them. The PC/AT clones would almost immediately evolve into
+Turbo ATs (A term that is rarely used), which were faster than the system that
+they were to be compatible with.
Turbo ATs would eventually further evolve with the introduction of the first
-Chipsets, as they would dramatically alter the platform topology. This also
+chipsets, as they would dramatically alter the platform topology. This also
highly reduced the number of variety in original Motherboard designs, as the
Chipset based Motherboards tended to consolidate their feature set around a
specific Chipset characteristics, thus a vendor had to really go out of its way
-to do something different enough. Turbo XTs would eventually get Chipsets, too,
-but apparently slighty later.
+to do something different enough. Turbo XTs would eventually get chipsets, too,
+but apparently slightly later.
##### 5.1 - First generation PC/AT clones and Turbo ATs, integrated BIOS Setup
@@ -5122,36 +5130,36 @@ enough to be remarkable.
In July 1985, 4 months after the Kaypro 286i and almost a year after the
original IBM PC/AT, Compaq released its [DeskPro 286][deskpro286]. What made it
-interesing, is that it had an Intel 80286 CPU that could run at two operating
+interesting, is that it had an Intel 80286 CPU that could run at two operating
modes, one known as the Slow Mode that worked at 6 MHz for full compatibility
with the original IBM PC/AT, and a Fast Mode that ran at 8 MHz (Note that it
predates IBM own 8 MHz PC/AT model). Unlike most Turbo XT systems, the DeskPro
286 didn't had a Turbo Button, instead, it relied on either a Key Combination,
Ctrl + Alt + \\ or the MODE SPEED command in MS-DOS. Since it explicitly
mentions two different clock speeds, I suppose that it has two different Crystal
-Oscilators like Turbo XTs and switches between them on demand. As I'm not aware
+Oscillators like Turbo XTs and switches between them on demand. As I'm not aware
whenever there was an earlier system with such feature, the DeskPro 286 may be
the first PC/AT compatible that can be classified as a Turbo AT.
A major difference between Turbo XTs and Turbo ATs is what they were intended to
-be compatible with. As you already know, a lot of early PC Software was tuned
+be compatible with. As you already know, a lot of early PC software was tuned
expecting only an IBM PC with its 8088 CPU @ 4.77 MHz, thus they didn't work as
intended in faster computers like Turbo XTs or PC/AT based ones. This exact
-issue also happened with some PC/AT Software, as at least a few applications
+issue also happened with some PC/AT software, as at least a few applications
were tuned specifically for the IBM PC/AT (Usually related to those pesky copy
protection schemes...), failing to work properly in anything faster than it.
-However, when it comes to PC/AT Software, there was an additional hurdle: Which
+However, when it comes to PC/AT software, there was an additional hurdle: Which
IBM PC/AT version an application was tuned for? Whereas both the PC and PC/XT
had identical performance, there was an early 6 MHz PC/AT and a later 8 MHz
model, plus the PC/XT 5162 that ran at 6 MHz but with 0 Memory WS. The
performance of these three PC/AT platform variants was different. As all PC/AT
-Software released before 1986 would only be expecting the original 6 MHz IBM
+software released before 1986 would only be expecting the original 6 MHz IBM
PC/AT model, it was possible that some of these very early applications would
not work as intended even in IBM own PC/AT variants. Later PC/AT compatible
manufacturers noticed this and implemented user configurable clock speed and
Memory WS, so that their PC/AT clone computers could perfectly match any of the
three IBM PC/AT variants performance levels, resulting in the Turbo ATs being at
-times more compatible with older PC/AT Software and expansion cards than the
+times more compatible with older PC/AT software and expansion cards than the
later IBM PC/AT 8 MHz models themselves, as IBM never bothered to implement a
feature similar to Turbo.
@@ -5161,10 +5169,10 @@ at either 6 MHz @ 1 Memory WS, 8 MHz @ 2 Memory WS (Albeit based on a page that
list the Motherboard Jumpers it seems that it is actually 8 MHz @ 1 Memory WS,
which makes sense as otherwise it wouldn't match the 8 MHz IBM PC/AT), or 10 MHz
@ 0 Memory WS. Getting a 286 to run at 10 MHz @ 0 Memory WS was quite an
-accomplishment, and it made it slighty faster than another contemporary 286
+accomplishment, and it made it slightly faster than another contemporary 286
PC/AT compatible system running at 12 MHz @ 1 Memory WS. However, it required
new and expensive 100 ns DRAM chips mounted in a custom, very long Memory
-expansion card that used a propietary connector, known as FASTram, that was
+expansion card that used a proprietary connector, known as FASTram, that was
pretty much a standard 16 Bits I/O Channel Slot followed with another separate
section at the end of the card (This is roughly the same thing that VESA Local
Bus Slots would do years later). The Motherboard had two slots with the FASTram
@@ -5180,36 +5188,36 @@ code of the original Phoenix BIOS).
Something that I don't remember hearing about is of any PC/AT compatible that
could go lower than 6 MHz to try to have better compatibility with early PC
-Software, as a 286 @ 3 MHz may have been not much above the PC 8088 @ 4.77 MHz
+software, as a 286 @ 3 MHz may have been not much above the PC 8088 @ 4.77 MHz
performance level and thus could have been far more usable for things like
games. Considering that, as explained elsewhere, perfect PC compatibility was
impossible due to the 286 not being cycle accurate with the 8088, it makes sense
that PC/AT compatible manufacturers didn't bothered adding a way to slow down
their newer flagships systems since it was a lost cause anyways (Ironically, at
-least an 80386 based system, the [Dell System 310][dellSystem310],
-could be underclocked to 4.77 MHz. Perhaps Dell added such option because, as
-you already know, the 4.77 MHz Frequency is easy to derive). Actually,
-compatibility with early PC Software would crumble rather fast after the PC/AT
-generation, as no one going for the high end segment of the PC/AT compatible
-market would event attempt bothering to try to support these any longer.
+least an 80386 based system, the [Dell System 310][dellSystem310], could be
+underclocked to 4.77 MHz. Perhaps Dell added such option because, as you already
+know, the 4.77 MHz Frequency is easy to derive). Actually, compatibility with
+early PC software would crumble rather fast after the PC/AT generation, as no
+one going for the high end segment of the PC/AT compatible market would event
+attempt bothering to try to support these any longer.
The good thing is that at the end of the PC/AT generation (More likely after the
release of the 8 MHz IBM PC/AT), there was a paradigm shift about how the
-Software developers took care of implementing any type of timers or timmings in
+software developers took care of implementing any type of timers or timings in
their applications. Instead of outright relying on speed loops or any other bad
-practices that worked at that moment but killed forward compatibility, Software
+practices that worked at that moment but killed forward compatibility, software
developers began to be aware that they needed to be more careful as to not make
things that are hardly usable on faster computers, as by that point it had
already become quite obvious that the PC/AT platform was going to have faster
versions of the same base platform, or successors that were going to be mostly
-backwards compatible. This paradigm shift is why late 80' Software is much less
+backwards compatible. This paradigm shift is why late 80' software is much less
problematic on faster computers from the late 90's compared to many of the early
-Software that pretty much forced you to use a PC class computer. There are some
+software that pretty much forced you to use a PC class computer. There are some
notorious exceptions like the 1990 Origin Systems game Wing Commander, which
could play faster than intended on some era accurate 80386 systems, depending on
the Processor clock speed and external Cache configuration.
-In general, timming issues and bad programming practices would still be present
+In general, timing issues and bad programming practices would still be present
for a long time, but they took many years to manifest instead of the very next
computer model, as happened during the early days. Perhaps the most famous
timing issue of the 90's was the Windows Protection Error when trying to boot
@@ -5223,29 +5231,29 @@ accurate AMD K6-II, the LOOP instruction executed with a mere 1 clock cycle
latency, whereas on an Intel Pentium Pro/II/III it took 6 clock cycles, thus it
would trigger the bug at a much lower clock speed than otherwise (In much later
Intel Processors that can finally match the K6-II speed on that particular
-routine, the bug is reproducible, too). Every now and then other ancient timming
-issues pop out when trying to run older pieces of Software in newer computers,
+routine, the bug is reproducible, too). Every now and then other ancient timing
+issues pop out when trying to run older pieces of software in newer computers,
like [this early Linux SCSI Controller Driver][timingIsHard], but none of these
are as notorious as the Windows 95 one, nor their cause is as esoteric in
nature.
Finally, while I'm not sure about the exact time frame (It could be as late as
1988), an extremely important feature that everyone considers a given nowadays
-began to appear in either PC/AT clones or Turbo ATs. Third party BIOS Firmware
+began to appear in either PC/AT clones or Turbo ATs. Third party BIOS firmware
vendors like Phoenix Technologies and AMI decided to integrate the BIOS
-configuration application into the Firmware ROM image itself, giving birth to
+configuration application into the firmware ROM image itself, giving birth to
the modern BIOS Setup. By integrating this critical tool, if you ever wanted to
configure the BIOS Settings, you could use a Key Combination during POST to
enter the BIOS Setup, without having to worry about preserving the Diskette that
-came with the system, which could be damaged or become lost. Some Firmware
+came with the system, which could be damaged or become lost. Some firmware
vendors even offered third party BIOSes for the original IBM PC/AT that included
an integrated BIOS Setup, which were delivered as a pair of ROM chips to replace
-the standard IBM ones (These Firmware images should also work in 100% compatible
+the standard IBM ones (These firmware images should also work in 100% compatible
PC/AT clones, too). At the time this integration was a minor convenience, but as
the PC/AT compatible platforms began to drastically differ between them and thus
-required a BIOS configuration tool appropiately customized for that computer or
+required a BIOS configuration tool appropriately customized for that computer or
Motherboard revision, having the BIOS Setup integrated was becoming a necessity.
-Some time later, during the IBM PS/2 generation timeframe, IBM would learn the
+Some time later, during the IBM PS/2 generation time frame, IBM would learn the
hard way that having a multitude of different configuration Diskettes was a
logistical nightmare...
@@ -5258,6 +5266,7 @@ logistical nightmare...
[fastMachineWin9xCrashes]: http://www.os2museum.com/wp/those-win9x-crashes-on-fast-machines/
[timingIsHard]: http://www.os2museum.com/wp/timing-in-software-is-too-hard/
+
##### 5.2 - The first PC/AT Chipset, C&T CS8220. Feature overview and Clock Generation
A major breakthrough that revolutionized the computer industry was the
@@ -5267,7 +5276,7 @@ had been trying to differentiate themselves from IBM by providing computers that
were faster or had more features than IBM ones while remaining as close as
possible to 100% compatible with them, most of the semiconductor industry had
been happy enough merely by being used as second sources that manufactured Intel
-designed chips (Having second sources was a requeriment that IBM imposed to
+designed chips (Having second sources was a requirement that IBM imposed to
Intel. At least until Intel got big enough that it didn't need those second
sources any longer, thus Intel tried to get rid of them, but that is part of
another story...). So far, NEC was the only one that I'm aware of that early on
@@ -5297,11 +5306,11 @@ platform by using three or more and still be mostly backwards compatible. A
Chipset that was intended to reproduce the IBM PC/AT functionality should behave
in the same way that its two cascaded 8259A would, but it was impossible to wire
to a Chipset a third standalone 8259A because they weren't intended to be
-interfaced with more support chips. As Chipsets invaded the market, they pretty
+interfaced with more support chips. As chipsets invaded the market, they pretty
much cemented the limits of the PC/AT platform, since it was not possible to
extend a highly integrated Chipset by adding individual support chips. Thus, the
evolution of the PC platform as a whole became dominated by which features got
-into Chipsets and which did not.
+into chipsets and which did not.
The very first Chipset was the C&T (Chips & Technologies) CS8220, released in
1986, and whose datasheet you can see [here][cs8220]. The CS8220 Chipset was
@@ -5371,7 +5380,7 @@ cards. However, as a consequence from that, the System Bus is no longer a direct
extension of the Local Bus, it is now a completely separate entity that can have
its own protocol. What this means is that if a new x86 Processor type changed
the Local Bus protocol (Which eventually happened a multitude of times), an
-appropiate Chipset could easily take care of interfacing both Buses by
+appropriate Chipset could easily take care of interfacing both Buses by
translating between the new and old protocols, so that it would still be
possible to use I/O Channel Cards that were designed to use the 8088 or 80286
Local Bus protocol in a much newer platform. This effectively began to pave the
@@ -5398,7 +5407,7 @@ Extended Memory ranges. It may explain why the Memory expansion cards vanished
so quickly, as they may not have been compatible with some Chipset based
platforms (I'm aware that at least the [Dell System 220][dellSystem220]
computer, equipped with the C&T CS8220 Chipset successor, the CS8221, claimed to
-have upgradeable RAM via an "AT-style memory card", so maybe Memory expansion
+have upgradable RAM via an "AT-style memory card", so maybe Memory expansion
cards did work. However, around the same time the SIMM format became popular, so
it could have simply been that the convenience of populating the SIMM Slots on
the Motherboard itself demolished DRAM sockets and Memory expansion cards in
@@ -5474,6 +5483,7 @@ the next one, they would be part of the same one.
[dellSystem220]: https://books.google.com/books?id=NIG9adkUxkQC&pg=PA210&lpg=PA210&#v=onepage&f=false
[82C206IPC]: http://computercaveman.eu/datasheet/386/P82C206-IPC.pdf
+
##### 5.3 - The second C&T PC/AT Chipset generation, C&T CS8221. Feature overview and Clock Generation
C&T eventually released an improved version of the CS8220 Chipset, the
@@ -5490,7 +5500,7 @@ effort to get them to 20, or even 25 MHz. The previous CS8220 could run a 286 @
10 MHz if using the better binned variant, but even if 286s could be clocked
higher, 10 MHz was pretty much the upper limit of what the expansion cards
sitting in the System Bus and the support chips could tolerate (The slower,
-asynchronous RAM was dealed with by using Wait States), a limit also shared by
+asynchronous RAM was dealt with by using Wait States), a limit also shared by
8088 Turbo XT platforms. Among the multiple major features of the CS8221, the
most notorious one was that the System Bus could be configured to be a fully
independent asynchronous clock domain that was not bound to the clock speed of
@@ -5500,7 +5510,7 @@ clocked almost everything else higher. While the CS8221 datasheet claims that it
supports either 12 or 16 MHz 286s, I'm aware that some Motherboards used it with
20 MHz ones, too.
-The CS8221 Chipset had two Clock Generators. The less interesing one was in the
+The CS8221 Chipset had two Clock Generators. The less interesting one was in the
82C212 Memory Controller, which used as input clock the already too many times
mentioned 14.31 MHz crystal to derive the OSC and OSC/12 lines from. The main
Clock Generator was in the 82C211 Bus Controller, which could use as input
@@ -5520,7 +5530,7 @@ MHz Crystal Oscillator wired to the CLK2IN input line, as in one of the Clock
Generator synchronous modes it could be used to derive a 32 MHz PROCCLK (Same as
CLK2IN) and a 8 MHz SYSCLK (CLK2IN/4). Basically, the Processor clock ran
synchronous with the rest of the system, but at twice its speed. The other use
-case is far more interesing, as it involves a higher clocked Processor, a 286 @
+case is far more interesting, as it involves a higher clocked Processor, a 286 @
20 MHz. Using a 40 MHz crystal to derive the reference clocks for the entire
system wasn't a good idea because in the previous setup, it would also mean that
the System Bus would be @ 10 MHz, which was borderline (Albeit still within the
@@ -5551,7 +5561,7 @@ for Memory expansion cards.
In order to understand in retrospective how amazing the capabilities of the
CS8221 Memory Controller were, you first have to consider about how much RAM a
-PC/AT of the inmediate previous generation had, and the required Hardware to
+PC/AT of the immediate previous generation had, and the required Hardware to
actually install that much RAM. As an example, suppose that a well geared 1988
PC/AT computer had at the bare minimum the full 640 KiB Conventional Memory. As
not all computers supported to have that much installed on the Motherboard
@@ -5566,7 +5576,7 @@ for the HMA actually mattered (Albeit before 1991, which is when PC DOS 5.0
introduced HIMEM.SYS in a pure DOS environment, I think that only Windows/286 or
later could make use of it). Meanwhile, the applications that were memory heavy
relied on EMS, which means that you also required an Expanded Memory card (There
-were also pure Software emulators that could use Extended Memory to emulate
+were also pure software emulators that could use Extended Memory to emulate
Expanded Memory, but I suppose that these were very slow and used only as a last
resort. I don't know how Expanded Memory emulators were supposed to work in a
286, those are functionally different from the more known 386 ones). Thus, a
@@ -5580,7 +5590,7 @@ be installed in identical pairs to fill a Bank (Two 9-Bit SIMMs for a 18-Bit
Bank). With SIMMs capacities being either 256 KiB or 1 MiB, a computer could
have from 512 KiB up to 8 MiB installed on the Motherboard itself, which at the
time was a massive amount. The magic of the Memory Controller relied on its
-mapping flexibility, which could be conveniently managed via Software.
+mapping flexibility, which could be conveniently managed via software.
Basically, you could install a single RAM memory pool in the Motherboard via
SIMMs without having to touch a single Jumper, then set in the BIOS Setup how
you wanted to map it. For example, with 2 MiB installed (8 256 KiB SIMMs), you
@@ -5593,29 +5603,28 @@ use 1024 KiB for Expanded Memory, then leave 384 KiB for Extended Memory. In
resume, the Chipset Memory Controller took care of all the remapping duties so
that your system RAM was where you wanted it to be, and all this was possible
without the need of specialized Hardware like the previous Memory expansion
-cards, nor having to pay the performance overhead of Software emulation. A
+cards, nor having to pay the performance overhead of software emulation. A
trivial detail is that the Memory Controller required an EMS Driver for the
Expanded Memory to work, something that should make this Chipset maybe the first
one to require its own custom Driver to be installed instead of relying on
-generic PC or PC/AT 100% compatible Firmware and OS support.
+generic PC or PC/AT 100% compatible firmware and OS support.
The other Memory Controller feature was Shadow RAM. By the time of the CS8221
Chipset, RAM memory was significantly faster than ROM chips. The PC/AT platform
-had several ROMs that were readed very often, like the BIOS due to the BIOS
+had several ROMs that were read very often, like the BIOS due to the BIOS
Services, and the Video Card VBIOS due to its own routines. Shadow RAM consisted
on copying the contents of these ROMs into RAM memory right after POST, then
tell the Memory Controller to map that RAM into the same fixed, known address
ranges than these ROMs were expected to be. Thanks to this procedure, some ROMs
-were readed only once to load them into RAM, then applications would
-transparently read them from it, which was faster. This resulted in a
-significant performance boost for things that called the BIOS Services or the
-VBIOS often enough. After copying the ROMs contents to the Shadow RAM, it was
-typically write protected, both for safety reasons and to reproduce ROM
-behavior, as it was impossible to directly write to it anyways. However, write
-protecting the Shadow RAM was not mandatory, so I suppose that either due to an
-oversight or maybe intentionally, someone could have left it writeable so that
-live patches could be applied for things like the BIOS or VBIOS code. I wonder
-if someone ever had fun doing that?
+were read only once to load them into RAM, then applications would transparently
+read them from it, which was faster. This resulted in a significant performance
+boost for things that called the BIOS Services or the VBIOS often enough. After
+copying the ROMs contents to the Shadow RAM, it was typically write protected,
+both for safety reasons and to reproduce ROM behavior, as it was impossible to
+directly write to it anyways. However, write protecting the Shadow RAM was not
+mandatory, so I suppose that either due to an oversight or maybe intentionally,
+someone could have left it writable so that live patches could be applied for
+things like the BIOS or VBIOS code. I wonder if someone ever had fun doing that?
What can be shadowed is extremely dependent on the Chipset capabilities. In the
case of the CS8221 Chipset, it seems to be able to shadow the entire 384 KiB of
@@ -5638,13 +5647,14 @@ address ranges, something that in previous generations would require a
specialized Memory expansion card as regular users didn't mapped RAM into the
UMA. That unused mapped RAM would eventually become useful for UMBs (Upper
Memory Blocks). However, UMBs pretty much belongs to the 386 era Memory
-Mangement section since these aren't really era appropiated for a 286, and their
-availability on 286 platforms was extremely dependent on the Chipset mapping or
-shadowing capabilities.
+Management section since these aren't really era appropriate for a 286, and
+their availability on 286 platforms was extremely dependent on the Chipset
+mapping or shadowing capabilities.
[cs8221]: https://media.searchelec.com//specshee/CHIPS/P82C206.pdf
[gentech286]: https://books.google.com/books?id=h6qtgYAzqDgC&lpg=PP1&pg=RA10-PP18&redir_esc=y#v=onepage&q&f=false
+
##### 5.4 - The third C&T PC/AT Chipset generation, C&T 82C235. Feature overview
Later developments from C&T for the 286 includes the 82C235 Chipset released
@@ -5655,10 +5665,10 @@ exception still being the Intel 8042 Microcontroller. Is rather ironic if you
consider how almost everything had been consolidated into a single chip, then
eventually would get bloated in the Intel 80486 and P5 Pentium generations
before repeating again the cycle of consolidation. By the time that the 82C235
-Chipset was reelevant, computers based on the 80386 CPU were already available
-in the mass market and next to become mainstream, pushing the 286 based Turbo
-ATs as the new budget computers, while the original PC platform based ones like
-the Turbo XTs were extremely close to obsolescence.
+Chipset was relevant, computers based on the 80386 CPU were already available in
+the mass market and next to become mainstream, pushing the 286 based Turbo ATs
+as the new budget computers, while the original PC platform based ones like the
+Turbo XTs were extremely close to obsolescence.
For some reason that I don't understand, the 82C235 had a lower Frequency
ceiling than the previous CS8221 Chipset, since it seems that it supported only
@@ -5671,7 +5681,7 @@ synchronous mode, there was no reason to change anything. Maybe it was a small
factory overclock that computer manufacturers could get away with?). There is
also the legend of the 25 MHz 286 from Harris, which I never bothered to check
the details about the required platform to get it running, like which Chipset
-supported it and which was the prefered clock generation method.
+supported it and which was the preferred clock generation method.
Even thought C&T appeared to be quite important during the late 80's and early
90's, it would eventually be purchased by Intel in 1997 and its legacy fade into
@@ -5679,6 +5689,7 @@ obscurity...
[scatDiagram]: http://www.bitsavers.org/components/chipsAndTech/1989_Chips_And_Technologies_Short_Form_Catalog.pdf
+
6 - The Compaq DeskPro 386, the Intel 80386 CPU, 386 era DOS Memory Management, DOS Extenders, and the beginning of the x86-IBM PC marriage
-------------------------------------------------------------------------------------------------------------------------------------------
@@ -5686,9 +5697,9 @@ In September 1986, Compaq, one of the most known manufacturers and among the
firsts to release a virtually 100% IBM PC compatible computer, launched the
DeskPro 386. The launch was significant enough to cause a commotion in the
industry, as it was the first time that a clone manufacturer directly challenged
-IBM leadership. Until then, IBM was the first to use and standarize the
+IBM leadership. Until then, IBM was the first to use and standardize the
significant platform improvements, with clone manufacturers closely following
-the trend that IBM set before eventually attemping to do it better, faster or
+the trend that IBM set before eventually attempting to do it better, faster or
cheaper. That was the case with the original IBM PC and PC/AT, the clone
manufacturers would begin with the same parts than IBM, then eventually deploy
higher clocked ones in Turbo XTs and Turbo ATs. A similar thing happened with
@@ -5707,17 +5718,18 @@ maintain its spot at the top, which it did when it launched a new platform, the
IBM PS/2, in April 1987. Sadly for IBM, the DeskPro 386 lead of half a year in
the market gave it an enormous momentum, since other PC/AT compatible
manufacturers began to follow Compaq and pretty much do clones of the DeskPro
-386. Besides, the IBM PS/2 was heavily propietary in nature, whereas the PC/AT
+386. Besides, the IBM PS/2 was heavily proprietary in nature, whereas the PC/AT
was an open architecture, which gave PC compatible vendors even more incentive
to go with Compaq approach, helping the DeskPro 386 to become a de facto
-standard. As such, the DeskPro 386 has an enormous
-[historical importance][deskpro386], as we're considered
+standard. As such, the DeskPro 386 has an enormous historical
+[importance][deskpro386], as we're considered
[direct descendants of it][deskpro386at30] instead of IBM next platform, the
PS/2.
[deskpro386]: https://dfarq.homeip.net/compaq-deskpro-386/
[deskpro386at30]: http://www.os2museum.com/wp/deskpro-386-at-30/
+
##### 6.1 - The Intel 80386 CPU main features, Virtual 8086 Mode, Flat Memory Model, Paged Virtual Memory
The original 80386 CPU, released in October 1985, is perhaps the most important
@@ -5725,7 +5737,7 @@ Processor in all the 35 years of evolution of the x86 ISA, as its feature set
tackled everything that mattered at the best possible moment. The 386 introduced
pretty much almost everything of what would later became the backbone of the
modern x86 architecture, with the 386 ISA remaining as the baseline for late era
-DOS Software, and going as far as Windows 95 (Even if by then the performance of
+DOS software, and going as far as Windows 95 (Even if by then the performance of
a 386 was far from enough to be usable, it could still boot it). This happened
mostly thanks to Intel finally learning that backwards compatibility was
important, so many of the 386 features were introduced to solve the shortcomings
@@ -5737,7 +5749,7 @@ eight GPRs themselves, which previously were 16 Bits (And for backwards
compatibility, they could still be treated as such), the Data Bus, and the
Address Bus. Extending the Address Bus to a 32 Bits width was a rather major
feature, since it gave the 80386 a massive 4 GiB (2^32) Physical Address Space.
-Protected Mode was upgraded to allow it to return to Real Mode by just setting a
+Protected mode was upgraded to allow it to return to Real Mode by just setting a
Bit, completely removing the need of resetting the Processor and all the
involved overhead when using any of the 286 reset hacks. The 386 also introduced
a new operating mode, Virtual 8086 Mode, a sort of virtualized mode that helped
@@ -5748,35 +5760,35 @@ old Segmentation Unit and the new Paging Unit coexisted in the MMU. The MMU
Paging Unit also had its own small cache, the TLB (Translation Lookaside
Buffer), which you may have hear about a few times.
-The vast majority of the 386 features were available only in Protected Mode,
+The vast majority of the 386 features were available only in protected mode,
which got enhanced to support them but in a backwards compatible manner, so that
-the 80386 Protected Mode could still execute code intended to run in the 80286
-Protected Mode. Since the inmense amount of new features means that applications
-targeting Protected Mode in an 80386 would not work in an 80286, I prefer to
-treat these modes as two separate entities, 286/16 Bits Protected Mode and
-386/32 Bits Protected Mode. Real Mode could be considered extended, too, since
+the 80386 protected mode could still execute code intended to run in the 80286
+protected mode. Since the immense amount of new features means that applications
+targeting protected mode in an 80386 would not work in an 80286, I prefer to
+treat these modes as two separate entities, 286/16 Bits protected mode and
+386/32 Bits protected mode. Real Mode could be considered extended, too, since
it is possible to do 32 Bits operations within it, albeit such code would not
work in previous x86 Processors.
-The Virtual 8086 Mode was a submode of Protected Mode where the addressing style
-worked like Real Mode. The idea was that a specialized application, known as a
-Virtual 8086 Mode Monitor, executed from within a Protected Mode OS to create a
-Hardware assisted Virtual Machine (We're talking about 30 years ago!) for each
-8088/8086 application that you wanted to run concurrently. The V86MM was almost
-identical in role and purpose to a modern VMM like QEMU-KVM, as it could provide
-each virtualized application its own Virtual Memory Map, trap and emulate
-certain types of I/O accesses, and a lot of other things. A V86MM intended to be
-used for DOS applications was known as a VDM (Virtual DOS Machine), which was
-obviously one of the prominent use cases of the V86 Mode. Another possible usage
-of the V86 Mode was to call the BIOS Services or the VBIOS from within it, which
-had an alternative set of pros and cons when compared to returning to Real Mode
-to do so.
-
-Memory Management in the 80386 was incredibily complex due to the many schemes
+The Virtual 8086 Mode was a sub-mode of protected mode where the addressing
+style worked like Real Mode. The idea was that a specialized application, known
+as a Virtual 8086 Mode Monitor, executed from within a protected mode OS to
+create a Hardware assisted Virtual Machine (We're talking about 30 years ago!)
+for each 8088/8086 application that you wanted to run concurrently. The V86MM
+was almost identical in role and purpose to a modern VMM like QEMU-KVM, as it
+could provide each virtualized application its own Virtual Memory Map, trap and
+emulate certain types of I/O accesses, and a lot of other things. A V86MM
+intended to be used for DOS applications was known as a VDM (Virtual DOS
+Machine), which was obviously one of the prominent use cases of the V86 Mode.
+Another possible usage of the V86 Mode was to call the BIOS Services or the
+VBIOS from within it, which had an alternative set of pros and cons when
+compared to returning to Real Mode to do so.
+
+Memory Management in the 80386 was incredibly complex due to the many schemes
that it supported. For memory addressing you had, as usual, the old Segmented
Memory Model that required two GPRs with a Segment and Offset pair to form a
full address, in both its 8088 Real Mode addressing style variant, the 286
-Protected Mode addressing style variant, and a new 386 Protected Mode one that
+protected mode addressing style variant, and a new 386 protected mode one that
differed in that it allowed to extend Segments to be up to 4 GiB in size
compared to the previous maximum of 64 KiB. Moreover, since in the 80386 the
size of the GPR was equal to that of the Address Bus, it was now finally
@@ -5793,7 +5805,7 @@ When in comes to Virtual Memory, you could use the existing Segmented Virtual
Memory scheme, either at a 286 compatible level or with 386 enhancements, or the
new Paged Virtual Memory scheme. The Virtual Address Space also got extended to
4 GiB per task. Is important to mention that internally, when the 386 was in
-Protected Mode and thus addresses were always translated by the MMU, the address
+protected mode and thus addresses were always translated by the MMU, the address
translation was done by the Segmentation Unit first, then optionally, if Paging
was being used, the Paging Unit, before finally getting the Address Bus to
output a Physical Address. Basically, even if using Paging, the Segmentation
@@ -5840,7 +5852,7 @@ Page could only be set with either Supervisor (Equivalent to Ring 0/1/2) or User
enough, the typical arrangement was to have the OS running as Supervisor/Ring 0
and the user applications being User/Ring 3. However, in the early 2000's, an
use case appeared where this was not enough: x86 virtualization. The first
-attempts at x86 virtualization were made entirely in Software, there was no
+attempts at x86 virtualization were made entirely in software, there was no
specialized Hardware features that helped with it. These early VMMs (Virtual
Machine Managers) had to run both the guest OS and the guest applications at the
same privilege level, Ring 3, which basically means that the guest OS had no
@@ -5849,7 +5861,7 @@ and Paging, it was possible to implement a technique known as Ring
Deprivileging, where the host OS could run in Ring 0, as usual, the guest OS as
Ring 1, and the guest applications at Ring 3, providing some form of Hardware
protection. Ring Deprivileging and everything associated with x86 virtualization
-via Software only methods pretty much dissapeared after Intel and AMD Hardware
+via software only methods pretty much disappeared after Intel and AMD Hardware
virtualization extensions, VT-x and AMD-V, respectively, became mainstream
(Actually, a VMM that uses them is colloquially considered to be running in Ring
-1).
@@ -5866,6 +5878,7 @@ with their product lineup...
[intel386design]: http://archive.computerhistory.org/resources/text/Oral_History/Intel_386_Design_and_Dev/102702019.05.01.acc.pdf
+
##### 6.2 - The side stories of the 386: The 32 Bits bug recall, removed instructions, poorly known support chips, and the other 386 variants
While the 80386 CPU would quickly become an era defining Processor, it had a
@@ -5874,9 +5887,9 @@ extremely ambitious CPU that mixed new, modern features on top of backwards
compatibility with previous Processors that in some areas operated quite
differently, so it was like combining the behaviors of three different
Processors into a single one that did them all (8088 Real Mode, 80286 16 Bits
-Protected Mode with Segmented Virtual Memory, 80386 own 32 Bits Protected Mode
+protected mode with Segmented Virtual Memory, 80386 own 32 Bits protected mode
with both Segmented and Paged Virtual Memory, and the Virtual 8086 Mode). Having
-so many operating modes made it such a complex beast that the early Steppings
+so many operating modes made it such a complex beast that the early steppings
were [plagued with issues][386issues].
The earliest issue with the 386 was that it couldn't hit its clock speed
@@ -5889,18 +5902,18 @@ then removed from the lineup). However, not hitting the clock speed target was
perhaps one of the more minor issues...
From all the bugs and errata that the 80386 had, a major one was a
-multiplication bug when running in 32 Bits Protected Mode. It seems that the bug
+multiplication bug when running in 32 Bits protected mode. It seems that the bug
was caused by a flaw in the manufacturing process since not all 386s were
-affected. According to the scarse info that can be found about that matter, the
+affected. According to the scarce info that can be found about that matter, the
bug was severe enough that Intel issued a recall of the 80386 after it was found
around 1987. The 386s that were sent back and those newly produced were tested
for the bug in 32 Bits mode, the good ones were marked with a Double Sigma, and
the bad ones as "16 BIT S/W ONLY". It makes sense than not all 80386 units were
-sent back, so many should't be marked with either.
+sent back, so many shouldn't be marked with either.
The recall and replacement cycle caused an industry wide shortage of 386s, yet
Intel seems to have capitalized on that as they sold those defective 16 Bits 386
-anyways. As there was little to no 32 Bits Software available (Actually, the
+anyways. As there was little to no 32 Bits software available (Actually, the
earliest 386 systems like the Compaq DeskPro 386 were the developing platforms
for them), most 386s were used just as a faster 286, so it made sense to sell
them, probably at some discount. I have no idea to whom Intel sold these 16 Bits
@@ -5918,17 +5931,17 @@ were removed in the B1 Stepping because Intel thought that they were redundant.
The respective opcodes became invalid opcodes. However, these opcodes were
reused for a new instruction in the 80486 CPU, CMPXCHG. Eventually, it seems
that Intel noticed that it wasn't a good idea to overlap two completely
-different instructions onto the same opcodes, so in later 80486 CPU Steppings,
+different instructions onto the same opcodes, so in later 80486 CPU steppings,
these instructions were moved to formerly unused opcodes, as to not have any
-type of conflict. All this means that there may exist Software intended for
+type of conflict. All this means that there may exist software intended for
early 80386 CPUs that uses the IBTS and XBTS instructions, thus will fail to
execute properly in later 80386 CPUs or any other Processor except the early
80486s, where it can show some undefined behavior, as these could execute the
otherwise invalid opcodes but with different results. Likewise, early 80486
-Software that used the CMPXCHG instruction with the old encoding may fail in
-anything but the earliest 80486 Steppings, and misbehave on early 80386s. I
+software that used the CMPXCHG instruction with the old encoding may fail in
+anything but the earliest 80486 steppings, and misbehave on early 80386s. I
suppose that there may still exist early Compilers or Assembler versions that
-can produce such broken Software. As always, details like this is what makes or
+can produce such broken software. As always, details like this is what makes or
breaks backwards and forward compatibility.
One of the most surprising things is that the 80386 CPU was released with pretty
@@ -5941,17 +5954,17 @@ respectively), then letting glue chips fill the void. The most notorious example
of this were early 386 platforms that had a Socket for an optional 80287 FPU,
which could partially sit in the Local Bus (The 16 Bits of the Data Bus were
directly wired to the lower 16 Bits of the CPU itself, the Address Bus had to be
-behind glue logic). Essencially, the whole thing was handled as IBM did in its
+behind glue logic). Essentially, the whole thing was handled as IBM did in its
PC/AT, which used the 286 with its 16/24 Bus for a platform extension of the IBM
PC with the 8088 with its 8/20 Bus, and everything to end up interfacing them to
8/16 8085 era support chips. Is fun when you consider how advanced the 80386
was, and how much the rest of the platform sucked.
Intel eventually released some new support chips to pair with its 80386 CPU. The
-most known one is the Coprocessor, the 80387 FPU, simply because it was a major
+most known one is the Co-processor, the 80387 FPU, simply because it was a major
chip. Because it arrived two years after the 80386 CPU, computer manufacturers
filled the void by adapting the 80287 FPU to run with an 80386, as previously
-mentioned. The FPU would remain a very niche Coprocessor, as in the DOS
+mentioned. The FPU would remain a very niche Co-processor, as in the DOS
ecosystem only very specific applications supported it. There was also the Intel
82385 Cache Controller, a dweller of the Local Bus that interfaced with SRAM
chips to introduce them as a new memory type, Cache. As faster 386s entered the
@@ -5959,7 +5972,7 @@ market, it was obvious that the asynchronous DRAM was too slow, so the solution
was to use the faster, smaller, but significantly more expensive SRAM as a small
Cache to keep the Processor busy while retrieving the main DRAM contents. The
Cache is memory, yet it is not mapped into the Processor Physical Address Space
-thus is transparent to Software. Later 386 Chipsets like the
+thus is transparent to software. Later 386 chipsets like the
[C&T CS8231][cs8231] for the 80386 incorporated their own Cache Controllers,
albeit Cache SRAM itself was typically populated only in high end Motherboards
due to its expensive cost.
@@ -5976,7 +5989,7 @@ The 82380 IPC, among some miscellaneous things, integrated the functions of a
DMAC, a PIC and a PIT, all of which were much better compared to the ancient
discrete parts used in the PC/AT. The integrated DMAC had 8 32 Bits channels, a
substantial improvement compared to the two cascaded 8237A DMACs in the PC/AT
-platform and compatible Chipsets that provided 4 8 Bits and 3 16 Bits channels.
+platform and compatible chipsets that provided 4 8 Bits and 3 16 Bits channels.
The 82380 integrated PIC was actually three internally cascaded 8259A compatible
PICs instead of just two like in the PC/AT. The three chained PICs provided a
total of 20 interrupts, 15 external and 5 internal (Used by some IPC integrated
@@ -5989,27 +6002,27 @@ The question that remains unsolved of the 82380 IPC is that of backwards
compatibility. Both the new PIC and PIT were considered by Intel supersets of
the traditional parts used in the PC/AT, so in theory these two should have been
IBM PC compatible. What I'm not so sure about is the DMAC, as the datasheet
-barely makes a few mentions about some Software level compatibility with the
+barely makes a few mentions about some software level compatibility with the
8237A. Since I failed to find any IBM PC compatible that used the 82380 IPC, I
find it hard to assume that its integrated Devices were fully compatible
supersets of the PC/AT support chips, albeit that doesn't seem logical since I
suppose that by that point, Intel had figured out that another 80186 CPU/SoC
-spinoff with integrated Devices that are incompatible with its most popular ones
-wouldn't have helped it in any way. There were some non IBM PC compatible 386
-based computers that used the 82380 IPC like the Sun386i, but in the IBM PC/AT
-world, everyone seems to have ignored it, as no one used it neither to implement
-the PC/AT feature set, nor the new supersets. Even Intel itself seems to have
-forgotten about it, since some years later, when Intel got into the Chipset
-business during the 486 heyday, the Chipsets only implemented the standard PC/AT
-support chips functionality, not the 82380 superset of them. Basically, whatever
-features the 82380 IPC introduced seems to have been orphaned in a single
-generation like the 8089 IOP, but it is an interesing fork that the x86
-ecosystem evolution could have taken.
+spin-off with integrated Devices that are incompatible with its most popular
+ones wouldn't have helped it in any way. There were some non IBM PC compatible
+386 based computers that used the 82380 IPC like the Sun386i, but in the IBM
+PC/AT world, everyone seems to have ignored it, as no one used it neither to
+implement the PC/AT feature set, nor the new supersets. Even Intel itself seems
+to have forgotten about it, since some years later, when Intel got into the
+Chipset business during the 486 heyday, the chipsets only implemented the
+standard PC/AT support chips functionality, not the 82380 superset of them.
+Basically, whatever features the 82380 IPC introduced seems to have been
+orphaned in a single generation like the 8089 IOP, but it is an interesting fork
+that the x86 ecosystem evolution could have taken.
During the 386 generation, Intel began to experiment heavily with product
segmentation. Whereas in the 286 generation Intel consolidated everything behind
the 80286 (Assuming that you ignore the many different bins, packagings and
-Steppings) with no castrated 80288 variant like in the previous two generations,
+steppings) with no castrated 80288 variant like in the previous two generations,
for the 386 generation Intel ended up introducing a lot of different versions.
The first 386 variant was not a new product but just a mere name change, yet
@@ -6017,12 +6030,12 @@ that name change is actually intertwined with the launch of a new product. After
the 80386 had been for 2 years or so in the market, Intel decided to introduce a
386 version with a castrated Bus width, a la 8088 or 80188. However, instead of
introducing it under the 80388 name that [was supposed to be obvious][386dx],
-Intel decided first to rename the original 80386 by adding a DX surfix, becoming
-the 80386DX. This name change also affected the Coprocessor, as the DX surfix
+Intel decided first to rename the original 80386 by adding a DX suffix, becoming
+the 80386DX. This name change also affected the Co-processor, as the DX suffix
was added to the 80387 FPU, effectively becoming the 80387DX. The 82385 Cache
-Controller seems to have avoided the DX surfix, since there aren't mentions of a
+Controller seems to have avoided the DX suffix, since there aren't mentions of a
82385DX being a valid part at all. Soon after the name change, it launched the
-castrated 386 version as the 80386SX. The SX surfix was also used by the new
+castrated 386 version as the 80386SX. The SX suffix was also used by the new
support chips that were specifically aimed for the 80386SX, namely the 80387SX
FPU and the 82385SX Cache Controller, which are what you expect them to be. I'm
not sure whenever Intel could have come up with an autodetection scheme so that
@@ -6055,20 +6068,20 @@ The next 386 variant, and for sure the most mysterious one, is the
[80376 CPU][376cpu], introduced in 1989. The 376 was a sort of subset of the 386
intended for embedded use, which had a few peculiarities not seen anywhere else
in the history of the x86 ISA. The most important one is that it had no Real
-Mode support, instead, it directly initialized in Protected Mode. The second one
+Mode support, instead, it directly initialized in protected mode. The second one
is that its integrated MMU didn't support Paging for some reason. While 80376
-applications should run in an 80386, the viceversa was not true if they used any
+applications should run in an 80386, the opposite was not true if they used any
of the unsupported features (Basically, nothing DOS related would run on a 376).
If you ever wondered why Intel never tried to purge backwards compatibility from
the modern x86 ISA, the fact that it is very probable that you never hear before
about how Intel already tried to do so with the 376, should tell you something
about how successful doing so was.
-In 1990, intel launched the 80386SL, targeting the nascent laptop and notebook
+In 1990, Intel launched the 80386SL, targeting the nascent laptop and notebook
market. The 386SL was almost a full fledged SoC, as it integrated a 386SX
CPU/MMU Core with a Memory Controller (Including Expanded Memory emulation
support), a Cache Controller and an ISA Bus Controller (The I/O Channel Bus had
-already been standarized and renamed to ISA by 1990). It also had a dedicated
+already been standardized and renamed to ISA by 1990). It also had a dedicated
A20 Gate pin, which was first seen on the 80486 released in 1989. However, it
didn't integrated the core platform support chips, something that the
80186/80188 CPUs did. Instead, the 80386SL had a companion support chip, the
@@ -6080,12 +6093,12 @@ it comparable to a Southbridge.
If you check the 386SL Block Diagrams, is easy to notice that it didn't had a
standard Local Bus to interface with other major chips, since all them were
integrated. As such, the 386SL was its own Northbridge, with the Memory Bus,
-Cache Bus, Coprocessor Bus (The 386SL could be paired with a 387SX FPU) and ISA
+Cache Bus, Co-processor Bus (The 386SL could be paired with a 387SX FPU) and ISA
Bus being directly managed by it. The Intel 82360SL also had its own Bus, the
X-Bus, a little known ISA Bus variant that is directly comparable with the
external I/O Channel Bus since it castrated the Data Bus to 8 Bits and typically
hosted an 8042 compatible Keyboard Controller, the Floppy Disk Controller and
-the Firmware ROM. Perhaps the 80386SL and 80360SL are the first Intel chips
+the firmware ROM. Perhaps the 80386SL and 80360SL are the first Intel chips
where we can see how it embraced the x86-IBM PC marriage, as Intel made clear
than this pair of chips were designed specifically to be used for PC/AT
compatible computers. Also, I think that the 82360SL was technically Intel first
@@ -6094,12 +6107,12 @@ pure PC/AT compatible Southbridge.
The 386SL introduced a major feature, as it was the first Processor to implement
a new operating mode, SMM (System Management Mode), which you may have hear
about if you follow Hardware security related news. The intention of the SMM was
-that the BIOS Firmware could use it to execute code related to power management
+that the BIOS firmware could use it to execute code related to power management
purposes in a way that was fully transparent to a traditional OS, so that the
computer itself would take care of all the power saving measures without needing
-Software support, like a Driver for the OS. The SMM also had a lot of potential
+software support, like a Driver for the OS. The SMM also had a lot of potential
for low level Hardware emulation, a role for which it is currently used by
-modern UEFI Firmwares to translate input from an USB Keyboard into a PC/AT
+modern UEFI firmwares to translate input from an USB Keyboard into a PC/AT
compatible virtual Keyboard plugged into the Intel 8042 Microcontroller. Being
in SMM mode is colloquially known as Ring -2, albeit this is a modern term since
by the time that it received that nomenclature, the mode introduced by Intel
@@ -6110,26 +6123,26 @@ of Interrupt to ask the Processor to switch to SMM. The SMI line is typically
managed by the Chipset (In the 80386SL case, by its 82360SL IOS companion chip),
any request to enter SMM has to be done though it.
-Another interesing thing is that the 386SL had a hybrid Memory Controller that
+Another interesting thing is that the 386SL had a hybrid Memory Controller that
could use either DRAM or SRAM for system RAM. While everyone knows that SRAM is
-theorically faster, in [Page 26 of the 386SL Technical Overview][386slto] Intel
-claims that it performed slower than DRAM since the SRAM chips that were big
-enough to be worth using as system RAM required 3 Memory WS, being ridiculous
-slower than the small ones that are used as Cache. Thus, the purpose of using
-SRAM as system RAM was not for better performance, but because it was an ultra
-low power alternative to DRAM. I found that chart quite appaling, since I always
-though that SRAM as system RAM should have been significantly faster, even if at
-a huge capacity cost for the same money. Also, the 386SL datasheet claims that
-it has a 32 MiB Physical Address Space, pointing out to a 25 Bits Address Bus,
-but the integrated Memory Controller supports only up to 20 MiB installed
-memory. I'm not sure why it is not a standard power of two.
+theoretically faster, in [Page 26 of the 386SL Technical Overview][386slto]
+Intel claims that it performed slower than DRAM since the SRAM chips that were
+big enough to be worth using as system RAM required 3 Memory WS, being
+ridiculous slower than the small ones that are used as Cache. Thus, the purpose
+of using SRAM as system RAM was not for better performance, but because it was
+an ultra low power alternative to DRAM. I found that chart quite appalling,
+since I always though that SRAM as system RAM should have been significantly
+faster, even if at a huge capacity cost for the same money. Also, the 386SL
+datasheet claims that it has a 32 MiB Physical Address Space, pointing out to a
+25 Bits Address Bus, but the integrated Memory Controller supports only up to 20
+MiB installed memory. I'm not sure why it is not a standard power of two.
The final step in the 386 evolution line was the 80386EX, released in 1994.
While the 386EX is out of era since by that time 486s were affordable, the
original P5 Pentium had already been released, and Intel had formally entered
-the PC/AT compatible Chipset business, it is still an interesing chip. The
+the PC/AT compatible Chipset business, it is still an interesting chip. The
80386EX is somewhat similar to the 80386SL as it had a lot of integrated stuff
-SoC style, but instead of notebooks, it targetted the embedded market. The 386EX
+SoC style, but instead of notebooks, it targeted the embedded market. The 386EX
had a 386SX CPU/MMU Core plus the addition of the 386SL SMM, with an external 16
Bits Data Bus and 26 Bits Address Bus (64 MiB Physical Address Space). However,
compared to the 386SL, it doesn't have an integrated Memory Controller, Cache
@@ -6156,13 +6169,13 @@ manufacturers are selling it as such, but not fully compatible in a strict
sense. As such, I find the 386SL much more representative of predicting where
Intel would be going...
-There are two almost unhear variants of the 386 that aren't really important to
-mention but I want to do so to satisfy curious minds. The first is the 80386CX,
-which seems to be mostly an embedded version of the 80386SX with minor changes.
-The second is the [80386BX][386bx], which is a SoC similar to the 386EX but with
-a totally different set of integrated peripherals that aimed to cover the needs
-of early PDAs (The Smartphones of late 90's) with stuff like an integrated LCD
-Controller.
+There are two almost unheard-of variants of the 386 that aren't really important
+to mention but I want to do so to satisfy curious minds. The first is the
+80386CX, which seems to be mostly an embedded version of the 80386SX with minor
+changes. The second is the [80386BX][386bx], which is a SoC similar to the 386EX
+but with a totally different set of integrated peripherals that aimed to cover
+the needs of early PDAs (The Smartphones of late 90's) with stuff like an
+integrated LCD Controller.
[386issues]: https://www.pcjs.org/pubs/pc/reference/intel/80386/
[ibtsxbts]: https://www.pcjs.org/documents/manuals/intel/80386/ibts_xbts/
