Editing Conventional memory

{{Short description|First 640 KB of RAM under DOS}}
{{Use dmy dates|date=May 2019|cs1-dates=y}}
{{Use list-defined references|date=December 2021}}
[[File:IBM PC Memory areas.svg|thumb|Memory areas of the IBM PC family]]

In [[DOS memory management]], '''conventional memory''', also called '''base memory''', is the first 640 [[Kilobyte#Base_2_(1024_bytes)|kilobyte]]s of the memory on [[IBM PC]] or compatible systems. It is the read-write memory directly addressable by the processor for use by the operating system and application programs. As memory prices rapidly declined, this design decision became a limitation in the use of large memory capacities until the introduction of operating systems and processors that made it irrelevant.

== 640 KB barrier ==
<!-- This section is linked from [[IBM PC compatible]] -->
{| class="wikitable floatright"
|+ IBM PC, [[IBM Personal Computer XT|PC/XT]], [[IBM 3270 PC|3270 PC]] and [[IBM PCjr|PCjr]] memory blocks<ref name="Norton_1986"/><ref name="Patent4926322"/>
|-
|0-block||align="right"|1st 64&nbsp;KB||Ordinary user memory to 64&nbsp;KB (low memory area)
|-
|1-block||align="right"|2nd 64&nbsp;KB||Ordinary user memory to 128&nbsp;KB
|-
|2-block||align="right"|3rd 64&nbsp;KB||Ordinary user memory to 192&nbsp;KB
|-
|3-block||align="right"|4th 64&nbsp;KB||Ordinary user memory to 256&nbsp;KB
|-
|4-block||align="right"|5th 64&nbsp;KB||Ordinary user memory to 320&nbsp;KB
|-
|5-block||align="right"|6th 64&nbsp;KB||Ordinary user memory to 384&nbsp;KB
|-
|6-block||align="right"|7th 64&nbsp;KB||Ordinary user memory to 448&nbsp;KB
|-
|7-block||align="right"|8th 64&nbsp;KB||Ordinary user memory to 512&nbsp;KB
|-
|8-block||align="right"|9th 64&nbsp;KB||Ordinary user memory to 576&nbsp;KB
|-
|9-block||align="right"|10th 64&nbsp;KB||Ordinary user memory to 640&nbsp;KB
|-
|A-block||align="right"|11th 64&nbsp;KB||Extended video memory ([[Enhanced Graphics Adapter|EGA]])
|-
|B-block||align="right"|12th 64&nbsp;KB||Standard video memory ([[IBM Monochrome Display Adapter|MDA]]/[[Color Graphics Adapter|CGA]])
|-
|C-block||align="right"|13th 64&nbsp;KB||ROM expansion (XT, EGA, 3270 PC)
|-
|D-block||align="right"|14th 64&nbsp;KB||other use (PCjr cartridges, [[Expanded memory|LIM EMS]])
|-
|E-block||align="right"|15th 64&nbsp;KB||other use (PCjr cartridges, LIM EMS)
|-
|F-block||align="right"|16th 64&nbsp;KB||System ROM-BIOS and ROM-BASIC
|}
The '''640 KB barrier''' is an architectural limitation of [[IBM&nbsp;PC compatible]] PCs. The [[Intel 8088]] CPU, used in the [[IBM Personal Computer|original IBM PC]], was able to address 1&nbsp;MB (2<sup>20</sup>&nbsp;bytes), since the chip offered 20 [[address line]]s. In the design of the PC, the memory below 640&nbsp;KB<!-- not 64 KB! --> was for [[random-access memory]] on the motherboard or on expansion boards, and it was called the conventional memory area. {{anchor|Low}}The first memory segment (64&nbsp;KB<!-- not 640 KB! -->) of the conventional memory area is named '''lower memory''' or '''low memory area'''. The remaining 384&nbsp;KB beyond the conventional memory area, called the [[upper memory area]] (UMA), was reserved for system use and optional devices. UMA was used for the [[ROM BIOS]], additional [[read-only memory]], BIOS extensions for fixed disk drives and video adapters, video adapter memory, and other [[memory-mapped I/O|memory-mapped input and output devices]]. The design of the original IBM PC placed the [[Color Graphics Adapter]] (CGA) memory map in UMA.

The need for more RAM grew faster than the needs of hardware to utilize the reserved addresses, which resulted in RAM eventually being mapped into these unused upper areas to utilize all available addressable space. This introduced a reserved "hole" (or several holes) into the set of addresses occupied by hardware that could be used for arbitrary data. Avoiding such a hole was difficult and ugly and not supported by [[DOS]] or most programs that could run on it. Later, space between the holes would be used as upper memory blocks (UMBs).

To maintain compatibility with older operating systems and applications, the 640&nbsp;KB barrier remained part of the PC design even after the 8086/8088 had been replaced with the [[Intel 80286]] processor, which could address up to 16&nbsp;MB of memory in [[protected mode]]. The 1&nbsp;MB barrier also remained as long as the 286 was running in [[real mode]], since DOS required real mode which uses the segment and offset registers in an overlapped manner such that addresses with more than 20 bits are not possible. It is still present in IBM PC compatibles today if they are running in real mode such as used by DOS. Even the most modern Intel PCs still have the area between 640 and 1024&nbsp;[[kilobyte|KB]] reserved.<ref name="Yao"/><ref name="Russinovich"/> This however is invisible to programs (or even most of the operating system) on newer operating systems (such as [[Microsoft Windows|Windows]], [[Linux]], or [[Mac OS X]]) that use [[virtual memory]], because they have no awareness of physical memory addresses at all. Instead they operate within a virtual address space, which is defined independently of available RAM addresses.<ref name="Richter"/>

Some motherboards feature a "Memory Hole at 15 Megabytes" option required for certain VGA video cards that require exclusive access to one particular megabyte for video memory. Later video cards using the [[Accelerated Graphics Port|AGP]] (PCI memory space) bus can have 256&nbsp;MB memory with 1&nbsp;GB [[Aperture (computer memory)|aperture size]].

=== Additional memory ===
One technique used on early [[IBM XT]] computers was to install additional RAM into the video memory address range and push the limit up to the start of the [[Monochrome Display Adapter]] (MDA). Sometimes software or a custom [[address decoder]] was required for this to work. This moved the barrier to 704&nbsp;KB (with MDA/HGC) or 736&nbsp;KB (with CGA).<ref name="Atkinson"/><ref name="Paul_1997_NWDOSTIP"/>

[[DOS memory management|Memory manager]]s on [[Intel 80386|386-based]] systems (such as [[QEMM]] or MEMMAX (+V) in [[DR-DOS]]) could achieve the same effect, adding conventional memory at 640&nbsp;KB and moving the barrier to 704&nbsp;KB (up to segment B000, the start of MDA/HGC) or 736&nbsp;KB (up to segment B800, the start of the CGA).<ref name="Paul_1997_NWDOSTIP"/> Only CGA could be used in this situation, because [[Enhanced Graphics Adapter]] (EGA) video memory was immediately adjacent to the conventional memory area below the 640&nbsp;KB line; the same memory area could not be used both for the [[frame buffer]] of the video card and for transient programs.

All Computers' piggy-back add-on [[memory management unit]]s ''AllCard'' for XT-<ref name="Petzold_1986_Allcard"/><ref name="PCW_1986_AllCard"/> and ''Chargecard''<ref name="Zerbe_1987_AllCharge"/> for 286/386SX-class computers, as well as MicroWay<!--, Inc.-->'s ECM (Extended Conventional Memory) add-on-board<ref name="Petzold_1986_ECM"/> allowed normal memory to be mapped into the A0000–EFFFF ([[hexadecimal|hex]]) address range, giving up to 952&nbsp;KB for DOS programs. Programs such as [[Lotus 1-2-3]], which accessed video memory directly, needed to be [[patch (computing)|patched]] to handle this memory layout. Therefore, the 640&nbsp;KB barrier was removed at the cost of hardware compatibility.<ref name="Zerbe_1987_AllCharge"/>

{{anchor|Console redirection}}<!-- Redirecting here for now, as there is no better target. A standalone Console redirection article is needed. -->It was also possible to use '''console redirection'''<ref name="Kontron_2021"/> (either by specifying an alternative console device like [[AUX:]] when initially invoking [[COMMAND.COM]] or by using [[CTTY (DOS command)|CTTY]] later on) to direct output to and receive input from a [[dumb terminal]] or another computer running a [[terminal emulator]]. Assuming the [[System BIOS]] still permitted the machine to boot (which is often the case at least with BIOSes for embedded PCs), the video card in a so called [[headless computer]] could then be removed completely, and the system could provide a total of 960&nbsp;KB of continuous DOS memory for programs to load.

Similar usage was possible on many DOS- but not IBM-compatible computers with a non-fragmented memory layout, for example [[Seattle Computer Products|SCP]] [[S-100 bus]] systems equipped with their [[Intel 8086|8086]] CPU card CP-200B and up to sixteen SCP&nbsp;110A memory cards (with 64&nbsp;KB RAM on each of them) for a total of up to 1024 KB (without video card, but utilizing console redirection, and after mapping out the boot/BIOS ROM),<ref name="Paterson_2007_SCP"/> the [[Victor 9000]]/[[Sirius 1]] which supported up to 896&nbsp;KB, or the [[Apricot PC]]<!-- the figure for the Apricot PC is not currently known, except for that it was more than 640 KB --> with more continuous DOS memory to be used under its custom version of MS-DOS.

== DOS driver software and TSRs ==
Most standard programs written for DOS did not necessarily need 640&nbsp;KB or more of memory. Instead, driver software and utilities referred to as [[terminate-and-stay-resident program]]s (TSRs) could be used in addition to the standard DOS software. These drivers and utilities typically used some conventional memory permanently, reducing the total available for standard DOS programs.

Some very common DOS drivers and TSRs using conventional memory included:
* ANSI.SYS - support for color text and different text resolutions
* ASPIxDOS.SYS, ASPIDISK.SYS, ASPICD.SYS - all must be loaded for Adaptec [[SCSI]] drives and CDROMs to work
* [[DOSKEY|DOSKEY.EXE]] - permits recall of previously typed DOS commands using up-arrow
* LSL.EXE, E100BODI.EXE (or other network driver), IPXODI.EXE, NETX.EXE - all must be loaded for [[NetWare]] file server drive letter access
* MOUSE.EXE - support for mouse devices in DOS programs
* MSCDEX.EXE - support for CDROM drive access and drive letter, used in combination with a separate manufacturer-specific driver. Needed in addition to above SCSI drivers for access to a SCSI CDROM device.
* SBCONFIG.EXE - support for [[Sound Blaster 16]] audio device; a differently-named driver was used for various other sound cards, also occupying conventional memory.
* [[SMARTDRV.EXE]] - install drive cache to speed up disk reads and writes; although it could allocate several megabytes of memory beyond 640&nbsp;KB for the drive caching, it still needed a small portion of conventional memory to function.

As can be seen above, many of these drivers and TSRs could be considered practically essential to the full-featured operation of the system. But in many cases a choice had to be made by the computer user, to decide whether to be able to run certain standard DOS programs or have all their favorite drivers and TSRs loaded. Loading the entire list shown above is likely either impractical or impossible, if the user also wants to run a standard DOS program as well.

In some cases drivers or TSRs would have to be unloaded from memory to run certain programs, and then reloaded after running the program. For drivers that could not be unloaded, later versions of DOS included a startup menu capability to allow the computer user to select various groups of drivers and TSRs to load before running certain high-memory-usage standard DOS programs.

=== Upper memory blocks and loading high ===
As DOS applications grew larger and more complex in the late 1980s and early 1990s, it became common practice to free up conventional memory by moving the device drivers and TSR programs into upper memory blocks (UMBs) in the [[upper memory area]] (UMA) at boot, in order to maximize the conventional memory available for applications. This had the advantage of not requiring hardware changes, and preserved application compatibility.

This feature was first provided by third-party products such as [[QEMM]], before being built into [[DR&nbsp;DOS 5.0]] in 1990 then [[MS-DOS 5.0]] in 1991. Most users used the accompanying {{mono|[[EMM386]]}} driver provided in MS-DOS 5, but third-party products from companies such as [[QEMM]] also proved popular.

At startup, drivers could be loaded high using the "[[DEVICEHIGH (CONFIG.SYS directive)|DEVICEHIGH]]=" directive, while TSRs could be loaded high using the "[[LOADHIGH]]", "[[LH (DOS command)|LH]]" or "[[HILOAD]]" directives. If the operation failed, the driver or TSR would automatically load into the regular conventional memory instead.

[[CONFIG.SYS]], loading ANSI.SYS into UMBs, no EMS support enabled:
 DEVICE=C:\DOS\HIMEM.SYS
 DEVICE=C:\DOS\EMM386.EXE NOEMS
 DEVICEHIGH=C:\DOS\ANSI.SYS

[[AUTOEXEC.BAT]], loading MOUSE, DOSKEY, and SMARTDRV into UMBs if possible:
 LH C:\DOS\MOUSE.EXE
 LH C:\DOS\DOSKEY.EXE
 LH C:\DOS\SMARTDRV.EXE

The ability of DOS versions 5.0 and later to move their own system core code into the [[high memory area]] (HMA) through the [[DOS (CONFIG.SYS directive)|DOS]]=HIGH command gave another boost to free memory.

=== Driver and TSR optimization ===
Hardware expansion boards could use any of the upper memory area for ROM addressing, so the upper memory blocks were of variable size and in different locations for each computer, depending on the hardware installed. Some windows of upper memory could be large and others small. Loading drivers and TSRs high would pick a block and try to fit the program into it, until a block was found where it fit, or it would go into conventional memory.

An unusual aspect of drivers and TSRs is that they would use different amounts of conventional and/or upper memory, based on the order they were loaded. This could be used to advantage if the programs were repeatedly loaded in different orders, and checking to see how much memory was free after each permutation. For example, if there was a 50&nbsp;KB UMB and a 10&nbsp;KB UMB, and programs needing 8&nbsp;KB and 45&nbsp;KB were loaded, the 8&nbsp;KB might go into the 50&nbsp;KB UMB, preventing the second from loading. Later versions of DOS allowed the use of a specific load address for a driver or TSR, to fit drivers/TSRs more tightly together.

In MS-DOS 6.0, Microsoft introduced <code>[[MEMMAKER]]</code>, which automated this process of block matching, matching the functionality third-party [[DOS memory management|memory managers]] offered. This automatic optimization often still did not provide the same result as doing it by hand, in the sense of providing the greatest free conventional memory.

Also in some cases third-party companies wrote special multi-function drivers that would combine the capabilities of several standard DOS drivers and TSRs into a single very compact program that used just a few kilobytes of memory. For example, the functions of mouse driver, CD-ROM driver, ANSI support, DOSKEY command recall, and disk caching would all be combined together in one program, consuming just 1 – 2 kilobytes of conventional memory for normal driver/interrupt access, and storing the rest of the multi-function program code in EMS or XMS memory.

== DOS extenders ==
<!-- http://support.microsoft.com/kb/95555 describes the use of BIOS Interrupt 15 services to allocate extended memory. OS2 etc. interpreted BIOS IRQ 15 incorrectly over 64 MB so newer systems had setup to bypass this -->
The barrier was only overcome with the arrival of [[DOS extender]]s, which allowed DOS applications to run in 16-bit or 32-bit [[protected mode]], but these were not very widely used outside of [[PC game|computer gaming]]. With a 32-bit DOS extender, a game could benefit from a 32-bit flat address space and the full 32-bit instruction set without the 66h/67h operand/address override prefixes. 32-bit DOS extenders required compiler support (32-bit compilers) while [[XMS (memory management)|XMS]] and [[Expanded memory|EMS]] worked with an old compiler targeting 16-bit real-mode DOS applications. The two most common specifications for DOS extenders were [[VCPI]]- and later [[DOS Protected Mode Interface|DPMI]]-compatible with Windows 3.x.

The most notable DPMI-compliant DOS extender may be [[DOS/4G|DOS/4GW]], shipping with [[Watcom C/C++|Watcom]]. It was very common in games for DOS. Such a game would consist of either a DOS/4GW 32-bit kernel, or a stub which loaded a DOS/4GW kernel located in the path or in the same directory and a 32-bit "linear executable". Utilities are available which can strip DOS/4GW out of such a program and allow the user to experiment with any of the several, and perhaps improved, DOS/4GW clones.

Prior to DOS extenders, if a user installed additional memory and wished to use it under DOS, they would first have to install and configure drivers to support either [[expanded memory]] specification (EMS) or [[extended memory]] specification (XMS) and run programs supporting one of these specifications.

EMS was a specification available on all PCs, including those based on the [[Intel 8086]] and [[Intel 8088]], which allowed add-on hardware to page small chunks of memory in and out ([[bank switching]]) of the "real mode" addressing space (0x0400–0xFFFF). This allowed 16-bit real-mode DOS programs to access several megabytes of RAM through a hole in real memory, typically (0xE000–0xEFFF). A program would then have to explicitly request the page to be accessed before using it. These memory locations could then be used arbitrarily until replaced by another page. This is very similar to modern paged [[virtual memory]]. However, in a virtual memory system, the operating system handles all [[paging]] operations, while paging was explicit with EMS.

XMS provided a basic protocol which allowed a 16-bit DOS programs to load chunks of 80286 or 80386 extended memory in low memory (address 0x0400–0xFFFF). A typical XMS driver had to switch to protected mode in order to load this memory. The problem with this approach is that while in 286 protected mode, direct DOS calls could not be made. The workaround was to implement a callback mechanism, requiring a reset of the 286. On the 286, this was a major problem. The [[Intel 80386]], which introduced "[[virtual 8086 mode]]", allowed the guest kernel to emulate the 8086 and run the host operating system without having to actually force the processor back into "real mode". [[HIMEM.SYS]] 2.03 and higher used [[unreal mode]] on the 80386 and higher CPUs while HIMEM.SYS 2.06 and higher used [[LOADALL]] to change undocumented internal registers on the 80286, significantly improving interrupt latency by avoiding repeated real mode/protected mode switches.<ref name="Loadall"/>

Windows installs its own version of HIMEM.SYS<ref name="Microsoft_95555"/> on DOS&nbsp;3.3 and higher. Windows HIMEM.SYS launches 32-bit protected mode XMS (n).0 services provider for the Windows Virtual Machine Manager, which then provides XMS (n-1).0 services to DOS boxes and the 16-bit Windows machine (e.g. DOS&nbsp;7 HIMEM.SYS is XMS&nbsp;3.0 but running 'MEM' command in a Windows&nbsp;95 DOS window shows XMS&nbsp;2.0 information).

== See also ==
* [[Expanded memory]] (EMS)
* [[Extended memory]] (XMS)
* [[High memory area]] (HMA)
* [[DOS Protected Mode Services]] (DPMS)
* [[LOADHIGH]]
* [[Long mode]]
* [[RAM limit]]
* [[Transient Program Area]] (TPA)
* [[Upper memory area]] (UMA)
* [[x86 memory segmentation]]
* [[3 GB barrier]]

== References ==
{{reflist|refs=
<ref name="Norton_1986">[[Peter Norton|Norton, Peter]] (1986). Inside the IBM PC, Revised and Enlarged, Brady. {{ISBN|0-89303-583-1}}, p. 108.</ref>
<ref name="Patent4926322">{{US patent|4926322}} - ''Software emulation of bank-switched memory using a virtual DOS monitor and paged memory management'', Fig. 1</ref>
<ref name="Yao">{{cite web |title=White Paper: A Tour beyond BIOS Memory Map Design in UEFI BIOS |author-first1=Jiewen |author-last1=Yao |author-first2=Vincent J. |author-last2=Zimmer |publisher=[[Intel Corporation]] |date=February 2015 |url=https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Map_in%20UEFI_BIOS.pdf |access-date=25 August 2016 |archive-url=https://web.archive.org/web/20150930105244/https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Map_in%20UEFI_BIOS.pdf |archive-date=30 September 2015 |url-status=dead }}</ref>
<ref name="Russinovich">{{cite book |title=Windows Internals |author-first1=Mark Eugene |author-last1=Russinovich |author-link=Mark Eugene Russinovich |author-first2=David A. |author-last2=Solomon |author-first3=Alex |author-last3=Ionescu |edition=6th |volume=Part 2 |page=322 |publisher=[[Microsoft Press]] |date=2012 |quote=Note the gap in the memory address range from page 9F000 to page 100000...}}</ref>
<ref name="Richter">{{cite book |title=Programming Applications for Microsoft Windows |author-first=Jeffrey |author-last=Richter |pages=435 ff}}</ref>
<ref name="Atkinson">{{cite web |title=What is High Memory, why do i care, and how can I use it? |author-first=Cy |author-last=Atkinson |location=San Jose, CA, USA |url=http://www.textfiles.com/computers/pc869kb.txt |access-date=2017-03-13 |date=2001 |url-status=dead |archive-url=https://web.archive.org/web/20160303193643/http://www.textfiles.com/computers/pc869kb.txt |archive-date=2016-03-03}}</ref>
<ref name="Paul_1997_NWDOSTIP">{{cite book |title=NWDOS-TIPs — Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds |trans-title=NWDOSTIPs — Tips & tricks for Novell DOS 7, with special focus on undocumented details, bugs and workarounds |series=MPDOSTIP |author-first=Matthias R. |author-last=Paul |date=1997-07-30 |edition=3 |language=de |url=http://www.antonis.de/dos/dos-tuts/mpdostip/html/nwdostip.htm |access-date=2016-06-06 |url-status=live |archive-url=https://web.archive.org/web/20160606185230/http://www.antonis.de/dos/dos-tuts/mpdostip/html/nwdostip.htm |archive-date=2016-06-06}} (NB. NWDOSTIP.TXT is a comprehensive work on [[Novell DOS 7]] and [[OpenDOS 7.01]], including the description of many undocumented features and internals. It is part of the author's yet larger MPDOSTIP.ZIP collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the NWDOSTIP.TXT file.)</ref>
<ref name="Loadall">{{Cite web|url=http://www.os2museum.com/wp/himem-sys-unreal-mode-and-loadall/|title = HIMEM.SYS, unreal mode, and LOADALL | website=OS/2 Museum}}</ref>
<ref name="Microsoft_95555">{{cite web |url=http://support.microsoft.com/kb/95555 |title=Overview of Memory-Management Functionality in MS-DOS |publisher=Microsoft Support |date=2003-05-12 |access-date=2012-08-13 | archive-url=https://web.archive.org/web/20070212055855/http://support.microsoft.com/kb/95555 | archive-date=February 12, 2007 | url-status=dead}}</ref>
<ref name="Zerbe_1987_AllCharge">{{cite magazine |title=Speicher-Kredit - All Chargecard für ATs |language=de |series=Prüfstand |author-first=Klaus |author-last=Zerbe |editor-first=Andreas |editor-last=Burgwitz |date=November 1987 |magazine=[[c't - magazin für computertechnik]] |publisher=[[Verlag Heinz Heise GmbH & Co. KG]] |volume=1987 |issue=11 |issn=0724-8679 |pages=58, 60}}</ref>
<ref name="Petzold_1986_Allcard">{{cite magazine |title=More Options For Enlarging the Dimensions of Memory |author-first=Charles |author-last=Petzold |date=1986 |magazine=[[PC Magazine]] |issn=0888-8507 |volume=5 |issue=11 }}</ref>
<ref name="Petzold_1986_ECM">{{cite magazine |title=Number Smasher/ECM |author-first=Charles |author-last=Petzold |date=1986-09-16 |magazine=[[PC Magazine]] |issn=0888-8507 |volume=5 |issue=15 |series=Accelerator Boards |pages=148, 150 |url=https://books.google.com/books?id=vcqI6sY2e-kC&pg=PA148 |access-date=2020-03-03 |url-status=live |archive-url=https://web.archive.org/web/20200303183843/https://books.google.de/books?id=vcqI6sY2e-kC&pg=PA148&lpg=PA150&ots=5ZibyVtpJc&focus=viewport&dq=Allcard++286+memory&hl=de#v=onepage&q=Allcard%20%20286%20memory&f=false |archive-date=2020-03-03}}</ref>
<ref name="PCW_1986_AllCard">{{cite magazine |title=AllCard review |magazine=[[Personal Computer World]] |date=September 1986 |page=138}}</ref>
<ref name="Paterson_2007_SCP">{{cite web |title=The First DOS Machine |author-first=Tim |author-last=Paterson |author-link=Tim Paterson |work=DosMan Drivel |date=2007-11-24 |url=http://dosmandrivel.blogspot.com/2007/11/first-dos-machine.html |access-date=2021-12-23 |url-status=live |archive-url=https://web.archive.org/web/20210918001629/https://dosmandrivel.blogspot.com/2007/11/first-dos-machine.html |archive-date=2021-09-18 |quote=[[IBM]] also reintroduced memory limitations that I had specifically avoided in designing the 8086 CPU [card]. For [[S-100 computer]]s, a low-cost alternative to using a regular computer terminal was to use a video card. The video card, however, used up some of the memory address space. The boot ROM would normally use up address space as well. SCP systems were designed to be used with a terminal, and the boot ROM could be disabled after boot-up. This made the entire 1&nbsp;MB of memory address space available for RAM. IBM, on the other hand, had limited the address space in their [[IBM PC|PC]] to 640&nbsp;KB of RAM due to video and boot/BIOS ROM. This limitation has been called the "DOS 640K barrier", but it had nothing to do with [[DOS]]. [[Microsoft]] took full advantage of the [[Seattle Computer Products|SCP]] system capability. In 1988, years after SCP had shut down, they were still using the SCP system for one task only it could perform ("linking the linker"). Their machine was equipped with the full 1&nbsp;MB of RAM – 16 of the 64&nbsp;KB cards. That machine could not be retired until 32-bit software tools were developed for [[Intel]]'s [[Intel 80386|386]] microprocessor.}}</ref>
<ref name="Kontron_2021">{{cite book |title=Kontron User's Guide - COMe-cBTi6R |chapter= |version=Document Revision 1.0 |date=2021 |publisher=[[Kontron]] |pages=37, 60, 64 |url=https://www.kontron.com/download/download?filename=/downloads/manuals/cvvrm110.pdf&product=129903 |access-date=2023-09-23 |url-status=live |archive-url=https://web.archive.org/web/20230923155029/https://www.kontron.com/download/download?filename=/downloads/manuals/cvvrm110.pdf&product=129903 |archive-date=2023-09-23 |quote-page= |quote=}} (89 pages)</ref>
}}

== Further reading ==
* {{cite magazine |title=Mehr als 640 K in PCs |language=de |author-first=Rudolf |author-last=Brenner |date=1986 |magazine=[[c't - magazin für computertechnik]] |publisher=[[Verlag Heinz Heise GmbH & Co. KG]] |volume=1986 |issue=11 |issn=0724-8679 |pages=94}}
* {{cite magazine |title=Booten mit List - PC-Speicher über 640 KB voll genutzt |language=de |series=Praxistip |author-first=Andreas |author-last=Landenberger |editor-first=Michael |editor-last=Wilde |date=November 1987 |magazine=[[c't - magazin für computertechnik]] |publisher=[[Verlag Heinz Heise GmbH & Co. KG]] |volume=1987 |issue=11 |issn=0724-8679 |pages=154, 156}}

[[Category:X86 memory management]]
[[Category:DOS memory management]]