Talk:Conventional memory

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Hardware (Rated B-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by Computer hardware task force (marked as Mid-importance).
WikiProject Software / Computing  (Rated B-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.


I've removed this passage:

  1. Note that it is neither a limitation of the PC nor of MS-DOS itself, but only the combination of the two. Non-DOS operating systems such as Xenix and Netware did not suffer from the restriction, nor did MS-DOS running on Non-PC compatible X86 computers. == == ==

It was very much a limitation of the pre-386 PC, if 'PC' is defined in this era as IBM systems using Intel chips. The article itself acknowledges this point and this passage subsequently contradicts it. --Yst 23:46, 2 July 2006 (UTC)

I am once again removing this passage, which has been reinserted. The problem with the generalisation that this was not "a limitation of the PC" is that it was fundamentally a limitation of the 8086/8088 and was in practice a real-world limitation of the 286, in that while addressing up to 16MB was possible, it was generally impractical and almost universally ignored as a possibility by manufacturers. It doesn't matter what OS you run on your conventional XT, the chip still can't address more than 1MB. And it doesn't matter what OS you run on your 286, the chip still doesn't make access to the full 16MB adequately practical to be useful. The paragraphs preceding this one acknowledge these differences. This one makes a deceptive generalisation which confuses the whole account. --Yst 19:11, 3 July 2006 (UTC)

I agree with what you say, but am guessing there was some glimmer of truth within that ill-written paragraph. Maybe it was that Xenix, Netware, and on some machines, MSDOS could use 1 MB instead of 640K. Or maybe it was that on 286s some of these could use 16MB (maybe only by VM swapping or something). I imagine that no OS used 16MB on 286s for normal memory since the 286 architecture was so amazingly broken in this respect. -R. S. Shaw 22:15, 4 July 2006 (UTC)
MS-DOS could use 1 mB of RAM on 8088's, but it required some serious hacking (and soldering on the motherboard) to do so. I don't believe XENIX could use any more than DOS could, simply because it was 100% a hardware problem. I know for a fact that MS-DOS can address much more than 640K, but it can't on an 8088 because of a hardware limitation. And yes, Windows/286 could address 16MB as it was specifically designed FOR the 80286. --AndreniW 02:34, 5 July 2006 (UTC)


Shouldn't this: 1024 KiB of memory (220 bytes) read: 1024 KiB of memory (210 bytes)? Unless I've got it all wrong. Please clarify. -- Ynhockey (Talk) 22:22, 28 April 2007 (UTC)

No, because 1 KiB = 1024 (or 210) bytes, and so 1024 Kib = 1024×1024 bytes or 220 bytes. -R. S. Shaw 05:20, 29 April 2007 (UTC)

Unit Prefix[edit]

Considering the low acceptance of the "binary prefixes" within the industry, and their general unfamiliarity outside of it, I propose reverting the March 6th change of units. Opposing views? Cnj 19:26, 25 June 2007 (UTC)

I've spent the last couple days reading the articles on Intel's past microprocessors and I agree that the binary prefixes should be changed to the more-familiar SI prefixes. I've been dabbling with computers since 1980 and majored in computer science in college, yet this is the first place I've ever seen the binary prefixes used. Granted, they may be more accurate, but from what I've seen these articles are directed to the general reader and therefore should be kept as clear as possible. Using the SI prefixes would mean a couple less articles people would have to read and the inaccuracy is only about seven percent at the GB level. KadrianBlackwolf 04:55, 28 June 2007 (UTC)


Isn't this a Unix utility? 12:39, 24 September 2007 (UTC)

Should mention linux and other non-DOS operating systems[edit]

The main reason for the 640kb barrier was the need to preserve functionality of legacy code. Linux has no such barrier since it has no need to preserve space for legacy software.

Microsoft spent years trying to break Windows of its 640k legacy code, but it lingered on as device drivers (MSCDEX, DOSKEY, SCSI board drivers, etc) with Win 3.1, Win 95, Win 98 and Win ME. I believe Windows NT was really the first Microsoft OS to break away from the 640k barrier. Of course many old programs would not work under NT, but oh well.

DMahalko (talk) 23:26, 31 December 2007 (UTC)

Wrong. I started with Minix and Linux .91 kernel which still used PC ROM BIOS calls e.g. Interrupt 10 for console screens. Non x86 like Alpha, MIPS, and Power PC systems used ARC ("Advanced RISC Computing") architecture that emulated PC BIOS on boot. Itanium sucked so Intel came up with EFI to avoid using 16bit x86 instructions on boot: x86 16bit boot code had to in first 1MB of memory. The 640K hardware limit is due to Video Card memory space being placed at 640K plus for ISA compatibility (which also limits dual monitor capability). Not all, but most newer video cards use PCI memoryspace. Amazingly many brand new motherboards include Floppy and IDE interfaces which require 8-bit DMA buffers in first 1MB of memory. And last I checked, most Linux distributions use an ISA (1982 standard) compatible boot loader from disk startup sector. (There are loaders that boot directly to 32-bit mode. Some x64 Linux distros do include those.) Shjacks45 (talk) 16:33, 16 March 2012 (UTC)

Similarities with 3 GB barrier[edit]

Memory from 640K - 1M is/was set aside for hw. Isn't this similar to how Microsoft 32-bit Windows sets aside memory from 3G - 4G, depending on hardware (PCI Express for instance). CapnZapp (talk) 10:45, 23 June 2008 (UTC)

As noted before, the 640K limit was due to video card memory framebuffer and video bios assignment. Newer hardware BIOS assigns devices based on device request, usually to top of PCI Namespace (usually 32-bit). However many PCI devices reserve more memory that they actually use, a video card with only 256MB of RAM may have an aperture size of 1GB. This might cause a conflict with 4 GB of Physical program memory.
Intel processors use internal hardware to map Physical (real) memory to Virtual memory - the memory references that programs use. For 32 bit Windows, normally the first 2 GB of Virtual memory is alloted to user programs and the top 2 GB of Virtual memory is used for the System. Use of the /3 switch in boot.ini in XP or EFI boot parameters in Vista/Win7 gives user programs 3GB and the System only 1GB; often a better fit for end user workloads. Most newer motherboards and Intel processors support PAE, or Physical Adress Extensions, where eight 4GB pages are made available to 32-bit systems. Adding this /PAE switch to boot parameters will allow full access to 4GB of Physical Memory on a 32bit system.
PCI multiplexes address and data bus. Desktops used 32bit PCI bus and Servers used 64 bit bus. PCI-express "lane" is a 2 wire serial bus with address embedded in the data stream header like TCP/IP. Motherboard BIOS detects PCI/PCIx cards on first boot and assigns them to PCI Namespace, and logs this in Extended Configuration Data Area which is internal Flash memory (but called "CMOS"). This is where the BIOS gets subsequent assignments. When 64bit OS loads it can request card config to change.Shjacks45 (talk) 17:15, 16 March 2012 (UTC)

DOSBox and conventional memory[edit]

Am I right in saying that the DOSBox emulator overcomes the limits of conventional memory for old programs which need it? Maybe the Conventional memory page should mention DOSBox? A possible ref link here. TurboForce (talk) 18:01, 7 February 2011 (UTC)

Wasn't supposed to last for 30 years[edit]

Aside from 64K 8088 segments, the reason for 64k blocks was that one row of 9 DRAM chips made 64 kB, in those days. Once 256K and 1M DRAMs becamse cheaper, it becamse awkward to part out memory in 64 K chunks - one (pair of) SIMMs contained the whole memory space in the processor, so part of the DRAM you'd bought was not accessible because it was overlain by the ROM and video memory, etc. ( If I can find a reference for this I can work it into the article, if no-one beats me to it). (Did any 8088 machine use SIMMs or were tehy commercially extinct by the time the SIMM came along?) --Wtshymanski (talk) 16:29, 2 May 2011 (UTC)

Original C compilers used 16-bit pointers or 64K segments. A 16-bit CPU register represented 65536 or 64K. On boot, the Program Segment Register was (hexadecimal) FFFF and the Instruction Pointer was 0000 added (pointer offset left by 4 bits) to make FFFF0 which was the first instruction executed on startup (usually a long jump instruction to the beginning of BIOS ROM. It was easier to make symmetrical silicon in those days and chips also cost per pin so addresses were multiplexed: 7 rows by 7 columns gave 2^14 or 16K bits; 8 X 8 = 2^16 or 64K bits; 9 X 9 = 2^18 or 256K bits. Note that the ORIGINAL IBM PC came with 16KB of RAM. See IBM Personal Computer. Shjacks45 (talk) 19:36, 16 March 2012 (UTC)

XMS Basis[edit]

I put some hidden comments about BIOS interrupt 15 as noted in, and information is also useful but link to "Extended Memory Specification Version 3.0" is broken. Windows Himem.sys info at for Win3. Also reference Andrew Shulman's "Unauthorized Windows 95" Novell's Knowledgebase re Netware not starting after himem.sys loaded and numerous Linux and BSD wikis. Also see for corrections to VCPI and DPMI support in Windows 3.1. ( Text picture in shows memory locations.

The Himem.sys supporting Windows 3.1 V86mgr (Virtual Machine Manager) and Microsoft stance against using Digital Research DOS was an important feature of the Department of Justice AntiTrust Lawsuit aginst Microsoft. Shjacks45 (talk) 16:00, 16 March 2012 (UTC)