Talk:Conventional memory

Removed

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)

Confused

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

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

Unit Prefix

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)

Setty

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

Should mention linux and other non-DOS operating systems

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

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)

Since we're not supposed to edit others' comments I will just rewrite the above but with fixes, as follows...

As noted in the article lede, the 640K limit was due to processor + chipset not being able to address more than 1 MB RAM, plus room being required for video card memory framebuffer, BIOS ROMs, etc. Newer hardware (PCI and later) receives its address assignments from the platform firmware, and later from the OS, but some devices such as the video card also present a "legacy" interface at the old addresses in this range, for compatibility both with older OSs and with the firmware itself.

On x86 and x64 CPUs under virtual memory operating systems, page tables are used to map virtual address space - the memory references that programs use - to physical (real) address space. For 32 bit Windows, normally the first 2 GB of virtual address space is per-process and user-space accessible, and the high-addressed 2 GB of virtual address space is (mostly) instantiated just once and used for kernel mode code and data to which it refers. Use of the /3GB switch in boot.ini in XP or the EXTENDUSERVA BCD option in Vista and later moves this barrier, giving (by default) processes 3GB and the kernel mode code and data only 1GB; often a better fit for e.g. file servers, SQL server, etc. However this article is about physical address space and the info in this paragraph has nothing to do with that.

Most newer motherboards and x86 processors support PAE, or Physical Adress Extensions, which allows physical addresses to be 36 bits wide (in the first implementations), up to 52 bits wide today. Running with PAE (which all recent 32-bit versions of Windows do by default, anyway) will allow full access to 4GB of Physical Memory on a 32bit system, provided that all of the following are true: a) the CPU and motherboard really do implement RAM addresses higher than 0xFFFFFFFF; b) the firmware implements "memory hole remapping"; and c) the OS does not refuse to look at RAM addresses higher than 0xFFFFFFFF. Windows 32-bit client versions, XP SP2 and later, do in fact refuse to touch RAM addresses above 0xFFFFFFFF, so they still see the "3 GB barrier" (it isn't actually at precisely 3 GB) even when all the other conditions are met.

PCI multiplexes address and data bus. Desktops used 32bit PCI bus and Servers used 64 bit bus. (well, some of them.) PCI-express "lane" is a 2 wire serial bus with address embedded in the data stream header like TCP/IP. PCIe and PCI are about 97% programmatically compatible. Motherboard firmware (BIOS or UEFI) detects PCI/PCIx cards after a reset and assigns them to PCI address space, and stores this information in, among other places, the Bus Address Range registers on each card. These are usually near the 4 GB RAM address boundary. many PCI devices reserve more address space than they actually use, a video card with only 256MB of RAM may occupy 1GB of physical address space. Each such assignment of physical address space to a device's host-controller interface (whether the device actually uses all of the assignment or not) causes a "memory hole", a range of physical memory addresses within which no actual RAM can be addressed. If a full 4 GB of RAM is installed then some of the RAM will not be accessible at the expected addresses within the 0x0 to 0xFFFFFFFF address range. Motherboards that implement "memory hole remapping" can cause the RAM that would otherwise be in such a "hole" to appear elsewhere in the address space, often at addresses above 0xFFFFFFFF (4 GB). However this remapping can normally only be done on a very coarse granularity.

When an OS loads it can request card config to change (this is called "resource rebalancing"). However this is not often done. Jeh (talk) 21:28, 25 August 2016 (UTC)

DOSBox and conventional memory

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

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

I put some hidden comments about BIOS interrupt 15 as noted in http://support.microsoft.com/kb/91088, and http://support.microsoft.com/kb/95555 information is also useful but link to "Extended Memory Specification Version 3.0" is broken. Windows Himem.sys info at http://support.microsoft.com/kb/89697 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 http://support.microsoft.com/kb/86018 for corrections to VCPI and DPMI support in Windows 3.1. (ftp://ftp.microsoft.com/misc1/PEROPSYS/WINDOWS/KB/Q83/3/99.TXT.) Text picture in http://support.microsoft.com/kb/37242 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)

About the 640K to 1M "hole"

Re this edit summary:

the memory can be used by drivers (presumably either directly or memory mapped) [...] A hole? Depends on your definitions.

No. It's not "memory" that "can be used by drivers" on any system. There is no RAM addressable there at all. So, yes, it's a "hole" in the otherwise contiguous range of addresses of general-purpose RAM. What might be there instead of RAM, as it says in the lede, is

the ROM BIOS, additional read-only memory, BIOS extensions for fixed disk drives and video adapters, video adapter memory, and other memory-mapped input and output devices.

That is, these things don't use RAM in this address range. These devices themselves (not their drivers) are addressable in that range. This is what's meant by "memory-mapped I/O". A device using MMIO presents its host-controller interface within the system's physical address space.

For example, when Windows' device manager shows that (as on my machine atm) addresses A0000-BFFFF are occupied by "Nvidia whatever-model", that doesn't mean that the driver for that card is in that address space, or is seeing RAM from the system's DIMMs in that space. It means that the video card presents a portion of its host-controller interface within that space. Now, much of the HCI of a video card acts pretty much like RAM, but writing to it will likely have strange effects, like causing points of light to appear on the screen. This particular example would be the old small frame buffer used for base VGA-mode compatibility; modern cards with large VRAM present the majority of their interfaces higher, closer to the 4 GB boundary.

There's a lot of much more complex stuff in devices' HCIs too. Many of the locations are read-only, or write-only; or they may support both read and write, but with different functions (e.g.. writing sends a command to the device, reading returns the device's status). Some bitmapped status or error registers have a "write ones to clear" behavior: You read a status word, then write it back to the same register; this clears the status bits that you've already seen, but bits that the device set since you read it last remain set, and so can be seen on the next read. Some have FIFOs behind them. Etc.

Each such MMIO location is generally called a "register", though from the POV of a driver, you talk to them the same way, or almost the same way, you'd talk to memory. On Windows the driver uses "routines" in the HAL with names like READ_REGISTER_ULONG or WRITE_REGISTER_ULONG, but on most platforms these are just macros that expand to "dereference the pointer". This is in contrast to the e.g. READ_PORT_UCHAR routines that are used to access I/O port space (primarily only used by legacy devices); these use IN and OUT instructions. Jeh (talk) 21:05, 25 August 2016 (UTC)

According to Intel's documentation, there are regions of addressable RAM there, and whether RAM that's hidden by ROM or memory mapped device RAM &c. is a hole or not depends on your definition. Is a hole still a hole after you've stuffed something else in it? It's better not to use the word ‘hole’ at all.

Apparently Windows' designers decided to deal with the situation by reserving the area for device drivers. That way a display adapter e.g. can (and normally does) grab parts of this area when the card has memory mapped video memory. I wonder why they chose to keep usable RAM reserved though, since booting in DOS it's possible to put stuff there. (As you can easily check using mem/full/p.) I'm guessing simplicity may have played a factor, or maybe to avoid driver installation issues, although these kind of devices aren't hot-pluggable. — Preceding unsigned comment added by 80.114.146.117 (talk) 22:44, 25 August 2016 (UTC)

Whether or not there is addressable RAM in that region depends on the granularity with which the firmware can implement holes. "Intel's documentation" doesn't include the effect of the platform you're on, i.e. the firmware. "Conventional memory", the assignment of the 640K to 1M range as reserved for I/O devices and etc., is an artifact of the PC platform that is imposed by the firmware ("BIOS"), not the Intel or AMD CPU or even its chipset (the chipset doesn't care), so it's not surprising that Intel's doc does not give the entire story. It's a hole in terms of addressable RAM. and anyway the term is widespread in the industry; so per WP:NOR, we have to go with that.

Windows does not "reserve the area for device drivers". I have no idea what you mean by that. Device drivers access that area to control their devices. For a card to have memory mapped video memory is the same thing as the card "grabbing parts of this area". Jeh (talk) 00:36, 26 August 2016 (UTC)

Whether Intel's documentation is the best guide is irrelevant, since my comment was a reply to your blanket assertion that ‘there is no RAM addressable there at all.’ And the fact of the matter is that you can take a modern computer, boot DOS on it, and put stuff in those RAM areas.

The WP:NOR link is completely irrelevant to the discussion, I have no idea why you posted it.

If the ‘hole’ terminology is used widely inside the industry, it sure as hell isn't common outside those very narrow circles. Encyclopaedia articles have to be understood by everyone and have to take care not to accidentally misinform, so jargon is no good. Why use a sloppy term that means different concrete things to different people?

‘I have no idea what you mean by that.’ Maybe because I never said that.

In addition, the following problems with this part of the article as it stands have to be dealt with. 1) Due to the references cited, it could appear to the average reader that this is Windows-specific. 2) It suggests to the average reader that a virtual address space has no reserved or inaccessible areas. — Preceding unsigned comment added by 80.114.146.117 (talk) 01:39, 26 August 2016 (UTC)

When you boot a modern computer, Windows doesn't find any RAM in those areas. If it did then the RAM areas would show up as RAM in e.g. RAMmap or meminfo. It doesn't.

WP:NOR is relevant in that we can't invent terminology. We have to go with what's in reliable sources. Even if we think that terminology is confusing or unfamiliar.

Yes, you did say that. Isn't that your signature under the section above, the section that includes the phrase "Windows' designers decided to deal with the situation by reserving the area for device drivers"?

Details of virtual address space like "reserved" or "inaccessbile" areas are completely irrelevant to this article. And I think that mentioning such things would only be confusing - the reader could be misled into thinking that they somehow correspond to or are influenced by these non-RAM areas of physical address space. (They don't.)

Since the article is talking about the PC platform, and the OS can't change the platform, and the Windows examples are just that, examples, I don't think the Windows-specific examples are a problem. But the only reason I removed your Linux ref is as I stated in the edit summary: We can't use self-published sources as references. If you can find a Linux- or Mac OS X-related reference that is acceptable per WP:RS, by all means, let's have it. Jeh (talk) 22:34, 26 August 2016 (UTC)

Incorrect use of the kilobyte unit

The correct unit for kilobyte that is being referred to here is "kB" and not "KB". — Preceding unsigned comment added by Hofniser (talk • contribs) 19:29, 9 May 2017 (UTC)